What is EN 16931?
EN 16931 is the European standard for e-invoicing. The European Committee for Standardization (CEN) published the standard in 2017 at the request of the European Commission. In March 2026, the semantic data model was revised (EN 16931-1:2026). The standard describes a semantic data model: a fixed set of information elements that together make up an e-invoice, with their meaning, their relationships and the rules they must comply with.
The direct trigger was Directive 2014/55/EU. It requires contracting authorities in the European Union to receive and process e-invoices that comply with EN 16931. For central government bodies, this obligation applied from April 2019. Sub-central authorities were allowed to wait until April 2020.
EN 16931 does not prescribe a file format. The standard defines which data an invoice contains and what that data means. How the data is recorded technically is determined by the syntax bindings, such as UBL and UN/CEFACT CII. You can read more about the individual formats on the E-invoice formats page. The standard is maintained by CEN/TC 434; in the Netherlands, the work is followed by the NEN standards committee for e-invoicing (NEN is the Dutch standardisation body), in Belgium by NBN, in Luxembourg by ILNAS, in France by AFNOR and in Germany by DIN.
Core components of EN 16931
Semantic data model
- More than 160 information elements (business terms)
- Mandatory and optional fields
- Business rules for consistency and calculations
- Support for different invoice types
Syntax bindings
- UBL 2.1
- UN/CEFACT CII
- Room for CIUS (Core Invoice Usage Specification)
- National and sector-specific extensions
Code lists
- Currency codes (ISO 4217)
- Country codes (ISO 3166)
- VAT categories
- Payment methods
Validation and compliance
- Schematron validation rules
- Business rule checks
- Syntax validation (XML schema)
- Conformance testing
Interoperability
- Mapping between UBL and CII
- Version control and stability of the model
- Alignment with international standards
- Basis for cross-border exchange
Security and integrity
- Verifiable origin through secure transport
- Integrity of the content
- Unambiguous, verifiable data
- Support for an audit trail
How does EN 16931 relate to Peppol?
EN 16931 and Peppol complement each other. EN 16931 determines what an e-invoice contains: the semantic model. Peppol determines how that invoice reaches the recipient securely and reliably: the network, the agreements and the transport infrastructure.
Within the Peppol network, Peppol BIS Billing 3.0 is the agreed invoice format. Peppol BIS Billing 3.0 is a CIUS of EN 16931. It therefore follows the standard in full and adds a number of extra agreements on top. An invoice that passes Peppol BIS validation therefore also complies with EN 16931.
What this delivers:
- One data model for public sector and business invoices
- One connection for recipients in multiple countries
- Predictable validation based on public rules
- A stable foundation as the number of trading partners grows
Where is EN 16931 used?
Almost every European e-invoicing mandate builds on EN 16931, often through its own CIUS: a specification that follows the standard and adds national agreements to it. In the Netherlands this is the NLCIUS (the Dutch CIUS), in Belgium and Luxembourg Peppol BIS Billing 3.0, in Germany XRechnung and ZUGFeRD, and in France the formats supported by the plateformes agréées (approved platforms). ViDA also uses EN 16931 as the basis for cross-border e-invoicing from 2030. See ViDA explained.
Timeline of EN 16931 and e-invoicing
- 2014: Directive 2014/55/EU calls for a European standard for e-invoicing in public procurement.
- 2017: CEN publishes EN 16931, with the semantic data model and the list of syntaxes.
- 2019–2020: Central government bodies must be able to receive and process e-invoices in accordance with EN 16931 from April 2019, sub-central authorities by April 2020 at the latest.
- 2020: Peppol BIS Billing 3.0, a CIUS of EN 16931, becomes mandatory in the Peppol network as of 18 April.
- 2025: ViDA is adopted; cross-border e-invoicing is based on EN 16931.
- 2026: On 13 March, CEN approves EN 16931-1:2026, the revised version of the semantic data model, partly with ViDA in mind. It replaces EN 16931-1:2017+A1:2019.
- 2030: Digital reporting for cross-border B2B transactions within the EU.
To find out what has happened in European e-invoicing legislation since 2020, read the ViDA explained page.
Technical specifications
| Feature | Specification |
|---|---|
| Standard | EN 16931-1:2026 (semantic data model; replaces EN 16931-1:2017+A1:2019), CEN/TS 16931-2:2017 (list of syntaxes) |
| Supported syntaxes | UBL 2.1, UN/CEFACT CII D16B |
| Document types | Invoice type codes from UNTDID 1001, including 380 (invoice), 381 (credit note) and 384 (corrected invoice) |
| Business rules | 100+ |
| Character encoding | UTF-8 |
| Identification schemes | ISO 6523 ICD list |
| Extensions | CIUS and extensions permitted |
What this means for your software
Are you a vendor of accounting, ERP, procurement or invoicing software? Then the invoices your software creates and processes must comply with EN 16931. The question is not whether you support the standard, but how. In practice, there are two routes.
Route 1: Build it yourself
You build EN 16931 validation and conversion into your software yourself. Your team implements the syntax bindings (UBL and/or CII), runs the Schematron validation, maps the internal data model to the semantic model of the standard and keeps all of this up to date whenever the standard, the CIUS or Peppol BIS is updated.
Route 2: Through a service provider or conversion service
Your software submits invoice data through an API. The service provider validates it, converts it to the correct format and handles delivery via the Peppol network. Your team does not need to maintain the details of the standard itself.
Assessment criteria
Development time
Building it yourself requires considerable development effort for mapping, validation and testing. An API integration is usually faster to implement, because the validation logic already exists.
Maintenance burden
Business rules, code lists and specifications are updated periodically. If you build it yourself, that maintenance falls to your team. Through a service provider, it is largely taken care of for you.
Required expertise
Building it yourself requires in-depth knowledge of the semantic model, Schematron, UBL and CII, and of national CIUS variants. For an API integration, knowledge of your own data model and the API is sufficient.
Speed to compliance
With a service provider, you connect to validation that is already in use. If you build it yourself, the pace depends on your own roadmap and testing capacity.
Control and flexibility
Building it yourself gives you maximum control over processing. Through an API, you depend on the capabilities and documentation of the service provider.
For integrators, the same trade-off applies per client project. For public sector organisations, this is mainly relevant when selecting suppliers and when assessing whether their receiving systems process compliant invoices correctly.
You can read how to build Peppol into your product technically on the Integrating Peppol into your software page.
Conclusion
EN 16931 is the common language of e-invoicing in Europe. Once you understand the standard, you also understand why Peppol BIS, UBL and CII fit together so closely. For your software, the next step is deciding how to support that language: yourself, or through a service provider that handles validation and conversion for you. The comparison tool on Peppol.now shows which service providers are a good fit.
