EN 16931 explained: the EU standard behind e-invoices

EN 16931 is the European standard for electronic invoices. It defines which details an invoice carries and how each is defined, as numbered business terms and business rules, and that content can be written in two XML syntaxes: UBL and UN/CEFACT CII.

The name turns up everywhere once e-invoicing reaches your country: in tax authority guidance, in software release notes, in the small print of a customer's supplier requirements. This guide explains what the standard is, where it came from and what it means for a business that sends invoices.

Where EN 16931 comes from

In April 2014 the EU adopted Directive 2014/55/EU on electronic invoicing in public procurement. Its aim was simple to state: a supplier anywhere in the EU should be able to send an electronic invoice to a public body anywhere else, without a different format for every country. To make that possible, the directive called for a common European standard at the level of meaning, not just file layout.

The European Committee for Standardization, CEN, developed that standard at the Commission's request and published it in 2017. Public contracting authorities then had to be able to receive and process e-invoices that follow it from 18 April 2019, with the option of extra time until 18 April 2020 for sub-central authorities such as regions and municipalities.

What the standard is made of

EN 16931 is a family of documents rather than one file. The 2017 publication came in six parts:

PartKindWhat it covers
EN 16931-1StandardThe semantic data model of the core elements of an electronic invoice
CEN/TS 16931-2Technical specificationThe list of syntaxes that comply with part 1
CEN/TS 16931-3Technical specificationsSyntax bindings: how each term maps onto UBL 2.1, UN/CEFACT CII and UN/EDIFACT
CEN/TR 16931-4Technical reportInteroperability at the transmission level
CEN/TR 16931-5Technical reportGuidelines for sector or country extensions
CEN/TR 16931-6Technical reportResults of testing the standard in practice

Part 1 is the heart of it. A revised edition of part 1 was published in 2026. The 2017 text is withdrawn but stays acceptable during a migration period, so check which edition a requirement or a piece of software refers to.

Business terms and business rules

The semantic model gives every piece of invoice information a name, a definition and an identifier. Single values are business terms, numbered BT; related terms are gathered in business groups, numbered BG. A few you will meet often:

  • BT-1 invoice number, BT-2 issue date and BT-3 invoice type code;
  • BT-5 invoice currency and BT-9 payment due date;
  • BT-27 seller name and BT-44 buyer name;
  • BG-8 the buyer's postal address and BG-25 an invoice line;
  • BT-24 the specification identifier, which says which rules the invoice follows.

Business rules then say how the terms must behave. They have identifiers too: BR-02 says an invoice shall have an invoice number, and BR-CO-15 says the total with VAT equals the total without VAT plus the total VAT. When an e-invoice is rejected, the message usually names one of these rules, which is why the identifiers are worth recognizing.

Which of these values a sender actually has to collect for a Peppol invoice is listed in the fields a Peppol invoice needs. The underlying content is close to what a paper VAT invoice already has to show, as the invoice checklist describes; the standard gives each item a fixed meaning so software can read it.

Meaning before syntax

Part 1 doesn't prescribe a file format. It describes content, and the syntax bindings say how to write that content down. For e-invoices under the directive, two XML syntaxes are recognized: OASIS UBL and UN/CEFACT Cross Industry Invoice. An invoice in either one can carry the same business terms, so a receiver that understands the model can read both.

That split explains a lot of the vocabulary you see in practice. A German format, a French format and a Peppol invoice can look different on disk and still meet the same European standard, because they share the model underneath. Why a PDF is not an e-invoice shows where a PDF falls short of this, and Germany's e-invoicing timeline is one country's example.

CIUS and extensions

The core model is deliberately general. Communities that need tighter rules publish a core invoice usage specification, a CIUS, which keeps the model and narrows the choices: certain terms become mandatory, certain code lists shorter. An invoice that meets a CIUS still meets the standard. Communities that need extra information can instead define an extension, which adds terms the core model lacks; part 5 gives the guidelines for doing that.

The best-known CIUS is Peppol BIS Billing, used on the Peppol network. Peppol BIS Billing explained walks through such a file, and what Peppol is covers the network that carries it.

Who has to follow EN 16931

  • Public bodies in the EU have to be able to receive and process invoices that follow it, under the 2014 directive.
  • Suppliers to public bodies are, in many countries, asked or required to send them, depending on national law.
  • Businesses invoicing other businesses are not covered by the 2014 directive itself. Several countries now require structured invoices between businesses based on the standard, and the EU's ViDA package moves cross-border trade the same way; VAT in the Digital Age explains the timeline.

For many small businesses the practical question is not the standard itself but whether their invoicing software can produce a compliant e-invoice in the format their customers and country expect. The standard is the shared vocabulary that makes that question answerable.

Frequently asked questions

Is EN 16931 mandatory for businesses?

Not by the 2014 directive, which addresses public procurement. National laws in a growing number of EU countries do require e-invoices between businesses that follow the standard, so check the rules where you and your customers are based.

What is the difference between EN 16931 and UBL?

EN 16931 defines what an invoice says. UBL is one of the XML syntaxes it can be written in; UN/CEFACT CII is the other. One describes meaning, the other the file.

Where can I get a copy of the EN 16931 standard?

The standard is sold through CEN's national members, the standards bodies of each country. The European Commission publishes free supporting material, such as validation files, code lists and examples, in its registry for implementing the standard.

What does CIUS mean in e-invoicing?

Core invoice usage specification: a set of extra rules that a community applies on top of EN 16931, narrowing its options without breaking it. Peppol BIS Billing is a common example.

Run your business on Apple.

Create your account on the web, then set up your workspace in the app on your iPhone, iPad or Mac.

Create your account

Keep reading

  1. What a Peppol invoice must contain: the required fields

    A Peppol BIS Billing invoice needs the EN 16931 basics (number, date, currency, both parties with addresses, totals, lines with a VAT category) plus Peppol's own rules: an electronic address for seller and buyer, and a buyer reference or purchase order reference.

  2. What must an invoice include? A checklist for EU sales

    An EU VAT invoice needs a date, a sequential number, both parties' names and addresses, your VAT number, a description and quantity of what you sold, the taxable amount, VAT rate and VAT due. Cross-border sales add the customer's VAT number and a reverse-charge note.

  3. Why a PDF invoice is not an e-invoice

    A PDF invoice is not an e-invoice. A PDF is a document for people to read, while an e-invoice is structured data, such as a UBL file following EN 16931, that the customer's software can read without retyping.