Delivery Date in ZUGFeRD and XRechnung (BT-72): Map and Correct It Properly

Many automatic converters simply set the invoice date as the delivery date – and that is wrong. The actual delivery or service date is a dedicated field in EN 16931 (BT-72) and must reflect the real moment of delivery, not the day on which the invoice was written.

> Quick answer: The delivery date (BT-72, in the XML as ActualDeliveryDate) is the day of the actual delivery or service – not the invoice date (BT-2). The two can differ. TaxLayer detects the delivery date independently of the invoice date and lets you check and correct it before generation.

The delivery date is not the invoice date

Many invoices carry two different dates: the date the invoice was issued, and the date on which the delivery or service actually took place. For example:

If the delivery date is mistakenly filled with the invoice date, the e-invoice is formally valid but factually incorrect – with consequences for bookkeeping, the service date, and VAT.

What EN 16931 requires

EN 16931 defines the actual delivery date as BT-72. In the two syntaxes it looks like this:

• ZUGFeRD / CII: ram:ApplicableHeaderTradeDelivery → ram:ActualDeliverySupplyChainEvent → ram:OccurrenceDateTime
• XRechnung / UBL: cac:Delivery → cbc:ActualDeliveryDate

The format is a calendar date (in CII as YYYYMMDD, format code 102). It describes the moment of delivery, independently of the invoice date or due date.

The typical error made by automatic converters

A pure PDF-to-XML converter often reads only the obvious header data and fills missing fields with default values. If it has no dedicated detection of the delivery date, it enters the invoice date instead. As long as both dates are identical, this goes unnoticed – but as soon as they differ, the wrong ActualDeliveryDate ends up in the e-invoice.

How TaxLayer solves this

TaxLayer detects the delivery or service date independently and separately from the invoice date. In the review step before generation, it is shown in a dedicated delivery date field, where it can be corrected before the ZUGFeRD or XRechnung file is created. The generated XML then carries the correct date as ActualDeliveryDate.

That way, responsibility for factual accuracy stays with you – and an automatic error cannot slip through in the first place.

Conclusion

The delivery date is a dedicated field of EN 16931 (BT-72) that is mandatory in practice, and it must not be blindly equated with the invoice date. With every conversion, make sure the ActualDeliveryDate reflects the actual delivery date.

---

Try TaxLayer for free now – detects the delivery date, article numbers, and references automatically and lets you review them before generation. Questions to info@landauer.de.