ARLing

What Is EN 16931? The Core Invoice Standard Explained

ARLing s. r. o. · 11 September 2026

EN 16931 is the European standard that defines what a compliant electronic invoice must actually contain: the semantic data model of the core invoice, meaning which data an invoice needs and how the pieces relate to each other. It is not a file format you attach to an e-mail; a document only counts as an electronic invoice when it is issued, sent and received in a structured format that a machine can process automatically, following EN 16931 in the UBL 2.1 or CII syntax. A PDF sent by e-mail or a scanned paper invoice does not meet that definition, no matter how correct the numbers on it look. Country-specific formats sit on top of this same core model instead of replacing it: Peppol BIS Billing 3.0 adds its own rules to EN 16931 rather than starting from scratch. None of this is theoretical for much longer. Slovakia introduces mandatory business-to-business electronic invoicing between domestic VAT payers from 2027, and Germany already requires companies to be able to receive electronic invoices. This note explains what the standard specifies, how national formats build on it, and why its VAT category codes matter in practice.

What EN 16931 actually specifies

EN 16931 works at the level of meaning, not markup. It sets out which data a compliant invoice must carry and how that data must relate to each other, so that a computer on the receiving end can process the invoice without a person retyping it. The schematron behind EN 16931 splits its checks into two kinds: core rules, numbered BR-01 through BR-65, of which 58 actually exist, and calculation and consistency rules, numbered BR-CO-01 through BR-CO-26, of which 24 exist. One of the calculation rules shows how concrete this gets: the schematron requires that the invoice total amount with VAT equal the total amount without VAT plus the total VAT amount, written formally as BT-112 equal to BT-109 plus BT-110.

That semantic model still needs an actual syntax to travel in. EN 16931 allows the data to be carried in either of two syntaxes, UBL 2.1 or CII, and a document following either one can satisfy the same underlying rules.

Why you rarely see "EN 16931" written on an invoice

EN 16931 is usually implemented through a profile built on top of it, because the standard leaves some choices open for individual sectors and countries to close. The common name for such a profile is a CIUS, and Peppol BIS Billing 3.0 is one of them: it keeps the EN 16931 syntax, UBL 2.1, and adds its own rules on top, coded PEPPOL-EN16931-R and PEPPOL-COMMON-R, 41 of them in the November 2025 release, some of which apply only to certain countries.

Slovakia does not have a separate national CIUS of its own; it uses Peppol BIS Billing 3.0 directly, extended only by national requirements that mainly set the mandatory network identifier. Germany went a different way and built its own CIUS, XRechnung, whose current version incorporates the Peppol BIS Billing 3.0 business rules while adding country-specific ones on top.

The VAT category code is part of the standard, not an afterthought

EN 16931 does not leave VAT treatment to guesswork either. A line-level VAT category code from the UNTDID 5305 list drives which values the standard recognises: S for the standard rate, Z for zero rated, E for exempt, AE for reverse charge, K for an intra community supply, G for export outside the European Union, O for not subject to VAT, and L and M for the Canary Islands and for Ceuta and Melilla.

Each of those codes drags its own rule group behind it. Categories S, Z, E, AE and G each carry ten rules of their own, O carries fourteen, and K carries twelve rules under the BR-IC group; picking the wrong category code on a line does not just misdescribe the tax treatment, it switches which set of rules the invoice gets checked against.

Where this already has a deadline attached

Slovakia's mandate is not a vague future plan. From 2027, domestic taxable business-to-business supplies between Slovak VAT payers must be invoiced electronically, under a new delivery service written into the VAT act. Invoices move over the Peppol network through certified delivery service providers, directly from issuer to recipient, with no central government system in between.

Germany moved first on the receiving side: since 2025, a business there must be able to receive an electronic invoice, and an ordinary e-mail inbox is enough to receive one.

Frequently asked questions

Is EN 16931 itself a file format I can export from my accounting software?

No. It is a semantic data model, and it needs a concrete syntax such as UBL 2.1 or CII, usually inside a country profile such as Peppol BIS Billing 3.0, before it becomes a file you actually send.

What should a business currently sending PDF invoices by e-mail do before the deadline?

Nothing has to change today, but the invoicing process itself has to move to the structured UBL 2.1 or CII syntax under EN 16931, sent over Peppol, before domestic taxable business-to-business supplies between Slovak VAT payers become mandatory in 2027. A business already trading with German counterparts should note that side moved first: since 2025 a business there must already be able to receive a structured invoice, even though an ordinary e-mail inbox is enough on the receiving side.

Why would an invoice get rejected specifically because of its VAT category code?

Because EN 16931 ties a different group of validation rules to each VAT category code from the UNTDID 5305 list. Take a reverse-charge line mistakenly marked S instead of AE: it stops being checked against the ten BR-AE rules built for a reverse-charge supply and starts being checked against the ten BR-S rules built for a standard-rated one instead, even though nothing about the actual supply changed.

Conclusion

Understanding EN 16931 matters most on the day the 2027 deadline in Slovakia stops being a compliance article and becomes a field in your own invoicing software that has to be filled in correctly. For a closer look at what a compliant electronic invoice needs to contain before that day arrives, see ARLing's e-invoicing overview.

Sources. The facts in this note are numbered after our internal fact list and were checked on the publication date. ARLing is not a bank; a clean check result is no guarantee that the bank accepts the payment. If a source has changed since, write to andrej@arling.sk and we will correct this page.