How many business rules does EN 16931 have?

More than 200, falling into recognisable families. Integrity and conditional rules require certain fields and make some mandatory only when others are present. Calculation rules (often marked "CO") enforce the arithmetic: line amounts sum to the total, VAT total equals the sum of the breakdown, grand total equals net plus VAT. VAT category rules govern what must and must not be present for standard-rated, zero-rated, exempt, reverse-charge, and other categories. Further rules govern code lists and decimal precision. These are what separate a well-structured invoice from a genuinely valid one.

A Core Invoice Usage Specification is a specialisation that narrows the EN 16931 core without stepping outside it. A CIUS can make an optional element mandatory, restrict a code list to a subset, or add business rules, but it cannot contradict or exceed the core model, so an invoice conforming to a valid CIUS is still conforming to EN 16931. This is the mechanism behind Peppol BIS Billing, German XRechnung, Dutch NLCIUS, and Norwegian EHF. Each is identified by the specification identifier (BT-24) the invoice declares, and each shares the urn:cen.eu:en16931:2017 stem.

EN 16931 Explained: The Standard Behind EU E-Invoices

Q: Is EN 16931 a file format?

No. EN 16931 is a semantic standard, not a file format, and that is the most important thing to grasp about it. UBL and CII are syntaxes (ways of writing an invoice in XML), Factur-X and ZUGFeRD are container formats, and Peppol is a network. EN 16931 is none of these: it defines the meaning of an invoice, what information it must carry, what each piece means, and the rules that must hold between them, independently of how the invoice is written down. It was created by CEN (committee CEN/TC 434) in response to Directive 2014/55/EU.

Q: What is a business term (BT) in EN 16931?

A business term is a single piece of invoice information, identified by a number. The invoice number is BT-1, the issue date is BT-2, the currency code is BT-5, the seller name is BT-27, the buyer name is BT-44. There are roughly 160 business terms, and together they enumerate everything a standardised European invoice can contain. Business groups (BG) bundle related terms into nested structures such as the seller's details, an invoice line, or a VAT breakdown. The business terms are the shared language; the syntaxes are just different alphabets for writing it down.

Q: Which syntaxes does EN 16931 support?

Two. EN 16931 defines the semantic model once and binds it to UBL 2.1 and UN/CEFACT CII (D16B). Every business term has a defined location in each syntax: BT-1 (the invoice number) has a specific home in UBL and a specific home in CII, and the semantic content is identical, only the XML path differs. This is why the same standard can appear in two different formats and why an invoice can be converted between syntaxes without losing meaning. At the semantic level there is only one standard; the syntaxes are downstream of it.

Q: What does "EN 16931 compliant" actually mean?

An invoice is EN 16931 compliant when it carries the required business terms, expressed in one of the two permitted syntaxes (UBL or CII), and satisfies the business rules, including those of any CIUS it declares. Compliance is therefore a combination of the vocabulary (the right information), the syntax (a valid binding), and the logic (all the rules pass). The formats and networks differ, but the compliance question is always the same one, asked against this standard.

What EN 16931 actually is

EN 16931 is a semantic standard, not a file format. This is the single most important thing to grasp about it, and it is what makes it different from everything else covered in this series. UBL and CII are syntaxes, ways of writing an invoice in XML. Factur-X and ZUGFeRD are container formats. Peppol is a network. EN 16931 is none of these. It defines the meaning of an invoice: what information an invoice must carry, what each piece of information means, and the rules that must hold between them, entirely independently of how the invoice is written down.

It was created by CEN, the European Committee for Standardization, through its technical committee CEN/TC 434, in response to Directive 2014/55/EU on electronic invoicing in public procurement. The directive required a common European standard for the semantic content of an electronic invoice, so that public bodies across the EU could receive invoices against one shared model rather than a different one per country. EN 16931-1:2017 is the result: the core semantic data model for an electronic invoice.

Because it defines meaning rather than form, EN 16931 is what makes interoperability possible. Two invoices written in different syntaxes, sent over different networks, in different countries, can still carry exactly the same standardised information, because they are all built on the same semantic model.

The vocabulary: business terms and business groups

The core of EN 16931 is a controlled vocabulary of invoice information, expressed as business terms and business groups.

A business term (BT) is a single piece of invoice information, identified by a number. The invoice number is BT-1. The invoice issue date is BT-2. The invoice currency code is BT-5. The seller name is BT-27. The buyer name is BT-44. There are roughly 160 such business terms, and together they enumerate everything a standardised European invoice can contain, from header identifiers to line-level details to payment instructions.

A business group (BG) bundles related business terms into a meaningful structure. The seller's details form a group, the buyer's details another, each invoice line another, each VAT breakdown another. Groups can contain both individual business terms and other groups, giving the model a nested structure that mirrors how invoice information naturally clusters.

This vocabulary is the heart of the standard. When any format in this series is described as carrying a particular field, that field is a business term from this list. The business terms are the shared language; the syntaxes are just different alphabets for writing it down.

The logic: business rules

A vocabulary alone would tell you what an invoice can contain but not whether a given invoice is correct. That is the job of the business rules, and they are where EN 16931 has real teeth. There are more than 200 of them, and they fall into recognisable families.

Some are integrity and conditional rules: an invoice must have an invoice number, must have an issue date, must identify the seller and buyer. Some fields become mandatory only when others are present, and these conditional relationships are encoded as rules.

A significant group are the calculation rules, often identified with a "CO" marker. These enforce the arithmetic of the invoice: that the sum of line amounts equals the stated total, that the VAT total equals the sum of the VAT breakdown, that the grand total equals the net total plus VAT. These are the rules most frequently violated in practice, because they depend on every amount being computed and rounded consistently.

