XRechnung vs. ZUGFeRD: Differences & Which Format You Need

One semantic model, two packaging decisions

EN 16931-1 defines business terms and rules, not files. Every fact on an invoice has an identifier — BT-1 invoice number, BT-10 buyer reference, BT-31 seller VAT identifier, BT-112 grand total including VAT — and the standard fixes their meaning, cardinality and arithmetic relationships. Two syntax bindings are normative: OASIS UBL 2.1 and UN/CEFACT Cross Industry Invoice (CII) D16B.

XRechnung is a CIUS — a Core Invoice Usage Specification — published by KoSIT for the German public sector. A CIUS may only restrict the base standard: it can make optional fields mandatory, forbid fields, or narrow code lists, but it can never invent new semantics. XRechnung supports both UBL and CII syntaxes and adds roughly 30 additional business rules on top of the EN 16931 set.

ZUGFeRD 2.x (identical in substance to the French Factur-X) is not a CIUS but a container specification. It defines how a CII XML instance is attached to a PDF/A-3 file so that a human reads the page image and a machine reads the attachment. The XML inside a ZUGFeRD file at profile EN 16931 or above is itself an EN 16931-conformant CII document — which means a ZUGFeRD file can carry an XRechnung-conformant payload.

That last point resolves most of the confusion in practice. The question is rarely 'XRechnung or ZUGFeRD'. It is 'which syntax, at which profile, in which container, delivered over which channel'.

• Semantics: EN 16931 business terms (BT-*) and business rules (BR-*)
• Syntax: UBL 2.1 or UN/CEFACT CII D16B
• Profile: XRechnung CIUS, ZUGFeRD MINIMUM…EXTENDED, Peppol BIS
• Container: bare .xml file, or PDF/A-3 with an embedded attachment

Anatomy of an XRechnung file

An XRechnung instance is a single UTF-8 XML document, typically 8–40 KB. In UBL syntax the root element is <Invoice>, with cbc:CustomizationID carrying the specification identifier — the string that tells the receiving validator which rule set to apply. Getting that identifier wrong is one of the most common causes of a rejection that reports no obvious field error: the validator either applies the wrong profile or refuses the document outright.

Structurally the document falls into four blocks: document header (number, issue date, type code 380 for a commercial invoice, currency, buyer reference), party blocks (seller and buyer with legal name, address, tax registration and electronic address), line items (each with quantity, unit code from UN/ECE Recommendation 20, net unit price and a tax category), and the monetary summation with the per-category VAT breakdown.

The Leitweg-ID lives in BT-10, the buyer reference. It is a routing identifier assigned by the administrative body, not a customer number, and it is mandatory for German B2G. Without it the invoice cannot be delivered to the right accounting unit even if every other rule passes.

Because the file is bare XML, there is no visual rendering. Contracting authorities accept that: their portals render the XML themselves with a stylesheet. Sending bare XML to a small private-sector customer without an ERP, on the other hand, usually produces a confused email asking for 'the real invoice'.

How PDF/A-3 embedding actually works in ZUGFeRD

PDF/A-3 is the archival PDF subset that, unlike PDF/A-2, permits arbitrary file attachments with an /AFRelationship qualifier. ZUGFeRD exploits exactly that. The XML is embedded as an EmbeddedFile stream, referenced from the document catalog's /AF array, and marked with /AFRelationship /Alternative — declaring that the attachment is an alternative representation of the visible page content, not merely a supplement.

The attachment filename is normative and matters: factur-x.xml for Factur-X and current ZUGFeRD versions, with zugferd-invoice.xml still seen from ZUGFeRD 2.0-era systems. Receiving software looks for that exact name. A correctly structured PDF with the XML attached under a creative filename will be treated as a plain PDF by most inbound parsers.

A second requirement is XMP metadata. The document-level XMP packet must carry the Factur-X/ZUGFeRD extension schema declaring DocumentType, DocumentFileName, Version and ConformanceLevel (the profile). Parsers use this to decide whether to trust the attachment before extracting it. Missing XMP is the second-most common cause of hybrid invoices being silently ignored.

PDF/A-3 also brings archival obligations that plain PDF does not: all fonts embedded and subsettable, device-independent colour via an output intent, no JavaScript, no encryption, no external content references. This is why a hybrid invoice cannot simply be a password-protected PDF — encryption breaks PDF/A conformance outright.

