The short version, as a table
| XRechnung | ZUGFeRD | |
|---|---|---|
| File type | pure XML | PDF/A-3 with embedded XML |
| Human-readable | only once rendered | yes, directly |
| Syntax | UBL or CII | CII |
| Typical recipient | public administration | companies |
| Rule set | EN 16931 + German add-ons | depends on profile |
| Profiles | none | MINIMUM … EXTENDED, XRECHNUNG |
| Leitweg-ID | mandatory (public sector) | only relevant in the XRECHNUNG profile |
| Satisfies the obligation | always | from the EN 16931 profile |
The actual difference
Both formats implement the same standard. A field called BT-31 in XRechnung is called BT-31 in ZUGFeRD and means the same thing. There is no business content one can carry and the other cannot.
What differs is the shell:
- XRechnung is a data set. Open the file and you see XML. For a person it is usable only once a program renders it.
- ZUGFeRD is a document with a data set inside. Open the file and you see an invoice as always — and notice nothing of the XML.
💡 That is why "which format is better" is the wrong question. The right one is: does the recipient want to look at the document? For a public authority: no, a back-office system processes it. For a mid-sized business customer: almost always yes, a person reviews it before releasing payment.
Two misunderstandings that cost real time
"ZUGFeRD is just a PDF, so not a real e-invoice." Wrong. The embedded XML is a complete invoice under the same standard. The qualifier is right though: that only holds from the EN 16931 profile upwards. The small MINIMUM and BASIC WL profiles genuinely are not e-invoices — which is exactly what makes the claim so persistent, because it is true in some cases.
"XRechnung is mandatory, so I need it for every customer." Also wrong. What is mandatory is invoicing in a structured format — not picking a particular one. For public authorities XRechnung is the expected route. For business customers, ZUGFeRD from EN 16931 upwards satisfies the same obligation.
The way out: one format for both
Anyone who does not want to maintain two output paths uses ZUGFeRD in the XRECHNUNG profile. Such a file is simultaneously:
- a readable PDF for the human,
- a conformant XML under EN 16931,
- and compliant with the German add-on rules of XRechnung.
It is therefore deliverable to a public authority just as it is to a business customer.
The price: you bind yourself to the strictest rule set. Every invoice then needs a seller contact, structured payment instructions and — for public authorities — a valid Leitweg-ID. For business customers that is more diligence than required, but it is diligence that never hurts.
Decision guide
You invoice public administration. XRechnung, or ZUGFeRD in the XRECHNUNG profile. Do not forget the Leitweg-ID.
You invoice companies and want the document to be readable. ZUGFeRD, EN 16931 profile.
You invoice companies whose systems only want data. XRechnung is leaner and saves generating the PDF.
You invoice both and want one path. ZUGFeRD in the XRECHNUNG profile.
You invoice private customers. The obligation does not apply here. ZUGFeRD is still sensible: the customer sees a PDF, their accountant gets data — without you sending two files.
When receiving, the question does not arise
Everything above concerns generating. When receiving you have no choice: what arrives is whatever your suppliers send. One sends ZUGFeRD, the next a UBL XRechnung, the third a CII XRechnung.
An intake process that knows only one format breaks on the second supplier. That is why the format question has a different answer on the receiving side than on the sending side: there the answer is always "all of them".