XRechnung vs. ZUGFeRD
Two formats, one standard: what sets them apart, when each format is the right choice — and why, in the end, it is always the XML that counts.
Common basis: EN 16931
Both formats implement the European semantic data model EN 16931: the same business terms (BT fields), the same groups (BG), the same core rules. Germany adds the BR-DE rules (e.g. mandatory payment details and contact data). If you generate clean EN 16931, you serve both formats.
| XRechnung | ZUGFeRD (from 2.x) | |
|---|---|---|
| File form | pure XML (UBL or CII) | PDF/A-3 with embedded XML (CII) |
| Human-readable | only with a viewer | yes — the PDF is the view |
| Public authorities (B2G) | standard & usually mandatory | accepted depending on the portal |
| B2B | permitted & widespread | permitted — popular for its readability |
| Legal core | the XML | the embedded XML (not the PDF appearance!) |
| Maintained by | KoSIT (the XRechnung standard) | FeRD/AWV |
UBL or CII — does that need to concern me?
EN 16931 permits two XML syntaxes: UBL and UN/CEFACT CII. XRechnung accepts both, ZUGFeRD uses CII. For you as a user this is an implementation detail — CoolHanX generates valid syntax and validates it against the rules; you only choose whether the recipient additionally gets a PDF view.
| Profile | Content | EN 16931-compliant? |
|---|---|---|
| MINIMUM / BASIC WL | header data only, no line items | no — not sufficient |
| BASIC | structured core data with line items | yes (a subset) |
| EN 16931 (COMFORT) | the full EN 16931 data model | yes — the standard case |
| EXTENDED | EN 16931 + additional data (e.g. logistics) | yes, with extensions |
| XRECHNUNG (reference profile) | CII following XRechnung rules inside the PDF | yes — B2G-capable |
The most common misconception
'I'll attach a nice PDF, the XML is just an accessory' — that's the wrong way round: legally, with ZUGFeRD it is the embedded XML that counts. If the PDF view and the XML diverge, the XML prevails — and the recipient posts what the XML says. That is why CoolHanX always generates the view FROM the validated XML; there is only one truth.
Decision guide
- Public-authority customer? → XRechnung with Leitweg-ID (portal upload ZRE/OZG-RE).
- B2B customer with their own e-invoicing software? → XRechnung is enough.
- B2B customer who wants 'something to look at'? → ZUGFeRD: a PDF for the eye, XML for their software.
- Unsure? → Send XRechnung, offer ZUGFeRD. Both come from the same validated data set.
Frequently asked questions
Is a PDF with invoice data an e-invoice?
No — without structured XML it is not an e-invoice within the meaning of §14 UStG.
Can I receive ZUGFeRD invoices?
Yes — CoolHanX validates the embedded XML just like any XRechnung.
Which XRechnung version is current?
CoolHanX generates XRechnung 3.0 (the current KoSIT standard) and keeps the rule sets continuously up to date.
What about Factur-X?
The French sister format of ZUGFeRD — technically largely identical (CII inside a PDF/A-3).
My customer insists on 'XML only, no PDF' — is that possible?
Yes, then they receive the pure XRechnung. And vice versa — both are produced from the same validated data set.
Can I tell from the format whether an invoice is valid?
No — the format is only the packaging. Validity is decided by validation against EN 16931/BR-DE; that is exactly what runs in CoolHanX and in the free validator.
UBL or CII — two syntaxes under XRechnung
XRechnung is not a single file format but a national implementation (CIUS) of EN 16931 for Germany. It can exist in two XML syntaxes: UBL (Universal Business Language) and UN/CEFACT CII (Cross Industry Invoice). Both represent the same semantic model — a recipient must be able to read both. For you as the issuer this is an implementation detail: CoolHanX generates valid syntax; which one, you don't have to decide.
| Feature | XRechnung | ZUGFeRD |
|---|---|---|
| Structure | pure XML (UBL or CII) | PDF/A-3 with embedded XML |
| Human-readable | only with a viewer | yes, the PDF itself |
| Public sector (B2G) | standard | depending on the profile (EN 16931) |
| Decisive for validation | the XML | the embedded XML |
| Typical use | public authorities, pure B2B data flows | recipients who want a visual view |
ZUGFeRD profiles — not every one is an e-invoice
ZUGFeRD has several profiles. Only from the EN 16931 (Comfort) profile onwards does the embedded XML contain all the mandatory details required for an e-invoice; simpler profiles (e.g. 'Basic WL' or 'Minimum') are not sufficient for the full purpose of an e-invoice. CoolHanX generates ZUGFeRD at an EN 16931-compliant level so that the file legally qualifies as an e-invoice — not just as a pretty PDF with a bit of data.
Why, in the end, it is always the XML that counts
Whether XRechnung or ZUGFeRD: what is decisive for accounting and in law is the structured data set, not the presentation. With ZUGFeRD, if the PDF view and the XML diverge, the XML prevails. That is why CoolHanX generates every readable view from the validated XML — there is only one truth, and it is machine-readable.
Related topics
Allgemeine Produktinformation — keine Rechts- oder Steuerberatung. Verbindliche Auskünfte gibt Ihr Steuerberater bzw. Ihre Rechtsberatung.
Ready? Up and running in two minutes — no credit card.
Create your free company account