XRechnung vs ZUGFeRD: Choosing the Right Format (and the Profiles That Fail)
Germany's mandate accepts XRechnung and ZUGFeRD, but not every ZUGFeRD. The Minimum and Basic-WL profiles fail EN 16931 compliance. Here is how to choose, and how to validate before you send.
XRechnung vs ZUGFeRD: Choosing the Right Format (and the Profiles That Fail)
Germany's e-invoicing mandate does not prescribe one format. It prescribes one standard: EN 16931. Two formats dominate the compliant space. Choosing between them is a workflow decision, not a compliance decision. Choosing the wrong ZUGFeRD profile is a compliance failure.
The Two Formats
XRechnung
Germany's official standard: a pure structured XML file, defined as the German Core Invoice Usage Specification (CIUS) of EN 16931. Available in two syntaxes, both equally valid:
- UBL (Universal Business Language)
- UN/CEFACT CII (Cross Industry Invoice)
XRechnung is machine-first. There is no human-readable layer; the visualisation is generated by the receiving software. It has been mandatory for B2G invoicing to the federal administration since 2020, which makes it the default in public-sector-facing industries.
ZUGFeRD
A hybrid format: a human-readable PDF/A-3 with the structured XML embedded inside. The recipient sees a normal invoice; the recipient's software extracts the XML.
For mandate compliance, ZUGFeRD must be version 2.0.1 or later with a profile that meets EN 16931:
- EN 16931 (Comfort) profile: fully compliant
- Extended profile: compliant, carries additional data beyond the standard
- XRechnung profile: the XRechnung data model embedded in the hybrid container
The Profile Trap
ZUGFeRD ships in profiles with different data content. Two of them fail the mandate:
| Profile | Compliant? | Why |
|---|---|---|
| Minimum | No | Insufficient data content for EN 16931 |
| Basic-WL | No | Insufficient data content for EN 16931 |
| Basic | No | Below EN 16931 data requirements |
| EN 16931 (Comfort) | Yes | Full standard compliance |
| Extended | Yes | EN 16931 plus extensions |
An invoice issued as ZUGFeRD Minimum or Basic-WL is a "sonstige Rechnung": legally, it is not an e-invoice at all. After the transition periods, it carries no input VAT deduction for the buyer. The trap is that the file still looks like a normal invoice PDF. Nobody notices until a validation or an audit.
The Decision Framework
| Your situation | Best-fit format |
|---|---|
| Maximum automation; customers are enterprises or public sector | XRechnung |
| Recipients include small businesses that read invoices manually | ZUGFeRD (EN 16931 profile) |
| You invoice public authorities | XRechnung (already required for B2G) |
| Interoperability across many partners and countries | XRechnung UBL or Peppol BIS 3.0 |
| Existing EDI relationships at volume | EN 16931-aligned EDI mapping (transitional) |
The hybrid nature of ZUGFeRD is its real advantage: one file serves the accountant's eye and the accountant's software. The pure-XML nature of XRechnung is its advantage: no ambiguity about which layer is authoritative. Note that under GoBD, the structured part is the authoritative record in both cases.
Validate Before You Send
The mandate's error taxonomy distinguishes two failure types:
- Format errors: the file violates the syntax or technical specification. A formally defective e-invoice is not an e-invoice under Section 14 (1) sentence 6 UStG; input VAT deduction survives only during the transition periods.
- Business rule errors: the XML is well-formed but violates logical rules. The classic case: the mandatory field BT-10 (Buyer reference) is empty in an XRechnung. Another: the stated tax amount does not match the calculated one. Detected as critical errors during validation.
The KoSIT validator is the reference tool. Workflow:
- Generate a sample invoice from your production system, not from a test template.
- Run it through the KoSIT validator.
- Fix at the data source (contractor master data, invoice form logic), not by hand-editing XML.
- Re-validate, then send.
The BStBK recommends that recipients validate every incoming e-invoice the same way: syntax, semantics, and conformity with national extensions. An invalid invoice received is a problem to raise with the issuer immediately, not to book and discover later.
Common Mistakes
Assuming "ZUGFeRD" means compliant. The profile decides. Check the profile your software actually generates.
Hand-editing the PDF layer of a ZUGFeRD. The visual layer and the XML must match. Editing one desynchronises the file; the structured part is the legally relevant one.
Treating validation as the recipient's problem. A format error on an invoice you issued after your mandate date is your compliance failure, and your customer's input VAT problem.
Forgetting BT-10. Enterprise and public-sector buyers route invoices by Buyer reference. Missing it produces rejections even when the XML is technically valid.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.