Another important group govern VAT category logic. Each VAT category, standard-rated, zero-rated, exempt, reverse charge, intra-community supply, export, out of scope, has its own family of rules dictating what must and must not be present for that category. An exempt invoice must state a reason; a reverse-charge invoice must not carry a rate; and so on. These category rules are a common source of subtle errors because they encode real VAT logic, not just structural constraints.

Further rules govern code lists (values such as currencies, country codes, unit measures, and tax categories must come from specified lists) and decimals (amounts must respect defined decimal precision). Together, these rule families are what separate an invoice that is merely well-structured from one that is genuinely valid.

Two syntaxes, one model

EN 16931 defines the semantic model once, and then binds it to two XML syntaxes: UBL 2.1 and UN/CEFACT CII (D16B). Both are covered as formats in their own right elsewhere in this series (UBL and CII). What matters here is the relationship: every business term in the model has a defined location in each of the two syntaxes. BT-1, the invoice number, has a specific home in UBL and a specific home in CII. The semantic content is identical; only the XML path differs.

This is why the same standard can appear in two apparently different formats and why an invoice can be converted from one syntax to the other without losing meaning. Both are faithful transcriptions of the same underlying model. The existence of two bindings was a practical accommodation of two established ecosystems, but at the semantic level there is only one standard, and that is EN 16931. The syntaxes are downstream of it.

Specialising the standard: CIUS and extensions

EN 16931 defines a core. Real-world use often needs something more specific, a national variation, a network's particular requirements, and the standard provides two formal mechanisms for this: the CIUS and the extension.

A CIUS, or Core Invoice Usage Specification, is a specialisation that narrows the core without stepping outside it. A CIUS can make an optional element mandatory, restrict a code list to a subset, or add extra business rules, but it cannot introduce requirements that contradict or exceed the core model. An invoice conforming to a valid CIUS is still conforming to EN 16931. This is the mechanism behind Peppol BIS Billing, the German XRechnung, the Dutch NLCIUS, the Norwegian EHF, and other national and network profiles. Each is a CIUS layered on the same core.

Each CIUS is identified by the specification identifier (BT-24) the invoice declares, and comparing a few makes the shared-core relationship visible. A Peppol BIS Billing 3.0 invoice declares urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, a German XRechnung 3.0 invoice declares urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0, and a plain EN 16931 invoice with no national overlay declares simply urn:cen.eu:en16931:2017. The shared urn:cen.eu:en16931:2017 stem in each is the tell: every one of these is the same core standard, with the text after it naming the particular usage specification layered on top.

An extension goes further, adding information beyond what the core model covers, for cases where a sector or country genuinely needs data the standard does not define. Extensions are used more sparingly, because they reduce interoperability, the whole point of which is the shared core.

Understanding the CIUS concept resolves a lot of apparent complexity. The profusion of national and network specifications is not a collection of separate standards. It is one standard with a family of usage specifications on top, each constraining the same core for a particular context.

What "EN 16931 compliant" actually means

Putting the pieces together, an invoice is EN 16931 compliant when it carries the required business terms, expressed in one of the two permitted syntaxes, and satisfies the business rules, including those of any CIUS it declares. Compliance is therefore a combination of the vocabulary (the right information), the syntax (a valid binding), and the logic (the rules all pass). This definition has run implicitly through every article in this series. The formats differ, the networks differ, the national rules differ, but the compliance question is always the same one, asked against this standard.

The maintenance dimension

EN 16931 is not frozen. The standard has been amended since its original publication, its code lists are updated, and, more actively, the many CIUS built on top of it evolve on their own schedules with their own effective dates. Anyone maintaining e-invoicing against the standard directly has to track not only the core standard's revisions but the specific usage specifications relevant to the markets they serve. The core moves slowly; the specialisations move more often.

Where a service fits in

Implementing EN 16931 directly means building and maintaining the whole stack described here: the semantic model, the two syntax bindings, the full body of business rules, and the CIUS overlays for each market, kept current as all of them change. It is a substantial and continuing commitment for something that is rarely an organisation's core business.

This is why the compliance layer is so often delegated. InvoiceXML implements EN 16931 as a managed capability: generating and validating invoices against the semantic model and its business rules, in both the UBL and CII syntaxes, and across the CIUS profiles for the different European and international markets, with the standard and its specialisations kept current on the service's side. It can be reached through a REST API for direct integration, through no-code automation platforms, or through an MCP interface for AI-driven and agentic workflows, so the same underlying compliance is available however a system is built.

Building it in house remains a legitimate choice for those with the capacity to maintain it. The purpose of this overview, and of the series it concludes, is to make the standard legible: EN 16931 is the semantic model beneath European e-invoicing, a vocabulary of business terms, a body of business rules, bound to two syntaxes and specialised through CIUS profiles. Every format, network, and national variation in the earlier articles is, at bottom, a way of carrying this one standard. See EN 16931 clearly and the entire landscape organises itself around it.

Get started

Create a free InvoiceXML account → and you receive 100 free credits, no credit card required. Generate an EN 16931 invoice in UBL or CII, declare any CIUS profile you need, and run the full business-rule validation in a single call.

If you are weighing implementing EN 16931 in house against delegating the compliance layer, get in touch.

Related resources:

InvoiceXML is a REST API for European and international e-invoice compliance covering EN 16931 in both UBL and CII syntaxes, Peppol BIS Billing, PINT, Factur-X, ZUGFeRD, and XRechnung. Generate and validate invoices against the semantic model, its business rules, and any CIUS overlay with a single API call. Stateless and GDPR compliant by architecture.

EN 16931 Explained: The Standard Underneath Every European E-Invoice