Almost every argument about European e-invoicing is an argument about a layer, conducted by people who have not said which layer they are on. EN 16931 is the layer that makes the argument possible, and it is worth understanding precisely, because the rest of this site is downstream of it.
What the standard is
EN 16931 defines the semantic data model of the core elements of an electronic invoice. Read that phrase slowly, because each part of it is doing work.
Semantic means it defines meanings, not markup. It says that an invoice has an issue date and what an issue date is. It does not say what the element is called in a file.
Data model means it defines structure: which pieces of information belong together, how many times each may occur, what type each is, and which are required.
Core elements means it defines the subset of invoice information required for cross-border interoperability, not everything an invoice could conceivably carry. Anything outside the core is somebody's extension.
The standard was commissioned under Directive 2014/55/EU precisely so that a public body in one Member State could process an invoice from a supplier in another without bilateral agreement. That is the problem it solves. It does not solve the problem of two companies wanting to exchange purchase order references in a format they invented, and it was never meant to.
The four layers
Reading upward from the bottom of the picture — from the most specific to the most general — the layers are:
- The semantic model. Business terms and groups, with cardinalities and data types. Format-independent.
- The syntax bindings. The same model expressed in a concrete XML syntax. The standard names two, examined in UBL and CII.
- The core invoice usage specification. A national or sectoral profile that narrows the standard: mandatory where the standard says optional, forbidden where the standard says permitted. Covered in CIUS and extensions.
- The receiver's own rules. Purchase order references, cost centres, tolerances, blocked suppliers. Not published, not standardised, and the layer that rejects most real invoices.
The single most useful thing this article can tell you is that conformance is tested at the top of that stack and rejection happens at the bottom of it. A document that satisfies the semantic model, the syntax and the national profile can still be refused by the buyer's own validation, and it will be.
Business terms and business groups
The model is expressed as a list of identified elements. Groups carry a BG- identifier and terms carry a BT- identifier, and both numbers are stable across versions — which is what makes them useful as a shared vocabulary between a tax administration, a software vendor and an accounts payable manager who will never read the standard.
Three properties of that model matter in practice.
Cardinality is part of the definition. Whether an element occurs once, at most once, or many times is specified, and profiles narrow it. An element the standard makes optional and a profile makes mandatory is the most common source of a rejection that surprises people. The mechanics are in reading a BT number.
Values are frequently constrained to code lists. Country, currency, unit of measure, tax category, allowance and charge reason, document type — all of these are drawn from published lists rather than free text. That is what makes automatic processing possible and it is where most master data work lands. See code lists, identifiers and the schemes behind them.
Identifiers are qualified by schemes. An identifier without a scheme is a number with no meaning: it tells a receiver what to look up but not where. This is the basis of the whole addressing problem examined in addressing on Peppol.
One group, taken apart
An abstract description of a model persuades nobody, so take a single group and look at what it actually demands.
Consider the group that carries the seller. It is not one field. It contains a name — and, separately, a legal registered name, which are different things and are frequently different strings. It contains a postal address, which is itself a group with country, town, postcode and street components in separate elements rather than in one line of text. It contains identifiers: a VAT identifier, which is qualified by a scheme, and potentially a legal registration identifier from a different scheme. It contains an electronic address, which is again a scheme and a value.
Now count the ways a customer master that has served a business perfectly well for a decade fails against that. The account was set up under a trading name rather than a registered one. The address is held as three free-text lines because that is what fitted on the printed invoice. The VAT identifier was typed from an email and never verified. The electronic address does not exist as a concept anywhere in the system.
None of those are defects in the old sense. Every one of them produces a document that a receiver refuses, and the fix is not in the invoicing software.
That is the general shape of the work, and it is why the model rewards being read early: each group is a specification of data you are about to discover you do not hold in the form required. Master data remediation is the standard, read as a to-do list.
Cardinality and data types reject more documents than missing fields do
There is an intuition that validation failures are about absence — a required field left blank. In production they are more often about shape.
A data type says what kind of value an element takes, and the constraint bites in unglamorous ways. A quantity has a decimal representation and a precision. An amount has a currency attached and a permitted number of decimal places, and rounding a line total in your own ledger convention can produce a document that fails an arithmetic rule while being commercially correct to the penny. A date has one permitted format, and a system that emits a locale-specific one produces an unambiguous error at the first gate. A text field has a maximum length, which is discovered by the first customer whose legal name is long.
Cardinality bites differently. An element permitted once and supplied twice is a structural failure. An element permitted many times but constrained by a rule about the combination — two allowances at document level with the same reason code, say — is a semantic failure, and the message that reports it is considerably less obvious.
The practical consequence is that a test corpus built from tidy examples validates nothing useful. What exercises cardinality and data types is the awkward document: many lines, mixed tax treatments, an allowance and a charge on the same line, a rounding difference between line sum and document total, and a counterparty whose name contains an accented character. That is why the test corpus is built from the difficult cases rather than from the representative ones.
Business rules, and why they matter more than the schema
A schema tells you an element exists and what type it is. It cannot tell you that a total must equal the sum of the lines, that a VAT breakdown entry is required for every category present in the invoice, or that an exemption reason must be given when a zero rate is used.
Those are business rules, and the standard carries them in a form that can be executed. In practice they are the second gate an invoice passes.
The distinction is worth being precise about because it changes how you test. Testing against a schema tells you whether your file is well-formed and structurally valid. It tells you almost nothing about whether it will be accepted. A test suite built on schema validation alone will pass everything and predict nothing, which is the subject of testing against a real validation stack.
| Gate | Catches | Misses |
|---|---|---|
| Schema | Wrong element, wrong type, wrong order | Every arithmetic and consistency error |
| European rules | Totals, VAT breakdown coherence, required reasons | Anything a profile added |
| Profile rules | Nationally mandatory fields, forbidden elements | The buyer's own requirements |
| Receiver rules | Missing order reference, unknown cost centre | Nothing — this is the last gate |
What the standard deliberately does not do
This is where most disappointment originates.
It does not define transport. How the document travels is a separate question, answered by four-corner or five-corner architectures and by national platforms. The standard is silent, deliberately.
It does not define archiving. What you keep, in what form, for how long, is set by the VAT directive and by national law. See archiving a structured invoice.
It does not define signatures or seals. Assurance of authenticity and integrity is a separate regime, and the standard neither requires a seal nor forbids one.
It does not carry everything a business wants to send. Attachments are supported within limits, and rich commercial data — detailed logistics, complex rebate structures, sector-specific product identifiers — mostly is not. That is what an extension is for, and an extension is by definition something a conforming receiver need not understand.
How to use the standard in practice
Four rules that survive contact with real implementations.
Build to the model, not to a country. Produce one internal representation of an invoice that carries every business term you will ever need, and derive each national target from it. The alternative — a separate build per country — is a maintenance cost that grows linearly with your footprint. This is the point made concretely by Belgium's approach and, negatively, by Italy's national format.
Treat the profile as the requirement. Nobody validates against the bare standard. Whatever national profile applies is the thing to build and test against.
Assume the receiver adds rules. Budget for them. They are not published, they arrive as rejections, and they are the reason a go-live with three friendly customers tells you nothing about a go-live with three thousand.
Do the code lists first. Unit of measure, tax category, country and currency codes are cheap to fix in a spreadsheet and expensive to fix in production. They are also the part of master data remediation that can begin before any decision about software has been taken.
EN 16931 tells you what an invoice means; a profile tells you what a country will take; a receiver tells you what it will accept. You have to satisfy all three, and only the first one is a standard.
Where this leads
If your next question is about file formats, read UBL and CII. If it is about why a conforming invoice was rejected, read CIUS and extensions. If it is about how a hybrid PDF fits in, read Factur-X and hybrid invoices. If it is about what a network profile adds on top, read Peppol BIS Billing 3.0.
