BT-Felder in ZUGFeRD mit csv2zugferd

BT-Felder sind die fachlichen Bausteine jeder strukturierten Rechnung. Diese Übersicht führt die für csv2zugferd wichtigsten Business Terms zusammen und zeigt für jedes Feld, welcher YAML-Key beim CSV-zu-ZUGFeRD-Mapping dazugehört.

Was BT-Felder sind

#

BT steht für Business Term. Die europäische Norm EN 16931 beschreibt das semantische Datenmodell einer elektronischen Rechnung und vergibt jedem fachlichen Inhalt eine eindeutige Nummer: BT-44 für den Käufernamen, BT-131 für den Zeilennettobetrag, BT-152 für den Umsatzsteuersatz einer Position und so weiter. Mehrere zusammengehörige Business Terms werden zu Gruppen (BG) gebündelt, etwa alle Felder einer Rechnungsposition.

ZUGFeRD und XRechnung sind beide Umsetzungen derselben EN 16931. Ein BT-Feld bedeutet in beiden Formaten dasselbe – es wird nur in unterschiedlichen Profilen und in einer anderen XML-Syntax abgelegt. Wer die BT-Nummer kennt, weiß deshalb unabhängig vom konkreten Format, welcher Inhalt gemeint ist.

Warum BT-Felder für csv2zugferd wichtig sind

#

csv2zugferd verkauft keinen E-Rechnungseditor, sondern einen Mapping-Workflow: Eine CSV-Spalte wird per YAML auf ein strukturiertes Rechnungsfeld abgebildet, und daraus entsteht eine valide ZUGFeRD-Datei. Genau an dieser Stelle treffen drei Ebenen aufeinander:

1. Semantik – was das BT-Feld fachlich bedeutet.
2. Produktabbildung – welcher YAML-Key in csv2zugferd dazu gehört.
3. Praxis – aus welcher CSV-Spalte der Wert typischerweise kommt.

Die häufigste Frage in der Praxis lautet deshalb nicht „Was sagt die EN 16931 zu BT-44?", sondern „In welchen YAML-Key gehört der Käufername, und welche CSV-Spalte mappe ich darauf?". Diese Übersicht und die verlinkten Detailseiten beantworten genau das.

Auch Prüfwerkzeuge sprechen diese Sprache. Validatoren wie der KoSIT-Validator oder das E-Rechnungsportal der Finanzverwaltung melden einen Fehler nicht mit dem Namen einer CSV-Spalte, sondern mit der BT-Nummer und der verletzten Geschäftsregel, etwa „BR-61: BT-84 fehlt“. Mit der Tabelle unten führt der Weg vom Prüfbefund direkt zum YAML-Key, der korrigiert werden muss – ohne Umweg über die Norm. Welche Prüfwerkzeuge es gibt und wie sie eingesetzt werden, beschreibt die Seite ZUGFeRD-Validierung.

Die wichtigsten BT-Felder im Überblick

#

Die folgende Tabelle verbindet Bedeutung, YAML-Key und ein knappes Beispiel. Jede Zeile verlinkt auf die ausführliche Detailseite.

BT-Felder nach Themen gruppiert

#

Rechnungstyp und Vorgängerrechnung

#

BT-3 (Rechnungstyp) entscheidet, ob ein Dokument als Rechnung (380), Gutschrift bzw. Storno (381) oder Rechnungskorrektur (384) gelesen wird. Storno und Korrektur verweisen über BT-25 auf die Ursprungsrechnung; XRechnung verlangt diese Referenz bei 384 (BR-DE-26). Beide Felder stehen in csv2zugferd im invoice-Block – siehe YAML-Konfiguration.

Käuferdaten

#

BT-44 (Käufername) ist die elementare Empfängeridentität und nahezu in jedem Workflow ein Pflichtfeld. In csv2zugferd gehört der Wert in buyer.name, die übrigen Adressfelder stehen daneben im buyer-Block.

