EN 16931 is not a file and not a format. It is a list of what an invoice must carry for a machine to process it — plus a set of rules that check whether the result hangs together. Everything you can actually hold — ZUGFeRD, Factur-X, XRechnung, Peppol — is an implementation of that one list.
It was written by CEN, the European Committee for Standardization, in response to Directive 2014/55/EU. The brief was narrow: public authorities across Europe should be able to receive invoices under one set of rules rather than each country under its own.
What the model describes
The standard names the meaning of each piece of information and leaves the spelling open. “Seller name” is BT-27, “invoice line” is BG-25 — in every syntax, in every country. Which fields exist and where they end up in the file is covered in XML structure.
It covers: identification and tax numbers of seller and buyer, invoice number and dates, lines with quantity, unit and price, allowances and charges, tax categories and amounts, payment terms and the totals — each tied to the question of when the information is mandatory and when it is not.
Two syntaxes, one meaning
The model maps onto two XML syntaxes, and both are equally valid:
- CII (Cross Industry Invoice, from UN/CEFACT) — the syntax ZUGFeRD and Factur-X use exclusively.
- UBL (Universal Business Language, from OASIS) — common across the Peppol network.
They describe the same facts with different element names. Converting between them is possible at the level of field mapping with no loss of meaning; anyone working in both worlds can pour the same data into either shape.
For most businesses this is an implementation detail. Only one thing matters: that the route you send over supports the syntax your recipient expects. That is dictated by the channel, not by the quality of the data.
CIUS and extensions: how countries adapt the standard
The standard on its own leaves a lot open. Countries, industries and networks therefore narrow it through a CIUS — a Core Invoice Usage Specification. A CIUS may:
- make fields mandatory that the standard leaves optional;
- shorten code lists;
- add validation rules.
What it may not do is invent new fields. Anyone needing that builds an extension instead — and that is precisely the distinction visible in the profile identifier: #compliant# marks a CIUS, #conformant# an extension (see Profiles).
CIUS include Germany’s XRechnung, Peppol BIS Billing 3.0 and the ZUGFeRD BASIC profile. The EXTENDED profile, by contrast, is an extension. This is where the national rule codes that appear in validation reports alongside the European ones come from — BR-DE-* for Germany, BR-FR-* for France.
How conformity is checked
Being conformant does not mean the file opens. Validation happens on two levels:
- The schema (XSD) — is the XML well-formed, is every element in its place, does every value have the right data type? This level is strict about form and blind to sense.
- The business rules (Schematron) — do the totals add up, does every tax category carry a rate that is allowed for it, is the seller identifiable? This is where most real rejections happen.
For hybrid files a third level comes first: the PDF/A-3 container. How the three interact is in How validation works; the rule families and the codes that actually turn up are in Business rules.
You can check a file with us without signing up — against the schema and the business rules, using the rule set of the profile the file itself declares.
The 2026 revision
The 2017 edition was designed for public procurement. For B2B trade and for digital VAT reporting under ViDA it does not stretch far enough, so CEN reworked the model.
| Step | When |
|---|---|
| CEN adopts the revision (unanimously, 17 states) | 13 February 2026 |
| Final text | 18 March 2026 |
| Published as EN 16931-1:2026; the 2017 edition is withdrawn | May 2026 |
| Binding for intra-Community B2B transactions | 1 July 2030 |
What has been added visibly targets tax administration and the trade cases missing in 2017:
- bank details become mandatory (IBAN as its own field) — so that the payment flow behind an invoice can be traced;
- an indicator for the triangulation simplification where it applies;
- sequential numbering of corrective invoices;
- more commerce: several purchase orders per invoice, early-payment discounts, late-payment charges, foreign currency details;
- more tax cases: a wider range of exempt supplies and national special schemes such as margin taxation;
- a goods/services indicator and the time of invoice issuance.
The revision is not backward compatible. New business terms, changed validation rules and updated bindings to CII and UBL mean an existing implementation cannot simply absorb the new documents. That is why four years sit between publication and obligation.
Why validation still runs against the 2017 edition
A fair objection: if the 2017 edition has been withdrawn, why does every ZUGFeRD file still say urn:cen.eu:en16931:2017, and why do validators check against it?
Because the standard and the formats implementing it do not move in step. ZUGFeRD 2.5.2 and Factur-X 1.09.2 — the editions in force since 1 September 2026 — rest on the 2017 model. A file built to the 2026 model is something nobody could receive today, because the matching schemas and rules do not yet exist in the formats. The revision reaches you when FeRD and FNFE-MPE adopt it in a release; a next ZUGFeRD release is expected in autumn 2026.
In practice: keep validating against what is in force. And plan for the additional fields before the formats switch — above all the bank details, which in many invoice templates still live as a line of text in the footer rather than as a field.
Frequently asked questions
Is EN 16931 a file format?
No. It is a data model with rules. The file formats are ZUGFeRD, Factur-X, XRechnung and Peppol BIS — they implement the model.
Is CII better than UBL?
No, they are two spellings of the same content. Which one you need is decided by the recipient, or rather by the network they receive on.
What is the difference between a CIUS and an extension?
A CIUS narrows the standard — more mandatory fields, shorter code lists, extra rules, but no new fields. An extension adds fields the standard does not know. In the profile identifier you see it as #compliant# versus #conformant#.
Do I need to do anything about EN 16931-1:2026 now?
Keep issuing and validating as before — the formats still rest on the 2017 edition. What you can prepare: get the details that become mandatory into your master data cleanly, the IBAN first of all.
Does the standard apply outside the EU?
It is binding through EU law. Beyond that it gets used as a model because it is the most widely adopted one — a recipient in a third country may accept an EN 16931 invoice, but is not obliged to.
Why does my invoice fail when every field is filled in?
Because the second level does not check presence, it checks consistency: totals, tax categories, rounding. The most frequent codes and their causes are in Business rules.
What does ViDA mean for the standard?
ViDA is the reason for the revision: if VAT is to be reported digitally, the invoice has to carry the necessary details in structured form. Which is why the 2026 edition grows mainly in the tax-relevant fields.
In short
- EN 16931 is a model of meaning, not a format. Formats are its implementations.
- Two syntaxes: CII (ZUGFeRD, Factur-X) and UBL (Peppol). Equally valid, convertible into one another.
- A CIUS narrows, an extension adds — and both are visible in the profile identifier.
- Validation runs on two levels: schema and business rules. The second one is what rejects you.
- EN 16931-1:2026 is published, not backward compatible, and binding for intra-Community B2B from 1 July 2030.
- The formats still carry the 2017 edition today — the revision arrives through future format releases.
Want to check an invoice against the rules in force? Upload it without signing up — or create a free account and produce conformant documents correctly from the start.