EN 16931, XRechnung, Factur-X, ZUGFeRD: Europe's e-invoice formats
One European semantic standard, two XML syntaxes, one hybrid PDF, and two national mandates. How Europe's e-invoice formats fit together, and what to validate.
E-invoicing in Europe looks like a zoo of acronyms, but the structure underneath is simple: one semantic standard, two XML syntaxes, national profiles on top, and one hybrid trick that wraps the XML in a PDF. Once you see the layers, every format name slots into place.
The foundation: EN 16931
EN 16931 is the European standard for the content of an electronic invoice. It defines the business terms an invoice carries (seller, buyer, lines, VAT breakdown, totals), numbers them BT-1 through BT-165, and states the rules that hold them together: which fields are mandatory, and how the sums must add up (the BR-* business rules). Most EU countries’ e-invoicing rules build on it.
EN 16931 deliberately does not define file bytes. For that it names two XML syntaxes:
- UBL 2.1, an OASIS standard, element names like
<cbc:ID>and<cac:AccountingSupplierParty>. - UN/CEFACT CII (Cross-Industry Invoice), element names like
<ram:SellerTradeParty>.
The same invoice content can be written in either syntax. Everything below is a layer on top of these two.
The German profile: XRechnung
XRechnung is Germany’s national profile (a CIUS, a “core invoice usage specification”) of EN 16931, maintained by KoSIT, currently at version 3.0.2. It accepts both syntaxes and tightens the rules: a buyer reference (BT-10) becomes mandatory, and for public-sector invoices it carries the Leitweg-ID that routes the invoice to the right authority.
It has been required for invoices to German public buyers since 2020. On the B2B side, Germany has phased in e-invoicing since January 2025 (every company must be able to receive), with mandatory issuing arriving in 2027 for companies above 800,000 euros in turnover and in 2028 for everyone.
The hybrid: Factur-X and ZUGFeRD
Factur-X (French name) and ZUGFeRD (German name) are the same Franco-German standard, published jointly by FNFE-MPE and FeRD. The idea: a normal-looking PDF (PDF/A-3) with the machine-readable CII XML embedded inside. A human opens the PDF and sees an invoice; software extracts the XML and reads structured data. Current release: Factur-X 1.09.
Factur-X comes in profiles of increasing completeness (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). The EN 16931 profile is the one that carries a complete standard-compliant invoice; the smaller profiles carry less than the full data set, which matters if your counterparty needs to process the XML alone.
The French mandate
France switches on 1 September 2026: every VAT-registered business must be able to receive electronic invoices, and large and mid-size companies must issue them (small companies follow on 1 September 2027). Invoices flow through government-accredited platforms, and Factur-X is one of the core formats of the reform, alongside UBL and CII.
So which format will you meet?
| You are dealing with | Expect |
|---|---|
| German public sector | XRechnung (UBL or CII) |
| German B2B | XRechnung or ZUGFeRD (EN 16931 profile) |
| French reform (2026) | Factur-X, UBL or CII via accredited platforms |
| Pan-European networks | Peppol BIS, a UBL-based EN 16931 profile |
What “valid” means, per layer
A file can be well-formed XML and still be an invalid invoice. Real validation checks every layer: the syntax (schema), the EN 16931 business rules (mandatory fields, totals coherence), and the profile’s extra rules (XRechnung’s buyer reference, code lists). That is exactly what the einvoicekit API runs, one HTTP call per file, whichever of these formats you send: a Factur-X PDF is unwrapped automatically, and XRechnung files are checked in both syntaxes. For a quick manual check there is a free validator that runs the same full official rule set.
If you produce XRechnung from code, we walked through the whole loop in Validate an XRechnung invoice in Python.