ZUGFeRD, Factur-X, XRechnung and EN 16931 — how the pieces fit together

Anyone who starts sending electronic invoices runs into the same wall of names within a day: EN 16931, CII, UBL, ZUGFeRD, Factur-X, XRechnung, Peppol. They sound like competitors. They are not — they are layers of one stack. Once you see the layering, the whole field stops being confusing.

The foundation: EN 16931 is a meaning, not a file

EN 16931 is the European standard that defines what an invoice means: a semantic data model plus a set of business rules (the famous BR-… rules). It says an invoice has a seller, a buyer, line items, a VAT breakdown, and that the totals have to add up in a specific way. Crucially, it does not prescribe a single file format. It is the shared vocabulary everything else agrees on.

Two syntaxes: CII and UBL

The same EN 16931 model can be written down in two XML dialects: CII (UN/CEFACT Cross Industry Invoice) and UBL (OASIS Universal Business Language). They carry identical information in different tag structures. Think of them as two spellings of the same word — receivers may prefer one, but neither adds or removes meaning.

ZUGFeRD and Factur-X: the same hybrid PDF

Here is the detail that trips up almost everyone: ZUGFeRD (Germany) and Factur-X (France) are the same standard, published by two national bodies under two names. Both wrap a human-readable PDF/A-3 around an embedded CII XML file. Your accounts-payable clerk sees a normal PDF; the receiving software reads the structured data inside. One document, both audiences. The guideline identifiers even share the urn:factur-x.eu… namespace. Profiles range from MINIMUM up to EXTENDED, defining how much structured detail travels in the XML.

XRechnung: EN 16931, tightened for German public bodies

XRechnung is a CIUS — a Core Invoice Usage Specification. That is a fancy way of saying “EN 16931 with the optional bits pinned down and a few extra rules added”. It is the format German authorities require, it is pure structured XML (no PDF layer), and it is stricter than a plain ZUGFeRD EN16931 profile. A document can be valid ZUGFeRD and still fail XRechnung, because XRechnung asks for more.

Peppol: the postal network, not a format

Finally, Peppol is not a file format at all — it is the exchange network and addressing scheme that moves those XML documents between trading partners across borders. Format is what you send; Peppol is how it gets there.

Why the map matters: “looks fine” is not “is valid”

The layering explains why a file can look perfect and still be rejected. A PDF can open cleanly yet not be valid PDF/A-3. An XML can be well-formed yet break a BR- rule — a VAT breakdown that is off by a cent, an exemption without its reason code, a correction document missing its reference. The receiver’s validator will catch it; the question is only whether you catch it first.

That is the entire reason a conformance gate exists. Producing the bytes is the easy part. Proving that the result passes PDF/A-3 validation and the EN 16931 business rules — every time, before it leaves your system — is what turns “probably valid” into “provably valid”. That gate is exactly what eunormia runs on every single document, whether you use the web tool, the API or the offline SDK.