EN 16931 Explained: The European E-Invoicing Standard After the 2026 Revision

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.

What is EN 16931?

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.

The documents in the EN 16931 series

The European Commission maintains an overview of the series and the required syntaxes on its eInvoicing Digital Building Blocks pages.

How the EN 16931 semantic model works

If you are mapping ERP data to an e-invoice, you will spend most of your time with four building blocks of the model.

Business terms (BT) and business groups (BG)

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 (BR)

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.

Code lists

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.

Syntaxes: UBL and CII

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.

CIUS and extensions: how countries and networks adapt EN 16931

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.

• CIUS (Core Invoice Usage Specification): narrows the standard. A CIUS can make optional fields mandatory, restrict code lists or add stricter rules, but it cannot add new elements. An invoice that conforms to a CIUS still conforms to EN 16931.
• Extension: adds elements the core model does not contain, such as sector-specific data. Extensions give more flexibility but reduce out-of-the-box interoperability, because a receiver that only supports the core may ignore the extra data.

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.

Common EN 16931 implementations

• Peppol BIS Billing 3.0: the CIUS used across the Peppol network in Europe, in UBL syntax. OpenPeppol publishes the specification, rules and code lists at docs.peppol.eu, and its current release is dated May 2026. It adds Peppol-specific rules, such as requiring either a buyer reference or a purchase order reference.
• XRechnung: Germany's national CIUS, available in UBL and CII.
• Factur-X / ZUGFeRD: a hybrid format that embeds CII XML in a PDF/A-3 file. Its EN 16931 profile (and higher) is compliant. The lighter MINIMUM and BASIC WL profiles are not full invoices under the standard.
• National CIUS for public procurement: many Member States publish their own, for example Austria's layered CIUS for national and federal use.

What changes with EN 16931-1:2026

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.

Timeline of the revision

• February 2026: CEN approved the revised EN 16931-1, with Member States voting unanimously in favour.
• March 2026: the definitive text was released to national standardisation bodies for national publication.
• May 2026: the European Commission's eInvoicing pages confirm that the 2026 version was published and the 2017 version formally withdrawn. The Commission notes that invoices following the 2017 version remain compliant during the migration period.
• Mid-2026: updated syntax bindings, based on UBL 2.5 and CII D25A, were scheduled for a formal CEN vote.

Key content changes

Industry commentary on the approved text highlights three main areas:

• Fixes to legacy design gaps: clarifications for certain VAT category combinations and item-level details that caused avoidable validation failures under the 2017 rules.
• Richer B2B functionality: support for multiple purchase orders or delivery notes on one invoice, multiple buyer references, additional party identifiers, more detailed payment terms (including early payment discounts and late payment charges), and clearer handling of corrective invoices and foreign currency amounts.
• ViDA readiness: data structures that let an invoice serve as a reliable, machine-readable source for automated VAT controls and digital reporting.

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.

EN 16931 and ViDA: why the standard becomes mandatory infrastructure

ViDA was adopted in March 2025. For e-invoicing, it changes three things:

• Domestic mandates no longer need an EU derogation. Member States can require structured e-invoices for domestic transactions, and customer acceptance is no longer a condition for mandated e-invoices.
• From 1 July 2030, intra-EU B2B transactions fall under digital reporting requirements (DRR). Invoices must be issued as e-invoices that follow the European standard, within 10 days of the chargeable event, and transaction data must be reported to tax authorities.
• By 1 January 2035, domestic e-reporting systems introduced before ViDA must converge with the EU model.

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.

How EN 16931 applies in current EU and MEA mandates

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.

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.

EN 16931 implementation checklist for IT and compliance teams

1. Map your invoice data to business terms. Build a field-level mapping from ERP tables to BT and BG identifiers, and flag mandatory terms your system does not store today, such as buyer reference, VAT exemption reason codes or seller electronic address.
2. Inventory the specifications you must support. List every country, network and CIUS you invoice into (Peppol BIS, XRechnung, Factur-X, French platform rules, PINT AE and others), along with the syntax and version each one requires.
3. Validate before sending, not after rejection. Run XML schema validation, EN 16931 Schematron rules and CIUS-specific rules as part of invoice generation. Treat BR-CO calculation errors and code-list errors as blocking.
4. Plan the 2026 migration now. Assess which new 2026 business terms (multiple order references, payment terms, corrective invoice data) your processes will use. Keep mappings versioned so you can run 2017-based and 2026-based outputs side by side during the transition.
5. Separate the data model from the transport. EN 16931 defines content, not delivery. Peppol access points, national platforms and clearance portals each have their own onboarding and security requirements.
6. Monitor specification releases. Peppol, KoSIT, French authorities and Gulf tax authorities publish updates on separate schedules. A tool like the Infinite Compliance Tracker helps you catch changes before they break production invoicing.

For the wider picture, including tax reporting, archiving and multi-country governance, see The Complete Guide to Global E-Invoicing Compliance.

Frequently asked questions about EN 16931

Is EN 16931 a file format?

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.

What is the difference between EN 16931 and Peppol BIS Billing 3.0?

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.

Do I need to switch to EN 16931-1:2026 immediately?

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.

Is a PDF invoice EN 16931-compliant?

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.

Get EN 16931 right once, and reuse it everywhere

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.