↓ Zum Hauptinhalt springen
csv2zugferd

docs

BT-72 Lieferdatum in ZUGFeRD richtig mappen

BT-72 ist das tatsächliche Liefer- bzw. Leistungsdatum in ZUGFeRD und XRechnung. So mappen Sie es in csv2zugferd auf delivery.actualDeliveryDate – mit CSV-Beispiel und Fehlern.

BT-72 ist das tatsächliche Liefer- oder Leistungsdatum – der Tag, an dem die Ware geliefert oder die Leistung erbracht wurde. In csv2zugferd mappen Sie es auf delivery.actualDeliveryDate. Es ist klar vom Rechnungsdatum zu trennen.

Was ist BT-72?
#

BT-72 (Actual delivery date) gibt an, wann die berechnete Lieferung oder Leistung tatsächlich erfolgt ist. Es ist ein eigenständiger fachlicher Inhalt und nicht identisch mit dem Ausstellungsdatum der Rechnung (BT-2) oder dem Fälligkeitsdatum (BT-9).

Pflicht oder optional?
#

Optional nach EN 16931. Sobald Lieferung und Rechnungsstellung aber an unterschiedlichen Tagen liegen – der Regelfall –, ist das Lieferdatum fachlich und steuerlich relevant und sollte gesetzt werden.

Der umschließende Lieferblock (ApplicableHeaderTradeDelivery) ist im ZUGFeRD-Schema dagegen Pflicht. Fehlen in der YAML sowohl actualDeliveryDate als auch die Lieferscheinreferenz, verwendet csv2zugferd ab Version 1.2.1 das Rechnungsdatum als Leistungsdatum und protokolliert eine Warnung. Das entspricht der üblichen Angabe „Leistungsdatum entspricht Rechnungsdatum“, ersetzt aber kein echtes Lieferdatum.

YAML-Key in csv2zugferd
#

delivery:
  actualDeliveryDate:
    column: "DELIVERY_DATE"

actualDeliveryDate setzt das tatsächliche Lieferdatum BT-72. Der delivery-Block kann zusätzlich deliveryNoteNumber und deliveryNoteDate für die Lieferscheinreferenz enthalten; alle drei Felder sind optional.

CSV-Beispiel
#

INVOICE_DATEDELIVERY_DATE
31.05.202624.05.2026

INVOICE_DATE ist das Rechnungsdatum und wird im Rechnungskopf gesetzt. DELIVERY_DATE ist das Lieferdatum und wird auf BT-72 gemappt – hier liegt es vor dem Rechnungsdatum.

So landet der Wert im ZUGFeRD-XML
#

delivery.actualDeliveryDate wird als tatsächliches Lieferdatum (ActualDeliverySupplyChainEvent) geschrieben. Das Datum muss dem in csv.dateFormat konfigurierten Format entsprechen, damit es korrekt geparst wird.

Typischer Fehler
#

  • Rechnungsdatum als Lieferdatum wiederverwendet, obwohl beide Tage unterschiedlich sind. Genau das passiert auch, wenn der delivery-Block fehlt und der Fallback greift.
  • Fälligkeitsdatum als Lieferdatum missbraucht – BT-9 und BT-72 haben unterschiedliche Bedeutung.
  • Uneinheitliche Datumsformate in der CSV, sodass einzelne Zeilen nicht zum konfigurierten csv.dateFormat passen.

Praxishinweis für csv2zugferd
#

Das Datumsformat wird zentral in der YAML unter csv.dateFormat (z. B. dd.MM.yyyy) festgelegt und gilt für alle Datumsspalten. Prüfen Sie vor dem ersten Lauf, dass DELIVERY_DATE exakt diesem Format folgt.

Weiterführende Links#

Häufige Fragen

Ist BT-72 dasselbe wie das Rechnungsdatum?

Nein. BT-72 ist das tatsächliche Liefer- oder Leistungsdatum, also wann geliefert oder die Leistung erbracht wurde. Das Rechnungsdatum (Ausstellungsdatum, BT-2) ist davon unabhängig und wird separat gesetzt.

Was passiert, wenn ich kein Lieferdatum konfiguriere?

Seit Version 1.2.1 schreibt csv2zugferd dann das Rechnungsdatum als Leistungsdatum und gibt eine Warnung aus. Der Lieferblock ist im ZUGFeRD-Schema Pflicht und darf nicht leer bleiben. Liegt die Lieferung an einem anderen Tag, sollten Sie delivery.actualDeliveryDate ausdrücklich mappen.

In welchem Datumsformat muss BT-72 in der CSV stehen?

Im Format, das in der YAML unter csv.dateFormat konfiguriert ist – in der Demo etwa dd.MM.yyyy. Alle Datumsspalten der CSV müssen diesem Format einheitlich entsprechen, sonst schlägt die Verarbeitung fehl.