The visible page and the XML must agree. Nothing in the file format enforces that: it is entirely possible to produce a PDF showing 1,190.00 EUR while the attachment says 1,090.00. Where they diverge, the structured data is the legally relevant record in structured exchange, and the discrepancy is an audit finding waiting to happen. Generate both from one data source, never by editing the PDF afterwards.

The ZUGFeRD profile ladder

ZUGFeRD 2.x defines profiles that differ in how much of EN 16931 is populated. MINIMUM and BASIC WL carry only booking aids — totals, parties, payment terms — with no line items; they are explicitly not invoices in the VAT sense and cannot replace a paper or PDF original. BASIC adds line items but restricts some code lists. EN 16931 (formerly COMFORT) is the profile that is fully conformant with the European standard. EXTENDED adds fields beyond the norm for complex intra-group and logistics scenarios.

For anyone asking 'which profile do I generate', the answer is EN 16931 unless a specific trading partner has asked for EXTENDED. Below that profile the invoice does not satisfy the European standard, and you lose exactly the automation benefit that motivated the migration.

There is also an XRechnung-CIUS-inside-ZUGFeRD combination: a PDF/A-3 whose embedded CII payload additionally satisfies the XRechnung rules including the Leitweg-ID. This is the most portable single artefact you can produce, and it is what a well-configured invoicing pipeline should default to for German recipients.

• MINIMUM / BASIC WL — booking aid only, not a valid VAT invoice
• BASIC — line items present, restricted code lists
• EN 16931 — fully conformant, the sensible default
• EXTENDED — superset for complex logistics and intra-group cases

Validation behaves differently for each artefact

Validating bare XML is a two-stage process: XSD schema validation, then Schematron rule execution for the EN 16931 rules plus the CIUS overlay. Nearly all real-world failures come from the second stage — arithmetic that does not reconcile, a VAT breakdown entry missing for a category used on a line, an exemption reason absent on a zero-rated line, a due date before the issue date.

Validating a hybrid file adds two stages before that. First the container must be checked for PDF/A-3 conformance, typically with veraPDF. Then the attachment must be located via the /AF array and its XMP declaration cross-checked against the actual payload profile. Only then can the XML be validated normally. A hybrid invoice can therefore fail in ways a bare XML file never can: valid XML, invalid container.

Toolula's E-Invoice Reader performs the XML-side checks entirely in the browser: it accepts UBL or CII, extracts the attachment from a hybrid PDF, maps every value back to its BT identifier and lists which rules fail and why. Because the parsing runs in WebAssembly on your device, commercially sensitive invoices never leave the machine — which matters more than usual here, since invoice XML contains full customer data, bank details and margin-revealing unit prices.

A sending workflow that covers both worlds

Step one, classify the recipient. German public authority: XRechnung is mandatory, and you need the Leitweg-ID before you can even issue. EU public authority outside Germany: EN 16931 via Peppol, national CIUS may apply. Private-sector business: hybrid ZUGFeRD at the EN 16931 profile. Consumer: a plain PDF is fine, structured data is optional.

Step two, capture routing data once per customer rather than per invoice. Leitweg-ID, Peppol participant identifier, VAT identifier, required purchase-order reference (BT-13) and the delivery channel belong in the customer record. Most B2G rejections trace back to routing data being re-typed from an email each time.

Step three, generate from a single data object. Build the semantic invoice first, then serialise: to UBL or CII for bare XML, and to CII plus a rendered page for the hybrid file. Never produce the PDF in one tool and the XML in another — that is how visible and structured totals drift apart.

Step four, validate before sending, not after rejection. Run the arithmetic reconciliation, the VAT breakdown check and the profile identifier check every time. Step five, archive both artefacts together with any submission receipt, for the national retention period — generally eight years in Germany, six to ten elsewhere in the EU. In structured exchange the XML is the original; keeping only a printout is not sufficient.

Configured this way, the format question collapses into a single field on the customer record. The invoicing logic, the tax treatment and the validation routine stay identical whether the output is a bare XRechnung file or a hybrid ZUGFeRD PDF.

Frequently asked questions