Auf dieser Seite
- Die EN-16931-Pflichtfelder: BT-9 und BT-20
- XML-Syntax: CII D16B (ZUGFeRD) und UBL 2.1 (XRechnung)
- CII D16B: ZUGFeRD / Factur-X
- UBL 2.1: XRechnung
- Syntaxwahl und Einlese-Logik
- Aus BT-9 wird eine Cashflow-Position
- Eingang + Ausgang: der vollständige Roundtrip
- Warum das XML-Signal dem PSD2-Bankfeed systematisch vorausläuft
- Praxisarchitektur: Wie eine Einlese-Pipeline aussieht
- StaRUG §1 und IDW S 16: der Pflichtrahmen
- Was der Dienst übernimmt
Jede EN-16931-konforme Rechnung, ob als XRechnung-XML oder ZUGFeRD-Hybrid, trägt zwei Felder, die für die Liquiditätsplanung unmittelbar verwertbar sind: BT-9 (Fälligkeitsdatum) und BT-20 (Zahlungsbedingungen). Dieser Artikel zeigt, wo diese Felder im XML stehen, wie ein System sie zu einer rollierenden Cashflow-Position verarbeitet und warum das XML-Signal dem PSD2-Bankfeed strukturell um Wochen vorausläuft.
Wer zuerst den Nutzen ohne technischen Unterbau sehen will, findet ihn auf der Übersichtsseite Liquiditätsvorschau automatisch aus E-Rechnungen. Einen Überblick aller Lösungsbausteine bietet die Lösungsübersicht.
Die EN-16931-Pflichtfelder: BT-9 und BT-20
EN 16931 ist das semantische Datenmodell der EU für elektronische Rechnungen. Es definiert rund 120 Business Terms (BT) und Business Groups (BG), normiert als Semantik, nicht als Syntax. Für den Zahlungsfluss relevant sind:
| Feld | Bezeichnung | Datentyp | Kardinalität |
|---|---|---|---|
| BT-9 | Payment due date: Fälligkeitsdatum | Date (YYYY-MM-DD) | 0..1 |
| BT-20 | Payment terms: Zahlungsbedingungen | Text | 0..1 |
| BT-115 | Amount due for payment: Zahlbetrag | Amount | 1 |
Die Geschäftsregel BR-CO-25 der EN 16931 legt fest: Ist BT-115 größer als null, muss die Rechnung entweder BT-9 oder BT-20 enthalten. Eine normenkonforme E-Rechnung mit positivem Zahlbetrag liefert damit immer mindestens eines der beiden Fälligkeitssignale.
BT-9 ist der direktere Fall: ein maschinenlesbares Datum. BT-20 enthält Freitext wie „30 Tage netto", „14 Tage 2 % Skonto, 30 Tage netto" oder strukturierte Zahlungskonditionen. Ein System muss ihn parsen, um ein Fälligkeitsdatum abzuleiten.
XML-Syntax: CII D16B (ZUGFeRD) und UBL 2.1 (XRechnung)
EN 16931 schreibt kein XML-Format vor: Es legt zwei normierte Syntaxbindungen fest (CEN/TS 16931-3-2 für UBL 2.1, CEN/TS 16931-3-3 für CII D16B). Beide Syntaxen bilden dasselbe semantische Modell ab; die Feldpfade unterscheiden sich jedoch erheblich.
CII D16B: ZUGFeRD / Factur-X
ZUGFeRD baut auf UN/CEFACT Cross Industry Invoice (D16B) auf. BT-9 und BT-20 liegen im Element SpecifiedTradePaymentTerms unter dem rsm:SupplyChainTradeTransaction-Block:
<ram:SpecifiedTradePaymentTerms>
<!-- BT-20: Zahlungsbedingungen, Freitext -->
<ram:Description>30 Tage netto</ram:Description>
<!-- BT-9: Fälligkeitsdatum, Format 102 = YYYYMMDD -->
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20260228</udt:DateTimeString>
</ram:DueDateDateTime>
</ram:SpecifiedTradePaymentTerms>
Das Datumsformat ist 102 (ISO 8601 ohne Trennzeichen: YYYYMMDD). Systeme, die CAMT.053 oder MT940 kennen, müssen hier auf den format-Parameter achten: Der Wert ist kein ISO-8601-String, sondern ein UN/CEFACT-Format-Code.
UBL 2.1: XRechnung
XRechnung als deutsche CIUS (KoSIT / xeinkauf.de) unterstützt beide Syntaxen; bei PEPPOL-Anbindung ist UBL 2.1 die natürliche Wahl. BT-9 liegt hier unter PaymentMeans, BT-20 unter PaymentTerms:
<!-- BT-9: Fälligkeitsdatum (ISO 8601, YYYY-MM-DD) -->
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cbc:PaymentDueDate>2026-02-28</cbc:PaymentDueDate>
<cac:PayeeFinancialAccount>
<cbc:ID>DE89370400440532013000</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<!-- BT-20: Zahlungsbedingungen, Freitext -->
<cac:PaymentTerms>
<cbc:Note>30 Tage netto, 14 Tage 2 % Skonto</cbc:Note>
</cac:PaymentTerms>
Im UBL-Format ist das Datum als ISO-8601-String (YYYY-MM-DD) kodiert, direkt als Date-Typ verwertbar, ohne Format-Konversion.
Syntaxwahl und Einlese-Logik
Ein Einlesesystem muss beide Syntaxen verarbeiten können, weil Lieferanten nicht einheitlich liefern:
| Kriterium | CII D16B | UBL 2.1 |
|---|---|---|
| ZUGFeRD / Factur-X | Pflicht | nicht unterstützt |
| XRechnung 3.0.2 | unterstützt | unterstützt |
| PEPPOL BIS 3.0 | nicht verwendet | Standard |
| BT-9 Datumsformat | 102 (YYYYMMDD) | ISO 8601 (YYYY-MM-DD) |
| BT-9 Pfad | ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime/udt:DateTimeString | cac:PaymentMeans/cbc:PaymentDueDate |
| BT-20 Pfad | ram:SpecifiedTradePaymentTerms/ram:Description | cac:PaymentTerms/cbc:Note |
Open-Source-Bibliotheken wie Mustang (Java, Apache 2.0) normalisieren beide Syntaxen auf ein gemeinsames Objektmodell und liefern BT-9 direkt als LocalDate. Das reduziert den Eigenaufwand beim Aufbau einer Einlese-Pipeline erheblich.
Aus BT-9 wird eine Cashflow-Position
Die Transformation eines eingehenden Belegs in eine Forecast-Position ist strukturell einfach:
Dokument einlesen
→ Syntax erkennen (ZUGFeRD-PDF oder reines XML)
→ BT-9 extrahieren; falls leer: BT-20 parsen → Datum ableiten
→ BT-115 (Zahlbetrag) und BT-84/BT-85 (IBAN, Kontoinhaber) extrahieren
→ Cashflow-Eintrag anlegen: { datum: BT-9, betrag: -BT-115, gegenseite: BT-44 }
Das Minuszeichen vor BT-115: Verbindlichkeiten sind Abflüsse. Eingehende Rechnungen erzeugen negative Positionen im Forecast.
BT-20 muss geparst werden, wenn BT-9 fehlt. Typische Muster im deutschen B2B:
"30 Tage netto"→ Rechnungsdatum + 30 Tage"14 Tage 2 % Skonto, 30 Tage netto"→ zwei Positionen (eine für Skontofrist, eine für Nettofrist)"sofort"oder"per Erhalt"→ Rechnungsdatum + 0
Strukturierte Skonto-Konditionen (mehrfache ram:ApplicableTradePaymentDiscountTerms-Elemente in CII) erlauben es, Skonto-Szenarien explizit abzubilden, was im manuellen Planungsprozess regelmäßig verloren geht.
Eingang + Ausgang: der vollständige Roundtrip
Eine Liquiditätsvorschau braucht beide Seiten:
Eingehende E-Rechnungen (Verbindlichkeiten): BT-9 liefert das Fälligkeitsdatum, BT-115 den Zahlbetrag. Der Eintrag im Forecast ist negativ.
Ausgehende E-Rechnungen (Forderungen): Dasselbe Modell, umgekehrt. BT-9 ist das vereinbarte Zahlungsziel aus eigener Sicht; BT-115 ist der erwartete Zahlungseingang. Der Eintrag im Forecast ist positiv.
Wer ausgehende E-Rechnungen per BCC oder Kopie in dasselbe Postfach leitet, liefert dem System automatisch die Forderungsseite, ohne manuelle Datenpflege, ohne doppelte Eingabe. Wie das technisch funktioniert, beschreibt die Seite Cashflow aus Belegen.
Der rollierende Forecast ist dann:
Woche t: Summe aller Cashflow-Einträge mit Datum in [t, t+6]
Woche t+1 bis t+12: analog
→ Rollierende 13-Wochen-Vorschau, täglich aktualisiert
Neue Belege verschieben oder ergänzen Positionen; der Horizont rollt automatisch mit.
Warum das XML-Signal dem PSD2-Bankfeed systematisch vorausläuft
Der häufig zitierte Vergleich zwischen E-Rechnungs-XML und Bankfeed verdient eine genaue Herleitung, denn die Behauptung ist keine Annahme, sondern eine strukturelle Notwendigkeit.
Was ein PSD2-Bankfeed liefert: CAMT.053 (ISO 20022) enthält gebuchte Transaktionen. Die Buchung entsteht, wenn die Zahlung ausgeführt wird: Das ist das Valuta- oder Buchungsdatum auf dem Kontoauszug. Zu diesem Zeitpunkt ist der Geldabfluss oder -zufluss bereits vollzogen. Der Bankfeed zeigt die Vergangenheit.
Was das Rechnungs-XML liefert: BT-9 wird beim Rechnungseingang bereitgestellt, also zum Zeitpunkt, an dem der Lieferant die Rechnung ausstellt. Das durchschnittliche B2B-Zahlungsziel in Deutschland beträgt 32 Tage (Creditreform Zahlungsindikator Winter 2025/26). Wer eine Rechnung heute erhält, hat die Information über die in 32 Tagen fällige Verbindlichkeit 32 Tage früher als der Bankfeed sie liefern wird.
Dieser Vorsprung ist kein technischer Trick. Er ist die logische Konsequenz daraus, dass eine Rechnung eine Zahlungsverpflichtung ankündigt, bevor sie eingelöst wird. Der Bankfeed bestätigt die Vergangenheit; das XML signalisiert die Zukunft.
Bei einem Verzug von durchschnittlich weiteren 7,5 Tagen (Creditreform Winter 2025/26) sieht ein System, das auf den Bankfeed wartet, eine Verbindlichkeit im Regelfall erst rund 40 Tage nach Rechnungseingang, also nach dem Fälligkeitsdatum, an dem bereits gehandelt werden müsste.
Rechenbeispiel: Rechnung eingetroffen am 1. Januar 2026, Fälligkeit BT-9 = 31. Januar 2026, Buchung auf dem Konto = 7. Februar 2026. Wer ausschließlich auf CAMT.053 schaut, sieht die Verbindlichkeit 37 Tage nachdem sie hätte geplant werden können.
Praxisarchitektur: Wie eine Einlese-Pipeline aussieht
Eine minimalistische Architektur für den Roundtrip:
Postfach (IMAP/API)
→ Anhang-Extraktion (PDF → ZUGFeRD-XML; .xml → XRechnung)
→ Syntaxerkennung (CII: rsm:CrossIndustryInvoice / UBL: ubl:Invoice)
→ Feldextraktion (BT-9, BT-20, BT-115, BT-44, BT-84)
→ Normalisierung auf internes Modell { datum, betrag, richtung, gegenseite }
→ Forecast-Aggregation nach Woche
→ Ampel-Logik: Saldo in Woche t < Schwellwert → Alert
Die Validierung eingehender Belege gegen EN-16931-Schematron-Regeln (KoSIT-Validator) ist kein optionaler Schritt: Ein Lieferant, der BT-9 im falschen Format liefert oder die Geschäftsregel BR-CO-25 verletzt, erzeugt einen invaliden Beleg und damit eine fehlerhafte Forecast-Position. Eine Vorab-Validierung trennt valide Belege von Ausnahmen, die manuell nachgepflegt werden müssen.
Für ZUGFeRD-PDFs gilt zusätzlich: Der XML-Teil ist führend (BMF-Schreiben Oktober 2025). Das Einlesesystem muss den eingebetteten XML-Datenstrom (EmbeddedDocumentBinaryObject in der PDF-Anlage-Struktur) extrahieren und verarbeiten, nicht das gerenderte PDF. Systeme, die OCR auf dem PDF-Layer laufen lassen, lesen potenziell falsche Daten. Mehr zu diesem Risiko: ZUGFeRD Hybrid-Falle.
StaRUG §1 und IDW S 16: der Pflichtrahmen
Für GmbH, UG und AG kommt zum technischen Argument ein rechtlicher Rahmen hinzu: § 1 StaRUG verpflichtet Geschäftsführer und Vorstände zur frühzeitigen Krisenfrüherkennung. Der IDW S 16 (verabschiedet September 2025) konkretisiert diesen Anspruch: Ein rollierender Liquiditätshorizont gehört zu den Sorgfaltspflichten des Managements.
Aus technischer Sicht bedeutet das: Ein System, das BT-9 aus dem laufenden Rechnungseingang zieht und daraus wöchentlich eine 13-Wochen-Vorschau erzeugt, liefert genau den Datenstrom, den IDW S 16 einfordert, ohne separate Planungsrunde, ohne manuellen Pflegeaufwand.
Die rechtliche Einordnung im Einzelfall gehört in die Beratung durch Steuerberater oder Wirtschaftsprüfer; die Technik schafft die strukturelle Grundlage.
Was der Dienst übernimmt
Die beschriebene Pipeline (Syntaxerkennung, Feldextraktion, BT-20-Parsing, Normalisierung, Forecast-Aggregation, Ampel) ist der Kern der Liquiditätsvorschau des Dienstes. Beide Syntaxen (CII und UBL) werden normalisiert; das eingebettete XML aus ZUGFeRD-PDFs wird direkt verarbeitet, nicht das gerenderte Dokument. Valide und invalide Belege werden getrennt, damit Planungspositionen nicht auf fehlerhafte Felder aufbauen.
Ausführliche Informationen zum automatischen Rechnungseingang: Cashflow aus Belegen.
Liquiditätssignal direkt aus dem Beleg
Wer eingehende E-Rechnungen nach BT-9 und BT-20 auswertet, kennt die fälligen Zahlungsausgänge, bevor sie auf dem Kontoauszug erscheinen. Das gibt die Entscheidungsfähigkeit zurück, solange noch Handlungsspielraum besteht.
Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.
Welche Felder aus der E-Rechnung sind für die Liquiditätsplanung relevant?
Die wichtigsten sind BT-9 (Fälligkeitsdatum), BT-20 (Zahlungsbedingungen als Freitext), BT-115 (Zahlbetrag) und BT-84 (IBAN des Zahlungsempfängers). BT-9 liefert das Datum direkt maschinenlesbar; BT-20 muss geparst werden, wenn BT-9 nicht gesetzt ist. EN-16931-Geschäftsregel BR-CO-25 stellt sicher, dass in jeder normenkonformen Rechnung mit positivem Zahlbetrag mindestens eines der beiden Felder vorhanden ist.
Warum unterscheiden sich die XML-Pfade zwischen ZUGFeRD und XRechnung?
ZUGFeRD nutzt zwingend CII D16B (UN/CEFACT), XRechnung unterstützt sowohl CII als auch UBL 2.1. Die Pfade sind in beiden Syntaxen komplett unterschiedlich: BT-9 liegt in CII unter `ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime`, in UBL unter `cac:PaymentMeans/cbc:PaymentDueDate`. Ein Einlesesystem braucht für beide Syntax-Zweige eigene Extraktionslogik oder eine Bibliothek wie Mustang, die beide Formate auf ein gemeinsames Modell normalisiert.
Was passiert, wenn BT-9 fehlt und BT-20 unstrukturierten Text enthält?
Das System muss BT-20 parsen. Typische Muster im deutschen B2B (z. B. „30 Tage netto", „14 Tage 2 % Skonto, 30 Tage netto") sind mit regulären Ausdrücken oder einer kleinen Regelengine zuverlässig abdeckbar. Bleibt BT-20 leer oder enthält keinen interpretierbaren Wert, muss die Position als „Datum unbekannt" markiert und manuell gepflegt werden. Das ist ein seltener Ausnahmefall bei normenformal korrekten Belegen.
Warum ist der XML-Vorlauf gegenüber dem Bankfeed kein technischer Trick?
Ein PSD2-Bankfeed liefert CAMT.053-Daten: gebuchte Transaktionen, also Vergangenheit. Das Fälligkeitsdatum im E-Rechnungs-XML liegt beim Rechnungseingang vor, im Regelfall 30 bis 40 Tage vor der Bankbuchung (Zahlungsziel 32 Tage + Ø 7,5 Tage Verzug laut Creditreform Winter 2025/26). Das ist keine Approximation, sondern eine strukturelle Notwendigkeit: Eine Rechnung kündigt eine Zahlung an, bevor sie erfolgt.
Muss ich den KoSIT-Validator in die Pipeline integrieren?
Für produktive Systeme ja. Der offizielle KoSIT-Validator prüft Schema-Wohlgeformtheit, EN-16931-Schematron-Regeln und BR-DE-Regeln für XRechnung. Belege, die BR-CO-25 verletzen (kein BT-9 und kein BT-20 bei positivem Zahlbetrag), erzeugen sonst Forecast-Positionen ohne Datum. Die Validierung trennt auswertbare von nachpflegepflichtigen Belegen sauber.
Gilt das auch für Eingangsrechnungen im ZUGFeRD-MINIMUM-Profil?
Nein. Das Profil MINIMUM und BASIC WL sind für die B2B-Rechnungspflicht nach § 14 UStG nicht ausreichend (BMF-Schreiben Oktober 2025) und enthalten keine vollständigen Positionsdaten. BT-9 kann dort fehlen. Für eine belastbare Cashflow-Ableitung sind mindestens das Profil EN 16931 oder EXTENDED erforderlich. Das ist der empfohlene Mindeststandard für B2B-Integration.