What Is EN 16931? The European E-Invoice Standard Behind XRechnung and ZUGFeRD

Every compliant German e-invoice, whether XRechnung or ZUGFeRD, is built on the same foundation: EN 16931, the European norm for electronic invoicing. Understanding what this standard defines makes the whole format landscape much less confusing, because the formats are just different packagings of the same data model.

Where EN 16931 comes from

EN 16931 was developed by the European standardization body CEN following EU Directive 2014/55/EU, which required public authorities across the EU to accept electronic invoices. Instead of every country inventing its own format, the directive mandated one common semantic standard. Germany then reused this standard when it defined the domestic B2B e-invoice in the Wachstumschancengesetz: an E-Rechnung is, by default, an invoice conforming to EN 16931.

What the standard actually defines

EN 16931 is primarily a semantic model. It specifies the business terms an invoice consists of, each with an identifier like BT-1 (invoice number), BT-9 (payment due date) or BT-31 (seller VAT identifier), whether each term is mandatory, optional or conditional, how many times it may appear, and how the terms group together, for example into seller data, buyer data, invoice lines and the VAT breakdown. It also defines calculation rules, such as how line totals, allowances, charges and VAT amounts must add up.

• A core set of roughly 160 business terms covering parties, dates, references, line items, VAT and totals.
• Cardinality rules: which fields are required, which are optional, which may repeat.
• Business rules that validators check, for instance that the sum of line net amounts matches the invoice total.
• Code lists, for example VAT category codes such as S, Z, E, AE, K and G.

CII and UBL: two syntaxes, one meaning

The standard deliberately separates meaning from file format. EN 16931 data can be serialized in two permitted XML syntaxes: UN/CEFACT Cross Industry Invoice (CII) and OASIS UBL 2.1. An XRechnung can be written in either syntax, and ZUGFeRD uses CII for its embedded XML. Both express exactly the same business terms, so which syntax you use is mostly a question of what the recipient's system prefers; the content is equivalent.

CIUS: national profiles like XRechnung

Countries and sectors can tighten the standard through a CIUS, a Core Invoice Usage Specification. A CIUS may make optional fields mandatory or restrict allowed values, but it can never contradict the core standard. XRechnung is Germany's CIUS: for example, it requires a Buyer Reference (BT-10), which carries the Leitweg-ID for public-sector invoices, and it requires seller contact details that the base standard leaves optional.

Why conformance matters in practice

Recipients and portals validate incoming invoices against the EN 16931 rules and, where applicable, the XRechnung rules. An invoice that breaks a business rule, a missing mandatory field, a VAT total that does not add up, an invalid code, gets rejected before a human ever sees it. Conformance is therefore not a formality; it decides whether you get paid without a second round.

The practical fix is to validate while writing, not after sending. The E-Rechnung app checks every required EN 16931 field as you type and exports XRechnung XML in CII or UBL 2.1, or a ZUGFeRD/Factur-X PDF. For the full list of data your invoice must carry, see the required fields guide.

This article is general information about a technical standard, not tax or legal advice. For questions about your specific invoicing obligations, consult your Steuerberater.