EN 16931 is the European standard that defines what an electronic invoice must contain, and it now sits underneath almost every e-invoicing mandate in Europe. It has also changed. CEN approved a revised edition, EN 16931-1:2026, and the European Commission confirmed its publication in May 2026. This guide explains how the standard works, what the 2026 revision changes, and what IT and compliance teams should do about it now that France has gone live, Germany's issuing obligation is months away, and ViDA's 2030 deadlines are fixed.
EN 16931 is a series of European standardisation documents produced by CEN Technical Committee 434 under a mandate linked to Directive 2014/55/EU on electronic invoicing in public procurement. The directive required contracting authorities across the EU to receive and process e-invoices that comply with the standard, with deadlines in April 2019 for central government and April 2020 for sub-central bodies.
The core of the series, EN 16931-1, is a semantic data model. It does not prescribe an XML file. Instead, it lists the business information an invoice needs (seller, buyer, VAT breakdown, line items, totals, payment details), gives each piece a stable identifier, and sets rules on how those pieces relate to each other. Separate technical specifications then explain how to express that model in concrete syntaxes.
That separation matters. Two invoices in different XML formats can both be "EN 16931-compliant" because they carry the same business meaning, and they can be converted into each other without losing data. This is what makes cross-border e-invoicing, and the EU's future digital VAT reporting, possible.
| Document | What it covers |
|---|---|
| EN 16931-1 | Semantic data model of the core elements of an electronic invoice (2017 edition, revised as 2026 edition) |
| CEN/TS 16931-2 | List of syntaxes that comply with EN 16931-1 |
| CEN/TS 16931-3-1 to 3-4 | Methodology for syntax bindings, plus bindings for UBL, UN/CEFACT Cross Industry Invoice (CII) and UN/EDIFACT INVOIC |
| CEN/TR 16931-4 | Guidelines on interoperability at the transmission level |
| CEN/TR 16931-5 | Guidelines on sector and country extensions and CIUS |
| CEN/TR 16931-6 | Results of testing the standard in practice |
The European Commission maintains an overview of the series and the required syntaxes on its eInvoicing Digital Building Blocks pages.
If you are mapping ERP data to an e-invoice, you will spend most of your time with four building blocks of the model.
Every data element has an identifier. BT-1 is the invoice number, BT-2 the issue date, BT-5 the invoice currency code, BT-24 the specification identifier and BT-112 the invoice total including VAT. Related terms are grouped: BG-4 holds the seller, BG-7 the buyer, BG-22 the document totals and BG-25 each invoice line. Each term has a defined cardinality (mandatory or optional, single or repeating) and a data type such as amount, date, code or identifier.
Business rules make the model enforceable. Some are simple presence checks (an invoice must have an invoice number). Calculation rules, prefixed BR-CO, check the arithmetic. BR-CO-15, for example, requires the total with VAT to equal the total without VAT plus the total VAT amount. VAT category rules (BR-S for standard rate, BR-Z for zero rate, BR-E for exempt, BR-AE for reverse charge, BR-IC for intra-community supplies and others) specify which fields must be present for each tax treatment.
Many fields must use values from recognised code lists: UNTDID 1001 for document type (380 for a commercial invoice, 381 for a credit note), UNTDID 5305 for VAT category, ISO 4217 for currency and ISO 3166-1 for country codes. Code-list errors are among the most common reasons an otherwise well-formed invoice fails validation.
Under the 2017 framework, the two syntaxes every public buyer must accept are UBL 2.1 (ISO/IEC 19845) and UN/CEFACT CII D16B. A syntax binding maps each business term to a precise XML path, so a validator can check schema conformance first and then the business rules, typically with Schematron.
The core model is deliberately generic, so almost every real-world implementation layers something on top of it. There are two ways to do that.
An invoice declares which specification it follows in BT-24. Peppol BIS Billing 3.0 invoices, for example, carry a customization identifier that begins with urn:cen.eu:en16931:2017#compliant# and then names the Peppol specification. Germany's XRechnung uses the same pattern with its own identifier. That single value tells a receiving system which rule set to validate against.
The 2017 model was designed mainly for business-to-government invoicing. As Member States extended mandates to B2B transactions, gaps became visible, and the VAT in the Digital Age (ViDA) package made the standard the reference point for EU digital reporting. CEN/TC 434 therefore revised Part 1.
Industry commentary on the approved text highlights three main areas:
The most important point for IT teams is that the revision is not backward compatible. New business terms, changed rules and new syntax versions mean existing mappings, validators and templates will need to be updated. The migration will not happen overnight, though. Peppol BIS Billing 3.0 is still built on the 2017 model in its current release, and Germany's standard-setter KoSIT has announced a major XRechnung 4.0 release to align with the new model. Each specification will move on its own timeline once the syntax bindings are final.
ViDA was adopted in March 2025. For e-invoicing, it changes three things:
In practice, EN 16931 becomes the common language for EU VAT reporting. Countries are already adjusting: Italy has opened a consultation on aligning its e-invoicing system with ViDA, while newer mandates are being built around EN 16931 from the start.
EN 16931 is used differently from country to country. Some regimes adopt it directly, some build a national CIUS, some adapt it loosely, and some jurisdictions outside the EU borrow its semantics.
| Country / regime | Format(s) | Relationship to EN 16931 | Status (September 2026) |
|---|---|---|---|
| France | UBL, CII, Factur-X via accredited platforms (Plateformes Agréées) | All three base formats are EN 16931-based, with French-specific rules | Live since 1 September 2026: all businesses must receive, and large and mid-sized companies must issue. SMEs and micro-businesses must issue from 1 September 2027. |
| Germany | XRechnung, ZUGFeRD 2.0.1+ (not MINIMUM/BASIC WL) | The legal definition of an e-invoice references EN 16931 | Receiving required since 1 January 2025. Issuing required from 1 January 2027 for businesses with prior-year turnover above €800,000, and for all businesses from 1 January 2028. |
| Belgium | Peppol BIS Billing 3.0 (UBL) by default | EN 16931 CIUS. Other compliant formats are allowed by mutual agreement. | Mandatory for domestic B2B since 1 January 2026 |
| Slovakia | Peppol-based exchange | EN 16931 / Peppol BIS | B2B mandate from January 2027 |
| Poland (KSeF) | FA(3) XML structure | A national structure inspired by EN 16931 but not fully compliant and not a CIUS | Mandatory from February and April 2026 (micro-businesses from 2027), with no penalties during 2026 |
| UAE | PINT AE (Peppol International) | The shared core of PINT is based on the EN 16931 model, with UAE-specific rules | Phased rollout under the UAE's 5-corner model |
| Saudi Arabia (ZATCA) | UBL 2.1 XML | ZATCA's XML standard uses EN 16931:2017 business terms and rules, with KSA-specific fields and rules taking precedence | Phase 2 integration is rolling out in waves. Wave 25 (revenue above SAR 187,500) must integrate by 1 February 2027. |
For multinational groups, this is the practical takeaway: one EN 16931-aligned master data model in your ERP can feed most of these regimes. Each still needs its own validation layer, transmission channel and archiving rules. Our guide to Peppol e-invoicing in the UAE shows how the PINT specialisation adds local requirements on top of the shared core, and our Slovakia update covers a new EU mandate built on Peppol from the start.
For the wider picture, including tax reporting, archiving and multi-country governance, see The Complete Guide to Global E-Invoicing Compliance.
No. EN 16931-1 is a semantic data model that defines the information an invoice must contain and the rules that apply to it. Concrete file formats such as UBL and UN/CEFACT CII are linked to the model through separate syntax bindings.
Peppol BIS Billing 3.0 is a CIUS of EN 16931. It uses UBL syntax, applies all EN 16931 rules and adds Peppol-specific rules for use on the Peppol network. Every valid Peppol BIS Billing 3.0 invoice is also EN 16931-compliant, but not every EN 16931 invoice meets Peppol's extra rules.
Not immediately. The European Commission indicates that invoices following the 2017 version remain compliant during the migration period. The practical trigger will be the specifications you use, such as Peppol BIS, XRechnung and Factur-X, adopting the 2026 model. Because the revision is not backward compatible, start the impact assessment now.
A plain PDF is not. A hybrid Factur-X/ZUGFeRD file can be compliant, provided the embedded XML uses the EN 16931 profile or higher. The structured XML is what counts legally.
EN 16931 is becoming the backbone of European VAT compliance. With France live, Germany's issuing obligation starting in January 2027, a non-backward-compatible 2026 revision in circulation and ViDA's 2030 reporting deadline ahead, companies that treat the standard as shared infrastructure, rather than a per-country project, will spend less on each new mandate. Infinite IT Solutions connects your ERP to Peppol, national platforms and Gulf tax authorities with built-in EN 16931 and CIUS validation.
Contact our e-invoicing experts to review your EN 16931 readiness and plan your migration to the 2026 standard.