The German e-invoicing obligation: what businesses now have to handle

What an e-invoice is - and what it is not

An e-invoice is an invoice in a structured, machine-readable format the recipient can process without retyping. What counts is the structure, not the delivery channel: a PDF arriving by email is not an e-invoice - not even a beautifully designed, scanned one. A picture of an invoice remains a picture.

The reference point is the European standard EN 16931, which defines the data core. Two expressions of it matter in Germany: ZUGFeRD and XRechnung.

ZUGFeRD or XRechnung - which when

The two formats do not compete, they serve different recipients.

• ZUGFeRD is hybrid: a PDF with the structured data embedded as XML. A person sees a normal invoice, a machine reads the XML. It is the pragmatic route for general B2B, because it also works with recipients who have automated nothing yet.
• XRechnung is pure XML with no visual document and the standard towards public sector customers. It usually requires the routing ID (Leitweg-ID) that directs the invoice to the right office - if it is missing or wrong the invoice is rejected, not queried.
• In practice that means one system producing both, and a setting on the customer for which format they receive. Deciding it per invoice by hand builds the error in from the start.

Receiving is the more urgent half

The discussion is usually about issuing. In practice receiving presses first: you get structured invoices from suppliers whether you are ready or not. Printing and filing them gives away exactly the advantage the format exists for.

It makes sense to tie receiving to invoice checking: the invoice arrives, the lines are held against the purchase order and the goods receipt, discrepancies surface before payment. At that point the e-invoice stops being a compliance topic and starts saving work.

The stumbling blocks sit in the master data

Formats are the smallest problem. What holds a migration up is incomplete data that never bothered anyone, because a person filled in the gaps when in doubt.

• Missing or wrong VAT identification numbers for EU customers
• The routing ID not recorded, or stored on the wrong customer
• The customer order number not carried along, although the recipient rejects invoices without it
• Units and tax rates maintained inconsistently, so validation trips
• Payment terms as free text instead of a structured field

Validate before the customer does

A rejected e-invoice costs more than a faulty paper one: it does not come back with a phone call but disappears into a response channel nobody watches. So rule checks belong before sending - missing mandatory fields have to surface with you, not with the recipient.

That includes the formal validity of the document produced. If you ship ZUGFeRD, have both the XML and the PDF checked against the specifications once externally - either can be broken on its own without anything looking wrong on screen.

Archiving is a topic of its own

A common misunderstanding: that producing e-invoices also settles retention. The two have nothing to do with each other. The duty to retain records properly and unalterably under German GoBD rules, the Fiscal Code and the Commercial Code stays with the business.

What counts there is the structured original, not the printout. So check explicitly, for every system that produces invoices, whether it provides audit-proof archiving - and if not, plan the export into a document archive from the start rather than bolting it on later.

How to approach the change

• Take stock: which customers require which format, and who is a public sector body?
• Clean up master data - VAT identification numbers, routing IDs, order numbers, units
• Store the format on the customer instead of deciding it per invoice
• Start with one customer per format and have receipt confirmed
• Think about the receiving side and invoice checking at the same time, not in a second phase
• Settle archiving before the first e-invoice goes out