EN 16931: The European Semantic Standard for the Core Invoice
EN 16931 explained: the European e-invoicing standard's semantic model, its two syntax bindings and its validation rules, and what it deliberately leaves open.
A structured invoice is a data model before it is a file. This section takes the model apart: the European standard EN 16931 and the numbered business terms it defines, the two XML syntaxes permitted to carry it, the core invoice usage specifications that narrow it, and the national formats that either predate it or restrict it. It is written for whoever has to explain why a document that is conformant was rejected anyway.
That question has a small number of answers and all of them are structural. A profile required a field the standard leaves optional. A code came from a list the receiver does not accept. A syntax binding put a value somewhere the receiver's mapping does not look. The pieces here are meant to be usable with an actual error message open on the screen, so each one names the layer it belongs to and the specification that governs it, and links to the source text rather than paraphrasing it. Which countries oblige any of this, and from when, is a separate matter covered in mandates and deadlines; what happens to a file once it is valid belongs to networks and transmission. Everything is listed in the library.
EN 16931 explained: the European e-invoicing standard's semantic model, its two syntax bindings and its validation rules, and what it deliberately leaves open.
Most confusion about e-invoicing standards comes from comparing things that sit on different layers. EN 16931 is a data model, UBL and CII are the XML syntaxes that carry it, and everything else is either a narrowing of the model for one community or country, or a national format that predates it.
| Standard | Layer | What it is | Where it matters |
|---|---|---|---|
| EN 16931 | Semantic model | The European standard for the core elements of an electronic invoice | Public procurement under Directive 2014/55/EU, and the base of most national profiles |
| UBL | Syntax | OASIS XML syntax permitted to carry EN 16931 | The Peppol network and many national profiles |
| CII | Syntax | UN/CEFACT XML syntax, the other permitted binding | Hybrid PDF formats and several national profiles |
| CIUS | Specification | A restriction of EN 16931 for one community or country | Every national profile below is one |
| Peppol BIS Billing 3.0 | Network profile | The CIUS used on the Peppol network, in UBL | Cross-border exchange and network-based national mandates |
| XRechnung | National profile | Germany's CIUS of EN 16931 | German public sector, and the reference for domestic business invoices |
| Factur-X / ZUGFeRD | Hybrid format | A PDF carrying an embedded CII instance | France and Germany, where a readable document is still expected |
| FatturaPA | National format | Italy's own XML schema, older than the European standard | Every invoice cleared through the Italian exchange system |
Which of these a business actually has to produce is decided by the mandate that applies to it, not by the standard. The country-by-country answer is in e-invoicing mandates by country; how an invoice built to any of them travels is in networks and transmission.
The analysis underneath the anchor piece.
What BT and BG mean on an e-invoice: the business terms and business groups of EN 16931, how a BT number is read, and the terms worth knowing by number.
Automatic processing works because values come from published lists rather than from free text. Getting the lists right is unglamorous, cheap early, and ruinous late.
A CIUS narrows the European standard; an extension goes outside it. Why the difference decides whether an invoice that conforms to EN 16931 is still rejected.
One file containing a human-readable PDF and a machine-readable invoice. It solves a real transition problem and creates one genuinely dangerous failure mode.
Italy's invoice format predates the European standard and was built for a clearance system. It works. It also shows what a country pays for not adopting the common model.
How a structured invoice tells the buyer how to pay — the payment means code, the account, the card and the mandate — and the handful of rules that reject a document when that part is wrong.
The most widely implemented European invoice profile is not a format. It is a restriction of the standard plus the rules that make delivery over a shared network possible.
One semantic model, two XML syntaxes, and a genuine architectural decision hiding behind what looks like a file-format preference.
A national profile of the European standard, maintained by a public body, versioned on a fixed cycle. It is worth understanding as a specimen as much as for its own sake.