ZUGFeRD and XRechnung are the two German invoice formats that satisfy the EN 16931 standard — and therefore count as legal e-invoices under §14 UStG. ZUGFeRD is a hybrid: a normal-looking PDF (PDF/A-3) with the invoice data embedded inside as machine-readable XML. XRechnung is pure structured XML with no visual layer at all. Both carry the same invoice data; they differ in packaging, audience and where they are required. This guide explains the differences, how both relate to EN 16931, how validation works, and which format a Shopify shop actually needs — which, for most merchants, is "both, chosen per invoice".
Why these two formats exist
Germany's e-invoicing mandate (see our complete 2027/2028 timeline) does not prescribe a single file format. §14 UStG requires a structured electronic format conforming to the European standard EN 16931 — a semantic data model that defines what an invoice must contain (seller, buyer, lines, VAT breakdown, totals) and how each element is encoded. Two German implementations of that standard dominate:
- XRechnung — the standard maintained by KoSIT (the German public administration's coordination office for IT standards), created for invoicing German public-sector bodies, where it has been mandatory since November 2020 under the E-Rechnungsverordnung (ERechV).
- ZUGFeRD — developed by FeRD (Forum elektronische Rechnung Deutschland), designed so that one file serves humans and machines at once: a PDF/A-3 you can open and read, with an XML file (CII syntax) embedded inside that accounting software extracts automatically.
An important subtlety: ZUGFeRD qualifies as a legal e-invoice only from version 2.0.1 and only in its EN 16931-compliant profiles. Older ZUGFeRD 1.0 files and the reduced MINIMUM profile do not carry the full EN 16931 data set and do not satisfy the mandate. When someone says "ZUGFeRD counts", they mean ZUGFeRD 2.x at the EN 16931 profile or above.
The comparison at a glance
| ZUGFeRD 2.x | XRechnung 3.x | |
|---|---|---|
| File | One PDF/A-3 file with embedded XML (hybrid) | One XML file (UBL or UN/CEFACT CII syntax) |
| Human-readable? | Yes — opens like any PDF invoice | Not directly — needs a viewer or software to render |
| Machine-readable? | Yes — via the embedded XML | Yes — the file is nothing but data |
| Maintained by | FeRD (Forum elektronische Rechnung Deutschland) | KoSIT, on behalf of the German public administration |
| Required by | No one specifically — accepted wherever EN 16931 is accepted | German public-sector buyers (B2G, per ERechV); increasingly requested by large corporates |
| Typical audience | B2B and B2C e-commerce, SMEs, anyone who still wants a viewable invoice | Authorities, municipalities, public institutions, large enterprise AP systems |
| Extra rules | EN 16931 core rules | EN 16931 plus German BR-DE business rules (e.g. mandatory buyer reference BT-10, seller contact details) |
| Satisfies the 2027/2028 mandate? | Yes (version ≥ 2.0.1, EN 16931-compliant profile) | Yes |
| Validated with | veraPDF (PDF/A-3 container) + EN 16931 schematron for the XML | The official KoSIT validator |
How both relate to EN 16931
Think of EN 16931 as the grammar and vocabulary, and of ZUGFeRD and XRechnung as two documents written in that language. The standard defines around 160 "business terms" (BT-1 invoice number, BT-31 seller VAT identifier, BT-118 VAT category code, and so on) plus business rules that make the numbers reconcile — the sum of line amounts must equal the document total, the VAT breakdown must match the applied rates, and dozens more.
Because both formats implement the same semantic model, the content of a compliant ZUGFeRD invoice and a compliant XRechnung for the same order is essentially identical. What differs:
- Syntax and packaging. ZUGFeRD embeds CII XML in a PDF/A-3; XRechnung is a bare XML file in UBL or CII syntax.
- National tightening. XRechnung adds German business rules (BR-DE-*) on top of EN 16931. The best-known: a mandatory Leitweg-ID or buyer reference (BT-10) so public-sector systems can route the invoice, and mandatory seller contact details (name, phone, email). A file can be perfectly valid EN 16931 and still fail XRechnung validation.
Versions: a moving target
Both standards are alive. ZUGFeRD is today in its 2.x generation, with profiles ranging from MINIMUM through BASIC to EN 16931 and EXTENDED; since version 2.1 it is technically identical to the French standard Factur-X — the same file is valid in both countries. XRechnung is revised by KoSIT on a regular cadence; the current generation is 3.x, and each new release ships with an updated validator configuration. That has an uncomfortable consequence: an invoice that validated last year can fail against this year's configuration after a version change. If you generate invoices yourself, you must actively track version and validator updates; a good tool treats the version as configuration and keeps pace without you noticing.
Validation: the part everyone underestimates
An e-invoice is not "probably fine" the way a PDF is. Receiving systems validate incoming files and reject those that fail — so validation before sending is not optional hygiene, it is the difference between a delivered invoice and a bounced one.
KoSIT validator (XRechnung)
KoSIT publishes the official validator configuration used by public-sector receiving platforms. It checks the XML against the EN 16931 schematron rules plus the German BR-DE rules. If your invoice fails here, a Bund or Länder invoice portal will refuse it.
veraPDF (ZUGFeRD's PDF/A-3 container)
A ZUGFeRD file must additionally be a valid PDF/A-3 — the ISO-standardized archival PDF flavor that permits embedded files. veraPDF, the open-source industry validator, verifies this. A ZUGFeRD invoice whose XML is perfect but whose PDF container violates PDF/A-3 is still a broken e-invoice.
This is why Rechna validates every generated document against both the KoSIT validator and veraPDF before it is delivered — a document that fails a validator is never shipped. If you generate invoices any other way, run these validators yourself; buyers' systems certainly will.
Which format does a Shopify shop need?
Selling to consumers (B2C)
The e-invoicing mandate does not cover B2C, so no structured format is required. ZUGFeRD is still the smart default: your customer sees a familiar PDF, and any business buyer hiding in your B2C stream (it happens constantly) automatically gets a compliant document.
Selling to businesses (B2B)
From 2027/2028 (depending on your turnover — the timeline guide has the decision table), domestic B2B invoices must be EN 16931 documents. ZUGFeRD 2.x satisfies this and keeps the invoice readable for the human on the other side. It is the natural format for e-commerce B2B.
Selling to public-sector buyers (B2G)
Schools, municipalities, public institutions: XRechnung is mandatory, and has been since 2020. If a state institution orders from your shop, a ZUGFeRD PDF may be rejected — you need genuine XRechnung, including the buyer reference (BT-10) their system routes on.
Large corporate customers
Some enterprise accounts-payable systems prefer or demand pure XRechnung even though ZUGFeRD would legally suffice. Being able to produce XRechnung on request keeps those customers.
The practical answer for most shops is therefore not to pick one format but to pick per invoice: ZUGFeRD as the default, XRechnung when the buyer requires it. That per-buyer choice is exactly how Rechna operates — it selects the right format per invoice automatically, generates ZUGFeRD 2.x or XRechnung 3.x, and archives the result in the mandatory 8-year GoBD archive (covered in our guide on GoBD-compliant archiving).
Common misconceptions
- "A PDF with good structure is basically ZUGFeRD." No. Without embedded, EN 16931-conformant XML inside a valid PDF/A-3 container, it is legally just a PDF — a "sonstige Rechnung" under §14 UStG.
- "XRechnung is the stricter format, so I'll just always use it." Possible, but customer-hostile in e-commerce: consumers and small businesses can't open bare XML. Hybrid ZUGFeRD exists precisely for this audience.
- "ZUGFeRD 1.0 files are fine." They are not EN 16931-conformant and do not satisfy the mandate. Version 2.0.1 or later, EN 16931 profile or above.
- "Once generated, the file is compliant." Only validation proves that. The EN 16931 calculation rules (and XRechnung's BR-DE rules) fail real-world invoices constantly — especially ones back-computed from gross prices, which is precisely the Shopify case.
Rechna is software, not tax advice. Format obligations depend on who your buyers are — discuss the specifics with your Steuerberater.