Blog - E-invoicing & e-document exchange | Maventa

What is EN 16931? The European e-invoicing standard explained | Maventa

Written by Taru Kuusisto | 4.2.2026

If your product handles invoicing and you operate in Europe, you'll encounter EN 16931 sooner or later. It sits at the foundation of how structured e-invoicing works across the EU, and understanding it makes everything else, from Peppol to country-specific mandates, considerably easier.

Here's what it is, how it works, and why it matters for software vendors.

The short version

EN 16931 is the European standard that defines what a valid electronic invoice must contain. Not the file format, not the transmission protocol, but the data itself: which fields are required, what they mean, and how they relate to one another.

It was published in 2017 by CEN, the European Committee for Standardisation, and mandated into law through EU Directive 2014/55/EU on electronic invoicing in public procurement. Any public sector buyer in the EU is required to be able to receive and process invoices that comply with EN 16931.

What does "semantic data model" actually mean?

EN 16931 defines a semantic data model. A semantic data model describes the meaning and structure of information, independently of how that information is technically encoded. EN 16931 specifies, for example, that an invoice must include a buyer reference, a payment due date, and a breakdown of VAT by tax category. It defines what each of those fields means and what values are valid.

What it does not specify is how those fields should be written in a file. That's intentional. The standard is format-neutral at the semantic level, which is what makes interoperability possible across different systems and countries.

So what's the actual file format?

The file format is handled by a separate part of the standard: EN 16931-2, which defines syntax bindings. A syntax binding maps the semantic data model to a specific XML format, so that software systems can actually read and write the data.

EN 16931-2 currently defines two syntax bindings:

  • UBL 2.1 (Universal Business Language), widely used across Europe and as the basis for Peppol

  • UN/CEFACT CII (Cross Industry Invoice), used notably in France's Factur-X format and ZUGFeRD in Germany

Both produce valid EN 16931 invoices. A system that can process one can, in principle, process the other, because both map to the same underlying data model.

Where does Peppol fit in?

Peppol is a network for exchanging business documents, most commonly invoices. It uses its own specification called Peppol BIS Billing 3.0, which is a CIUS (Core Invoice Usage Specification) built on top of EN 16931.

A CIUS is a country or use-case specific profile that restricts or extends the base standard for a particular context. Crucially, a CIUS can only be more restrictive than EN 16931, never more permissive. It can make optional fields mandatory, narrow the range of valid values, or add rules specific to a market. It cannot introduce data that the base standard doesn't account for.

This hierarchy matters in practice:

  • EN 16931 is the European-level standard

  • Peppol BIS Billing 3.0 is a CIUS that applies EN 16931 to the Peppol network

  • Country-specific profiles like XRechnung in Germany are CIUSes that apply EN 16931 to national requirements

     

If your product is compliant with EN 16931, it's on the right foundation. The country-specific layers are restrictions on top of that foundation, not separate standards built from scratch.

Which invoice types does EN 16931 cover?

EN 16931 covers invoices and credit notes. It does not cover purchase orders, despatch advice, order responses, or other business documents. Those fall under separate standards, most commonly ISO 20022 or the Peppol specifications for ordering.

For software vendors building out full procure-to-pay or order-to-cash flows, this distinction is important. EN 16931 handles the invoicing part of the process. The document types that surround it are governed elsewhere.

Why EN 16931 matters for software vendors

If you're integrating e-invoicing into your product, EN 16931 is the common language that makes the integration reusable across markets.

A country-by-country approach, where you build to each national format independently, works in the short term but creates compounding maintenance overhead as mandates expand and formats evolve. Building to EN 16931 gives you a stable foundation that country-specific profiles sit on top of, rather than a separate stack for each market.

It also matters for compliance planning. Every new B2B e-invoicing mandate being introduced across Europe, in Belgium, France, Germany, and beyond, references EN 16931 as the baseline. Understanding the standard means you're not starting from scratch each time a new market becomes relevant to your customers.

What's coming next

EN 16931 is not static. An update to EN 16931-1 is expected in mid-2026, driven by the EU's expansion of e-invoicing mandates from public procurement into B2B, and by the requirements that will come with ViDA (VAT in the Digital Age). The updated standard will need to handle a broader range of B2B scenarios than the original B2G-focused version was designed for.

We cover what's changing and what it means for products already live with e-invoicing in our follow-up post: EN 16931 is getting an update. Here's what changes and what it means for SaaS.

Want the country-by-country picture?

EN 16931 defines the European baseline. How each country implements it, which formats they require, what their mandate timelines look like, varies market by market. For a full breakdown, visit our e-invoicing in Europe overview.