EN 16931: the semantic model of the electronic invoice
EN 16931 is the European standard that defines the mandatory data of an electronic invoice. Understanding this semantic model, and why it sits at the heart of the French reform and of the Factur-X, UBL and CII formats.
In this article
- What is the EN 16931 standard?
- The two levels: semantics and syntax
- What EN 16931 defines concretely
- EN 16931 and the Factur-X / UBL / CII formats
- EN 16931 and the French reform
- Who is concerned by EN 16931?
- Where to consult the EN 16931 standard (PDF)?
- How to check EN 16931 compliance of an invoice?
- What about Magento?
- Going further
In short: EN 16931 says which data an electronic invoice must contain, not how to write it. The three formats of the French reform - Factur-X, UBL and CII - are different ways of carrying that same model. Your job is to provide complete data; your Approved Platform produces the format.
As soon as electronic invoicing comes up, the code EN 16931 is everywhere: in the DGFiP texts, in vendor product sheets, in format documentation. It is in fact the central piece of the framework, and understanding it avoids a lot of confusion between “standard”, “format” and “platform”.
What is the EN 16931 standard?
EN 16931 is a European standard published by CEN (the European Committee for Standardization), in response to Directive 2014/55/EU on electronic invoicing. It defines a semantic invoice model: the list of information an invoice must carry, and the business rules that link them.
It does not describe a layout, nor a specific file. It describes the meaning: a seller, a buyer, lines, VAT rates, totals, references, legal mentions, etc. Each of these pieces is a Business Term (BT-xx), grouped into Business Groups (BG).
The two levels: semantics and syntax
This is the most important distinction, and the one that creates the most misunderstanding.
- The semantic level (what EN 16931 standardizes): which data, with which rules. Universal, independent of the technology.
- The syntactic level: how you write that data in a file. EN 16931 retains two XML syntaxes, UBL and UN/CEFACT CII, plus, in France, Factur-X (a PDF/A-3 that embeds the CII syntax).
In other words: the same invoice compliant with the EN 16931 model can exist as Factur-X, UBL or CII, without losing a single piece of data. The choice of format is a syntax question, not a substance one.
What EN 16931 defines concretely
- The mandatory data: seller and buyer identifiers (including SIRET in France), date, number, currency, lines, quantities, prices, VAT per rate, totals before/after tax, etc.
- The business rules: amount consistency, conditional presence of certain fields, standardized codes (units, VAT categories, etc.).
- The national extension points via the CIUS (Core Invoice Usage Specification), which restrict the standard to a precise use without leaving it.
EN 16931 and the Factur-X / UBL / CII formats
| Factur-X | UBL | CII | |
|---|---|---|---|
| Nature | PDF/A-3 + embedded XML | Pure XML | Pure XML |
| EN 16931 syntax | CII | UBL | CII |
| Human-readable | Yes (the PDF) | No | No |
| Typical use | French merchants, SMBs | PEPPOL network, Europe | International flows, PA-imposed cases |
For the details of each format and the choice per recipient, see Factur-X, UBL, CII: which format to choose.
EN 16931 and the French reform
The French reform relies on EN 16931 as a common foundation: B2B electronic invoices must carry the model’s data, and transit through an Approved Platform (Plateforme Agréée, PA). It is this shared foundation that makes invoices interoperable between companies, whatever their respective platforms.
For the timeline and obligations, see the complete guide to French e-invoicing 2026-2027 and the Approved Platform vs Compatible Solution distinction.
Who is concerned by EN 16931?
The standard was born in the public sector: Directive 2014/55/EU requires European public administrations to accept electronic invoices compliant with EN 16931. In France, this B2G circuit goes through Chorus Pro for public procurement suppliers.
The French reform extends that same foundation to domestic B2B, with the 2026-2027 timeline: mandatory reception for all companies subject to VAT from September 2026, and emission phased in by company size. Three profiles deal with the standard day to day:
- companies that issue or receive B2B invoices in France - they never have to read the standard, but their data must comply with it;
- software vendors and integrators (ERP, e-commerce, Compatible Solutions, etc.) who normalize data against the model;
- Approved Platforms, which validate that data and produce the regulatory formats.
Where to consult the EN 16931 standard (PDF)?
EN 16931 is published by CEN and distributed in France by AFNOR. The part that matters day to day is EN 16931-1, which describes the semantic model. Following an agreement between CEN and the European Commission, it is available free of charge on the AFNOR online store, after creating an account - that is the official source if you are looking for the text of the standard as a PDF.
The complementary parts (CEN/TS 16931-2 for the list of retained syntaxes, the 16931-3 series for their binding to the model) are mostly aimed at software vendors: a merchant practically never needs them.
How to check EN 16931 compliance of an invoice?
The semantic model comes with business rules (BR-xx codes): totals consistency, VAT per rate, fields required depending on context, etc. These rules are published as automatable validation artefacts (Schematron schemas maintained at the European level), and are the basis of compliance checks.
In practice, verification happens at three moments:
- upstream, in your invoicing system or your Compatible Solution, which checks the data before transmission (SIRET, VAT numbers, amount consistency, etc.);
- at the entrance of the Approved Platform, which rejects non-compliant invoices;
- on the recipient side, whose platform checks the received file in turn.
The earlier validation happens, the cheaper a rejection is: an anomaly caught before transmission is fixed in minutes, a downstream rejection delays payment. The details of statuses and rejections are covered in the lifecycle of an electronic invoice.
What about Magento?
For a merchant who invoices from Magento, the point is not to “produce EN 16931” by hand, but to ensure that the invoice data is complete and consistent with the model. A Compatible Solution such as Gatebold E-Invoice Gateway extracts the invoice emitted from Magento, normalizes its data against the EN 16931 semantic model, validates it (SIRET, VAT, totals consistency, etc.), then transmits it to the Approved Platform of your choice. The PA then produces the regulatory format (Factur-X, UBL or CII) and delivers it to the recipient.