Factur-X and ZUGFeRD: the hybrid PDF/XML invoice

Factur-X is a Franco-German specification for an electronic invoice that is, simultaneously, a human-readable PDF and a machine-readable XML document. Mechanically, it is a PDF/A-3 file with a CII XML attachment embedded inside it, conforming to the EN 16931 semantic model. The same file can be opened by a person in any PDF reader and parsed by accounts-payable software through the embedded XML — without round-trips between formats and without negotiation about which version to send.

The same specification is published under two names: Factur-X is the French label, ZUGFeRD the German one (Zentraler User Guide des Forums elektronische Rechnung Deutschland). The technical content is identical from version 2.1 onwards; vendors and authorities use whichever name fits their audience.

The hybrid principle

The argument for the hybrid format is essentially conservative. Pure-XML invoicing assumes both sides of the transaction have integrated software capable of producing and consuming structured documents. In small and mid-sized businesses, that assumption rarely holds. A bookkeeper opening their inbox still expects a document they can read; a tax inspector reviewing a folder of invoices wants something legible without specialised tooling. A pure XML file is none of these things.

Factur-X treats the PDF and the XML as a single artefact. The PDF is what people see; the XML is what software processes; nothing has to be reconciled because nothing is duplicated — the XML is the authoritative source, and the PDF is rendered from it (or vice versa) at the moment of creation. A receiver that ignores the embedded XML simply has a regular PDF invoice. A receiver that reads it gets a structured document with all the EN 16931 fields available for automation.

This makes Factur-X the natural transition format for organisations whose invoicing volume is too low to justify a full structured-invoicing integration but who must, from 2025 onwards, comply with German B2B receiving requirements or with French national mandates.

Profiles

Factur-X defines five profiles, ordered by the richness of the embedded XML:

• MINIMUM — only the bare identifying fields (parties, totals, type code, currency). The PDF carries the actual invoice content; the XML is a minimal stub for routing and posting.
• BASIC WL ("without lines") — adds VAT breakdowns and document-level allowances and charges, but still no line items.
• BASIC — adds line items. Sufficient for most simple commercial invoices.
• EN 16931 (also called COMFORT) — the full EN 16931 information set. This is the profile that counts as a "real" electronic invoice under the European standard.
• EXTENDED — adds fields beyond EN 16931 for sectors with richer needs (industrial supply chains, complex projects, third-party payments).

Only the EN 16931 and EXTENDED profiles are accepted as compliant electronic invoices in Germany under the 2025 mandate. The lower profiles exist for transitional and routing-only use cases where the structured data is not legally sufficient on its own.

Relationship to the French national format

France's B2B e-invoicing reform, originally scheduled for July 2024 and now phased in through 2026 and 2027, is built on Factur-X as one of three permitted formats (alongside UBL and pure CII). Invoices flow through the Portail Public de Facturation (PPF) and a network of certified private platforms (PDPs), which exchange the structured XML between buyer and seller while the human-readable PDF travels with it.

The French national CIUS — the BR-FR-* family — applies on top of EN 16931 and adds requirements specific to the French tax administration: SIRET formatting, billing-framework codes, lifecycle messages, and the Cadre de facturation concept that distinguishes deposit invoices, corrected invoices, and the various B2B/B2BINT/B2C contexts.

When Factur-X is the right choice

Factur-X earns its place when:

• the invoice must remain human-readable for the receiver — small businesses, B2C, or contexts where the recipient is not yet equipped with structured-invoicing software;
• one wants a single artefact for both archival and processing, rather than maintaining a PDF and a separate XML side by side;
• the issuing system already produces PDFs and adding the embedded XML is a cheaper integration than building a parallel pure-XML pipeline.

Factur-X is the wrong choice when both sides are already integrated for pure structured invoicing. In that case, the PDF wrapper is dead weight — it inflates file size, complicates archiving, and adds no information that is not already in the XML. The natural format in that scenario is pure XRechnung or pure UBL/CII. The decision is examined in detail in XRechnung vs ZUGFeRD.

Validation

A Factur-X file is valid when:

1. the PDF passes PDF/A-3 conformance,
2. the embedded XML conforms to its declared profile (MINIMUM through EXTENDED),
3. for EN 16931 and above, the embedded XML passes the EN 16931 schematron and any additional CIUS rules (BR-DE-* for German XRechnung-aligned use, BR-FR-* for French use).

Our validator accepts Factur-X files directly, extracts the embedded XML, and runs the relevant rule families against it. A green report tells you the file will be accepted both as a PDF and as a structured invoice by any compliant receiving system.

Limits

Two limitations are worth being explicit about. First, the hybrid format does not relieve any transmission, archival, or signing obligation — those live in national law and apply to Factur-X files exactly as they do to pure XML invoices. Second, the human-readable layer is only as good as the rendering: a PDF that omits or misrepresents fields present in the XML creates a mismatch between what a person sees and what accounting software posts. Factur-X assumes — but does not enforce — that the two layers were generated from a single source of truth at the moment of creation. The discipline of keeping them aligned belongs to the issuing system, not the format.