Bestell- und Lieferbezug

#

BT-13 (Bestellnummer) und BT-72 (Lieferdatum) verankern die Rechnung an Bestellung und tatsächlicher Leistung. Beide werden häufig mit anderen Datums- oder Nummernfeldern verwechselt – die Detailseiten grenzen sie sauber ab.

Positionsdaten

#

BT-153 (Positionsbezeichnung) und BT-155 (Verkäufer-Artikelnummer) beschreiben eine Rechnungsposition lesbar bzw. eindeutig. Sie liegen in csv2zugferd im lineItems.fields-Block und dürfen nicht miteinander vermischt werden.

Steuer und Summen

#

BT-152 (Umsatzsteuersatz je Position) und BT-131 (Zeilennettobetrag) bilden die Grundlage für valide Summen. BT-131 ist dabei kein einfaches Eingabefeld, sondern wird von csv2zugferd aus Menge, Einzelpreis und Rabatt abgeleitet – siehe die zugehörige Detailseite.

Zahlung und Bankverbindung

#

BT-9 (Fälligkeitsdatum) steht in paymentTerms. Die Bankverbindung liegt im paymentMeans-Block: BT-81 legt die Zahlungsart fest, bei Überweisung ist die IBAN des Verkäufers (BT-84) Pflicht. Für eine SEPA-Lastschrift kommen Mandatsreferenz (BT-89), Gläubiger-ID (BT-90) und die IBAN des Käufers (BT-91) hinzu – siehe YAML-Konfiguration.

Typische Mapping-Fehler

#

• Käufername fehlt oder enthält den Ansprechpartner statt der Firma (BT-44).
• Bestellnummer im falschen Feld – interne Auftragsnummer statt Käufer-Bestellnummer (BT-13).
• Artikelnummer als Beschreibung gemappt statt in sellerAssignedId (BT-155).
• Steuersatz fehlt oder wird global vs. positionsbezogen verwechselt (BT-152).
• Zeilenbetrag manuell widersprüchlich geliefert, sodass er nicht zu Menge und Preis passt (BT-131).
• Überweisung ohne IBAN – die Zahlungsart ist 58 (SEPA-Überweisung), aber paymentMeans.sellerAccounts fehlt oder bleibt leer (BT-84, Regel BR-61). csv2zugferd schreibt dafür eine Warnung ins Log, die Verarbeitung läuft weiter.

Wann sich die Detailseiten lohnen

#

Die Detailseiten beantworten für ein einzelnes Feld jeweils: Was ist es? Pflicht oder optional? Welcher YAML-Key? Welcher typische Fehler? Sie sind die richtige Anlaufstelle, wenn ein konkretes Mapping nicht aufgeht oder ein Validator ein bestimmtes BT-Feld bemängelt.

• Käuferdaten: BT-44 Käufername
• Bestell- und Lieferbezug: BT-13 Bestellnummer · BT-72 Lieferdatum
• Positionsdaten: BT-153 Positionsbezeichnung · BT-155 Verkäufer-Artikelnummer
• Steuer und Summen: BT-152 Umsatzsteuersatz · BT-131 Zeilennettobetrag
• Zahlung: BT-9 Fälligkeitsdatum · Bankverbindung und SEPA-Lastschrift (BT-81 bis BT-91)

Nächster Schritt mit csv2zugferd

#

Die BT-Felder sind die Sprache der Norm – das Mapping ist Ihre Arbeit in der YAML-Datei. Drei Wege führen direkt weiter:

• YAML-Konfiguration – die vollständige Mapping-Struktur mit FieldMapping, rows- und columns-Modus.
• Schnellstart – das Demo-Paket mit fertiger config_demo.yml, an der sich jedes BT-Feld nachvollziehen lässt.
• Download – csv2zugferd lokal herunterladen und eigene Rechnungen erzeugen.