ZUGFeRD: the hybrid format of PDF and XML explained

One file, two readers

The idea behind ZUGFeRD answers a practical problem: accounting wants data, the human wants a document. Two separate files mean two routes, two archives and eventually two versions of the truth.

ZUGFeRD puts both in one file. What you see is an ordinary PDF. Embedded inside it is a complete XML invoice. Someone who receives the file by email and opens it sees the document. Someone who drops it into an accounting system gets fields.

1invoice.pdf  (PDF/A-3)
2├── visible pages              → for the human
3└── factur-x.xml (embedded)    → for the machine (CII syntax)

The carrier is PDF/A-3. That is not an arbitrary choice: PDF/A-3 is the only PDF flavour that permits embedding arbitrary files while remaining suitable for archiving.

The XML is the original

This ordering matters more than it sounds. In a ZUGFeRD file the embedded XML is the authoritative part; the visible PDF is its rendering.

Two consequences follow:

🔴 Divergence is a real fault. If the PDF shows 1,190 € and the XML carries 1,109 €, the human checks one and the machine books the other. Both happen without anyone raising an objection.

🔵 What you retain is the whole file. A printout is not enough, and neither is an extracted XML without its PDF — the original is the combination.

The profiles decide

Not every ZUGFeRD file is an e-invoice. The format defines tiered profiles that set how much structured information travels along:

MINIMUM and BASIC WL were created as booking aids, not as invoices. They carry barely more than sender, totals and date. A file in those profiles looks like an e-invoice, carries the marque and opens normally — and a validating recipient turns it away.

Anyone meeting the e-invoicing obligation should specify EN 16931 as the floor.

ZUGFeRD, XRechnung, Factur-X

The three names confuse because they sit on different levels:

• XRechnung is a rule set (a CIUS) and technically pure XML.
• ZUGFeRD is a file format — a PDF with embedded XML.
• Factur-X is the same standard as ZUGFeRD under a French name.

They do not exclude one another. The ZUGFeRD profile XRECHNUNG produces a file that is both: a readable PDF and a conformant XRechnung. For companies invoicing public authorities and business customers alike, that is how you get by with one output format.

Where it goes wrong in practice

The XML is derived from the PDF. Taking a finished PDF and reading the values back with text recognition produces an XML built from guesses. The right direction is the opposite: PDF and XML are generated together from the structured data.

The profile is chosen too small. Often because MINIMUM was the fastest to implement and nobody checked later whether it was sufficient.

The recipient only sees the PDF. Some intake processes treat a ZUGFeRD file like an ordinary PDF and ignore the embedded data. That is not a fault in your file — but it explains why a recipient asks for data despite receiving an e-invoice.

The file is not PDF/A-3. An ordinary PDF with an attachment is not enough. Without PDF/A-3 conformance the check fails before the XML is even read.

Validating

For ZUGFeRD a validator checks two things separately: whether the PDF shell is PDF/A-3 conformant, and whether the embedded XML satisfies the rules of its profile. The two can fail independently — and the message tells you which of them is meant.