Factur-X: France and Germany's Hybrid PDF/XML E-Invoice Format
Factur-X and ZUGFeRD are now technically identical. A single PDF/A-3 carrying embedded EN 16931 XML lets accountants keep the document they recognise while machines get the data they need.
Most arguments about e-invoicing eventually come back to the same tension: humans want to look at an invoice, machines want to parse it. Factur-X — known as ZUGFeRD in Germany — was designed specifically to end that argument. It is a single PDF/A-3 file with a structured XML payload embedded inside it.
One file, two readers
A Factur-X document has two layers:
- The PDF/A-3 visual layer — what an accountant or auditor sees when they open the file. It is archivable, human-readable, and looks like the invoice they have always processed.
- The embedded XML attachment — a UN/CEFACT Cross Industry Invoice (CII) document conforming to EN 16931, the European semantic standard for invoices.
Because the XML is attached inside the PDF/A-3, there is exactly one artefact to send, store and sign. There is no risk of the human-readable and machine-readable views drifting apart.
Factur-X and ZUGFeRD are the same standard
This trips up almost everyone the first time. France's FNFE-MPE and Germany's FeRD publish the standard jointly. Since ZUGFeRD 2.0 in 2019 the two specifications have been technically identical; current versions (Factur-X 1.0.08 / ZUGFeRD 2.4) align with the latest biannual update of EN 16931 and add features such as sub-line management for kits and bundles, needed for the French and German reforms.
The five profiles
Factur-X defines five profiles that progressively enrich the XML payload:
- MINIMUM — header totals only. Designed for booking aids, not a compliant e-invoice on its own.
- BASIC WL ("without lines") — header data without line items. Also non-compliant with EN 16931 alone.
- BASIC — header plus line items. The first profile that meets EN 16931.
- EN 16931 (formerly COMFORT) — the full European semantic model.
- EXTENDED — EN 16931 plus extensions for complex B2B scenarios (multi-document references, intra-group billing, etc.).
For a French or German B2B mandate, BASIC is the floor; EN 16931 is what most platforms ship by default.
Where Factur-X fits in the French reform
France's reform requires structured e-invoicing between domestic VAT-registered businesses, routed through Partner Dematerialisation Platforms (PDPs) and the central Public Invoicing Portal (PPF). The reform accepts three core formats: UBL, UN/CEFACT CII, and Factur-X. For organisations that still need a human-readable PDF in their AP workflow — which, in practice, is most of them — Factur-X is the path of least resistance.
Where it fits in the German reform
Germany took a more incremental route. Since 1 January 2025 every German business must be able to receive structured e-invoices. The obligation to send them phases in: from 2027 for businesses with revenue above €800,000, and from 2028 for everyone else. Throughout the transition, ZUGFeRD/Factur-X is explicitly accepted as a compliant format, alongside pure XRechnung.
If your team is choosing between "rebuild AP around pure XML" and "keep the PDF workflow, add structured data", Factur-X is the bridge. It is not a workaround — it is a formally recognised EN 16931 implementation.
Implementation notes
- Generate the PDF as PDF/A-3 from the outset; you cannot reliably retrofit conformance by post-processing.
- Embed exactly one XML attachment named
factur-x.xml (older ZUGFeRD names like ZUGFeRD-invoice.xml are no longer compliant).
- Validate against the official EN 16931 schematron rules and the Factur-X profile rules — they catch different classes of error.
- If you also need to support PEPPOL BIS Billing 3.0, plan to emit UBL alongside Factur-X; the syntaxes are different even though the semantics align.
Sources and further reading: FNFE-MPE — Factur-X specification, FeRD — ZUGFeRD specification, European Commission — eInvoicing in France.