Understanding EN 16931 E-Invoicing Standards

What EN 16931 actually standardises

EN 16931-1 defines a semantic data model: a list of business terms, each with an identifier such as BT-1 for the invoice number or BT-112 for the invoice total with VAT, plus the cardinality and business rules that govern them. It does not prescribe a file format. The same semantic invoice can be serialised as UBL 2.1 XML or as UN/CEFACT Cross Industry Invoice (CII) XML and remain equally compliant.

That separation is the most useful thing to understand. If your data is modelled correctly — the right parties, the right tax categories, the right document references — then re-serialising into whichever syntax a trading partner demands is a mechanical step. If the model is wrong, no amount of format conversion will fix it, because the receiving system will fail the business rules rather than the schema.

The rules come in two layers. Schema validation checks that the XML is structurally sound. Business-rule validation (the BR and BR-CO rules) checks the commercial logic: that line totals sum to the document total, that a VAT breakdown exists for each tax category used, that an exemption reason accompanies any zero-rated line, that a due date is not earlier than the issue date. Most rejections in practice are business-rule failures, not schema failures.

The national formats you will actually meet

XRechnung is the German CIUS — a Core Invoice Usage Specification — that narrows EN 16931 for public-sector buyers. It makes certain optional fields mandatory, most notably the Leitweg-ID buyer reference (BT-10) that routes the invoice to the correct administrative unit. Sending a technically valid EN 16931 invoice without a Leitweg-ID to a German authority will normally get it bounced.

ZUGFeRD and Factur-X are the German and French names for the same hybrid approach: a PDF/A-3 document with CII XML embedded as an attachment. A human opens the PDF and sees a normal invoice; a machine extracts the XML and books it automatically. Hybrid formats are the pragmatic default for business-to-business exchange because they do not require your customer to have adopted anything yet.

Peppol BIS Billing 3.0 is not a competing format so much as a transport and profile layer. It uses EN 16931-compliant UBL and adds an addressing scheme plus a network of access points that deliver the document. If a customer asks for your Peppol ID, they are asking how to route to you, not which XML dialect you speak.

• XRechnung — German public sector, requires Leitweg-ID (BT-10)
• ZUGFeRD / Factur-X — hybrid PDF/A-3 with embedded CII XML
• Peppol BIS 3.0 — UBL profile plus network addressing and delivery

Fields that most often cause rejections

A handful of business terms account for the majority of failed invoices. The buyer reference (BT-10) is mandatory in several CIUS profiles and is frequently left empty because paper invoices never needed it. Seller and buyer VAT identifiers (BT-31, BT-48) must be present and syntactically valid whenever the transaction is treated as intra-community, and the reverse-charge case additionally needs both parties identified plus the correct exemption reason text.

Tax category codes are another common trap. Each line carries a category — S for standard rate, AA for reduced, Z for zero-rated, E for exempt, AE for reverse charge, G for export outside the EU, K for intra-community supply — and the document-level VAT breakdown must contain exactly one entry per distinct combination of category and rate used on the lines. Mixing a reverse-charge line with a standard-rate line in one invoice is legal, but both breakdown entries must be present with the right taxable amounts.

Rounding is the quiet killer. Line net amounts, the sum of lines, allowances and charges, the taxable base per category, the VAT amount per category and the payable total all have to reconcile to the cent. Calculating VAT per line and again on the document total with different rounding rules produces a one-cent discrepancy that fails validation with an error message that rarely mentions rounding.

A validation routine before every send

Build a habit rather than a one-off check. First, confirm the mandatory identifiers: invoice number, issue date, currency, seller legal name and address, seller VAT ID, buyer name and address, buyer reference where required. Second, verify that every line has a quantity, a unit, a net unit price and a tax category, and that the line totals add up. Third, check the VAT breakdown against the categories actually used, including exemption reason text for anything not standard-rated.

Fourth, run the file through a validator that applies the EN 16931 business rules, not just the XSD. The Toolula E-Invoice Reader does this locally in the browser: it parses UBL or CII, maps fields back to their BT identifiers and reports which rules fail and why, without the document leaving your device. Fifth, archive both artefacts — the PDF and the XML — for your national retention period, which in Germany is generally eight years and elsewhere in the EU commonly six to ten.

If you adopt a hybrid format now and keep your identifiers clean, later national mandates become a configuration change rather than a migration project. That is the real payoff of getting the semantic layer right early.

Frequently asked questions