EN 16931: The European E-Invoicing Standard Explained
Short answer: EN 16931 is the European standard for e-invoices. It isn’t a file format. It’s a data model: a numbered list of business terms (invoice number BT-1, issue date BT-2, seller VAT number BT-31 and so on) plus rules on how they fit together, which can be written in two XML syntaxes, UBL and CII. National formats such as XRechnung, ZUGFeRD, Factur-X and Peppol BIS Billing 3.0 are versions of it with extra national rules. It started as the standard for invoicing EU public bodies, and under ViDA it becomes the reference for all EU e-invoices from 1 July 2030.
This guide is for anyone who keeps seeing “EN 16931-compliant” in software specs and tenders, and for developers who need to know what’s inside an e-invoice. For which countries require e-invoicing and when, see the EU e-invoicing overview.
EN 16931 at a glance
Section titled “EN 16931 at a glance”| What it is | The European standard on electronic invoicing: a semantic data model plus a list of approved syntaxes |
| Written by | CEN (European Committee for Standardization), technical committee CEN/TC 434 |
| Legal basis | Directive 2014/55/EU on e-invoicing in public procurement |
| Editions | EN 16931-1:2017 (amended 2019). EN 16931-1:2026 approved in March 2026. The 2017 edition stays compliant during a migration period |
| Syntaxes | UBL 2.1 (ISO/IEC 19845) and UN/CEFACT CII (D16B), listed in Implementing Decision (EU) 2017/1870 |
| Size | Around 160 business terms in the 2017 model, grouped into business groups (BG) |
| Built on it | XRechnung, ZUGFeRD and Factur-X, Peppol BIS Billing 3.0, the French reform’s formats, Italy’s CIUS-IT |
| Under ViDA | The reference format for EU e-invoices from 1 July 2030 |
| Free copy? | Parts 1 and 2 are free through your national standards body, under a licence paid for by the Commission |
Do you need to care about EN 16931?
Section titled “Do you need to care about EN 16931?”| Your situation | What EN 16931 means for you |
|---|---|
| A customer or tender asks for an “EN 16931-compliant e-invoice” | Send a structured e-invoice in a format built on it, for example XRechnung or ZUGFeRD in Germany, or Peppol BIS in Belgium. A PDF is not enough |
| You invoice EU public bodies | They must accept EN 16931 invoices. Many countries also require suppliers to send them, usually in a national CIUS |
| You invoice German or French businesses | Their mandates are built on EN 16931. See Germany and France |
| You sell B2B across EU borders | From 1 July 2030 under ViDA, cross-border B2B invoices must be EN 16931 e-invoices with digital reporting |
| You’re a developer building invoicing | Model your invoice data on the business terms below. Every European format maps back to them |
| You sell only to consumers | Mostly not relevant. B2C invoices are outside nearly every e-invoicing mandate |
The semantic model: business terms and groups
Section titled “The semantic model: business terms and groups”The heart of EN 16931 is Part 1, the semantic data model. “Semantic” means it defines meaning, not file layout. Each piece of information has:
- An ID: BT- for a business term (one value, like the invoice number) or BG- for a business group (a block of related terms, like the seller’s address).
- A name and definition, for example BT-1 “Invoice number: a unique identification of the invoice”.
- A cardinality:
1..1means exactly one, mandatory.0..1means optional.1..nmeans at least one, repeatable. - Business rules that link terms together, coded BR- (general), BR-CO- (calculations and conditions) and BR-S-, BR-AE- and so on for each VAT category.
So “BT-31” means the same thing in a German XRechnung, a French Factur-X and a Belgian Peppol invoice: the seller’s VAT number. That shared vocabulary is what lets software read invoices from anywhere.
Core business terms
Section titled “Core business terms”These are the terms almost every invoice carries. Numbering and rules are from the 2017 model, which is what nearly all invoices in circulation use today. Rule IDs are from the official EN 16931 validation artefacts.
| ID | Business term | Required? | Rule |
|---|---|---|---|
| BT-1 | Invoice number | Always | BR-02 |
| BT-2 | Invoice issue date | Always | BR-03 |
| BT-3 | Invoice type code (380 invoice, 381 credit note) | Always | BR-04 |
| BT-5 | Invoice currency code | Always | BR-05 |
| BT-9 | Payment due date | Optional in the core rules. Peppol BIS requires it or payment terms (BT-20) when an amount is due | |
| BT-10 | Buyer reference | Optional in the standard. Mandatory in XRechnung (Leitweg-ID) | BR-DE-15 |
| BT-24 | Specification identifier (which standard or CIUS the invoice follows) | Always | BR-01 |
| BT-27 | Seller name | Always | BR-06 |
| BG-5 / BT-40 | Seller postal address / seller country code | Always | BR-08, BR-09 |
| BT-31 | Seller VAT identifier | When charging VAT (or BT-32 or BT-63 instead) | BR-S-02 |
| BT-44 | Buyer name | Always | BR-07 |
| BG-8 / BT-55 | Buyer postal address / buyer country code | Always | BR-10, BR-11 |
| BT-48 | Buyer VAT identifier | For reverse charge and intra-EU supplies of goods | BR-AE-02, BR-IC-02 |
| BT-106 | Sum of invoice line net amounts | Always | BR-12 |
| BT-109 | Invoice total without VAT | Always | BR-13 |
| BT-110 | Invoice total VAT amount | When VAT is charged | BR-CO-15 |
| BT-112 | Invoice total with VAT | Always | BR-14 |
| BT-115 | Amount due for payment | Always | BR-15 |
| BG-23 | VAT breakdown: taxable amount (BT-116), VAT amount (BT-117), category code (BT-118), rate (BT-119) | At least one | BR-CO-18, BR-45 to BR-48 |
| BG-25 | Invoice line | At least one | BR-16 |
| BT-126 | Invoice line identifier | Every line | BR-21 |
| BT-129 / BT-130 | Invoiced quantity / unit of measure | Every line | BR-22, BR-23 |
| BT-131 | Invoice line net amount | Every line | BR-24 |
| BT-146 | Item net price | Every line | BR-26 |
| BT-151 | Item VAT category code | Every line | BR-CO-04 |
| BT-153 | Item name | Every line | BR-25 |
Validators also check the arithmetic. For example, BR-CO-10 says BT-106 must equal the sum of all line amounts (BT-131), and BR-CO-15 says BT-112 must equal BT-109 plus BT-110.
VAT category codes
Section titled “VAT category codes”Every line and every VAT breakdown has a VAT category code (BT-151 and BT-118). The choice triggers its own rules:
| Code | Meaning | Typical use |
|---|---|---|
| S | Standard rated | Most domestic sales, at any non-zero rate (standard or reduced) |
| Z | Zero rated | Goods taxed at 0% where the country has a zero rate |
| E | Exempt from VAT | Exempt services such as most financial and medical services. Needs an exemption reason |
| AE | Reverse charge | B2B services to another EU country. Needs the buyer’s VAT number and a “Reverse charge” reason |
| K | Intra-community supply | B2B goods shipped to another EU country. Needs both VAT numbers |
| G | Export outside the EU | Goods exported to non-EU customers |
| O | Outside the scope of VAT | Transactions not subject to VAT at all |
| L, M | Canary Islands (IGIC), Ceuta and Melilla (IPSI) | Spain’s special territories |
The two syntaxes: UBL and CII
Section titled “The two syntaxes: UBL and CII”A data model has to be written in some file format. EN 16931 allows two XML syntaxes, named in the Commission’s Implementing Decision (EU) 2017/1870:
| UBL 2.1 | UN/CEFACT CII | |
|---|---|---|
| Full name | Universal Business Language, ISO/IEC 19845:2015 | Cross Industry Invoice, schema version 16B |
| From | OASIS | UN/CEFACT, the UN trade facilitation body |
| Used by | Peppol BIS Billing 3.0, XRechnung (UBL), the French reform (UBL) | ZUGFeRD and Factur-X, XRechnung (CII), the French reform (CII) |
The same business term sits in a different place in each:
| Business term | UBL | CII |
|---|---|---|
| BT-1 Invoice number | cbc:ID | rsm:ExchangedDocument/ram:ID |
| BT-2 Issue date | cbc:IssueDate as 2026-11-02 | ram:IssueDateTime/udt:DateTimeString as 20261102 |
| BT-24 Specification identifier | cbc:CustomizationID | ram:GuidelineSpecifiedDocumentContextParameter/ram:ID |
| BT-31 Seller VAT identifier | cac:PartyTaxScheme/cbc:CompanyID | ram:SpecifiedTaxRegistration/ram:ID with schemeID="VA" |
| BT-112 Total with VAT | cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount | ram:GrandTotalAmount |
CEN also published a binding to the older EDIFACT INVOIC message (CEN/TS 16931-3-4), but it isn’t on the Commission’s list, so public bodies don’t have to accept it.
The parts of the standard
Section titled “The parts of the standard”| Part | What it covers | Free? |
|---|---|---|
| EN 16931-1 | The semantic data model (the business terms and rules) | Yes |
| CEN/TS 16931-2 | The list of compliant syntaxes | Yes |
| CEN/TS 16931-3-1 to 3-4 | Syntax bindings: how each term maps to UBL, CII and EDIFACT | Sold by national standards bodies |
| CEN/TR 16931-4 | Interoperability at transmission level | Sold |
| CEN/TR 16931-5 | How to build CIUS and extensions | Sold |
| CEN/TR 16931-6 | Test results of the standard in practice | Sold |
Source: the European Commission’s page on obtaining a copy of the standard. For developers, the official business rules are also published free as schematron and XSLT files in the eInvoicing-EN16931 repository, currently version 1.3.17 (October 2026).
CIUS and extensions: how national formats are built
Section titled “CIUS and extensions: how national formats are built”EN 16931 is deliberately general. Countries and sectors adapt it in two ways:
- A CIUS (Core Invoice Usage Specification) restricts the standard: it makes optional fields mandatory, limits code lists or adds checks. Every CIUS invoice is still a valid EN 16931 invoice. Its BT-24 contains
#compliant#. - An extension adds data the standard doesn’t have, such as extra parties or sub-lines. An extension invoice is conformant but not strictly compliant, so a receiver that only knows the core standard may ignore the extra data. Its BT-24 contains
#conformant#.
| Specification | Type | Who uses it | BT-24 identifier |
|---|---|---|---|
| XRechnung | CIUS | German public sector and B2B | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 |
| Peppol BIS Billing 3.0 | CIUS | The Peppol network: Belgium, the Netherlands, the Nordics and many public bodies | urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 |
| ZUGFeRD / Factur-X EN 16931 profile | The plain standard, in CII inside a PDF | German and French B2B | urn:cen.eu:en16931:2017 |
| ZUGFeRD / Factur-X EXTENDED | Extension | Complex B2B billing | urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended |
| French reform: EN 16931 profile | CIUS (French BR-FR rules) | French B2B e-invoicing | urn:cen.eu:en16931:2017, with French rules applied by the platforms |
| French reform: EXTENDED-CTC-FR | Extension | French B2B cases the core can’t handle | urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-fr |
| CIUS-IT | CIUS | EN 16931 invoices to Italian public bodies through SdI | urn:cen.eu:en16931:2017#compliant#urn:fatturapa.gov.it:CIUS-IT:2.0.0 |
Where FatturaPA fits
Section titled “Where FatturaPA fits”Italy’s FatturaPA is not built on EN 16931. It’s a national XML format that predates the standard and has its own structure. Italy meets the public procurement directive differently: its exchange system SdI accepts EN 16931 invoices in UBL or CII for public sector customers, following the Italian CIUS-IT rules in the Agenzia delle Entrate’s technical specifications, and converts them to FatturaPA internally. Domestic Italian B2B and B2C invoices still use FatturaPA. See E-invoicing in Italy.
Directive 2014/55/EU: where EN 16931 came from
Section titled “Directive 2014/55/EU: where EN 16931 came from”The Directive 2014/55/EU of 16 April 2014 on electronic invoicing in public procurement asked CEN to write a European standard, so that a supplier in one country could invoice a public body in another without a different format for each.
| Date | Milestone |
|---|---|
| 16 April 2014 | Directive 2014/55/EU adopted |
| 28 June 2017 | CEN publishes EN 16931-1:2017 and CEN/TS 16931-2:2017 |
| 17 October 2017 | The Commission publishes the reference to the standard and its syntaxes in the Official Journal (Implementing Decision 2017/1870) |
| 18 April 2019 | Central government bodies in every EU country must receive and process EN 16931 e-invoices |
| 18 April 2020 | Deadline for sub-central bodies (regions, municipalities) in countries that used the extra year |
The directive obliges public bodies to receive EN 16931 invoices. It doesn’t oblige suppliers to send them. Several countries added that themselves, for example Germany for federal suppliers from November 2020 and Italy through SdI. The Commission ran a public consultation on revising the directive from March to June 2026.
EN 16931-1:2026: the revised standard
Section titled “EN 16931-1:2026: the revised standard”The 2017 model was designed for invoices to public bodies. With B2B mandates spreading and ViDA on the way, CEN revised it.
- Approved in March 2026. CEN’s national members approved EN 16931-1:2026 unanimously (17 countries voted in favour, the rest abstained), and the definitive text went to national standards bodies on 18 March 2026, according to the European Commission’s announcement.
- The 2017 edition is withdrawn but still compliant. The Commission’s eInvoicing pages say invoices following the 2017 edition remain compliant during a migration period. No end date has been set yet, and we couldn’t find the Official Journal reference to the 2026 edition published as of 26 October 2026.
- What’s new. Reported changes include several orders and deliveries on one invoice, VAT exemption reasons for allowances and charges, VAT breakdowns split by exemption reason, a goods-or-services indicator, early-payment discounts and late-payment charges, and better support for special VAT schemes. KoSIT’s XRechnung 4.0 pre-release, built on the new model, adds more than 50 business terms.
- Formats follow later. The syntax bindings and validation artefacts need updating first, then each national format. ZUGFeRD 2.5 and Factur-X 1.09 already added some 2026 features to their EXTENDED profile. XRechnung 4.0 is expected in spring 2027.
What to do now: nothing urgent. Keep issuing invoices in your current format and version. Ask your software provider when they plan to support the 2026-based versions, such as XRechnung 4.0.
ViDA: EN 16931 becomes the EU default in 2030
Section titled “ViDA: EN 16931 becomes the EU default in 2030”The EU’s VAT in the Digital Age package, Directive (EU) 2025/516, gives EN 16931 a much bigger role. From 1 July 2030:
- E-invoices must follow the European standard. The VAT Directive will refer to EN 16931 and its syntax list as the default for electronic invoices. Countries may still allow other formats for domestic sales.
- Cross-border B2B invoices become EN 16931 e-invoices with digital reporting to the tax authorities, replacing EC Sales Lists.
- No buyer consent is needed to send an EN 16931 e-invoice to a business.
The ViDA section of the EU overview has the full timeline. The practical message: if you invoice EU businesses, building your invoicing on EN 16931 data now saves a rebuild later.
EN 16931 vs XRechnung vs ZUGFeRD vs Factur-X
Section titled “EN 16931 vs XRechnung vs ZUGFeRD vs Factur-X”| EN 16931 | XRechnung | ZUGFeRD | Factur-X | Peppol BIS Billing 3.0 | |
|---|---|---|---|---|---|
| What it is | The standard (data model + syntaxes) | German CIUS | Hybrid PDF + CII, German name | Hybrid PDF + CII, French name | Peppol’s CIUS |
| File | None on its own | XML (UBL or CII) | PDF/A-3 with XML | PDF/A-3 with XML | XML (UBL) |
| Maintained by | CEN/TC 434 | KoSIT | FeRD with FNFE-MPE | FNFE-MPE with FeRD | OpenPeppol |
| Current version | 2026 (2017 still accepted) | 3.0.2 | 2.5.2 | 1.09.2 | 3.0 |
| Main use | Reference for all of them | German public sector and B2B | German B2B | French and German B2B | Belgium, the Netherlands, Nordics, cross-border |
Worked example: one reverse-charge invoice in EN 16931 terms
Section titled “Worked example: one reverse-charge invoice in EN 16931 terms”A freelance developer in Hamburg, registered for German VAT, builds an app for a business in Lyon. Services to an EU business are taxed where the customer is, under the reverse charge, so the developer charges no VAT.
| Business term | Value |
|---|---|
| BT-1 Invoice number | 2026-041 |
| BT-2 Issue date | 2 November 2026 |
| BT-3 Type | 380 (commercial invoice) |
| BT-5 Currency | EUR |
| BT-31 Seller VAT ID | The developer’s DE number |
| BT-48 Buyer VAT ID | The client’s FR number. Required by BR-AE-02 because this is reverse charge |
| BG-25 Line | 1 × “App development, October 2026” at €3,000.00, VAT category AE |
| BG-23 VAT breakdown | Taxable amount (BT-116) €3,000.00, VAT amount (BT-117) €0.00, category (BT-118) AE, rate (BT-119) 0 |
| BT-120 Exemption reason | ”Reverse charge” (required by BR-AE-10) |
| BT-109 / BT-110 / BT-112 | €3,000.00 / €0.00 / €3,000.00 |
| BT-115 Amount due | €3,000.00 |
Written as XRechnung, ZUGFeRD or Peppol BIS, the file looks different, but every one of these values sits in the same business term. Today, this cross-border invoice can still be a PDF if the client agrees, because neither the German nor the French e-invoicing mandate covers it (the French client may have to e-report the purchase through its own platform). From 1 July 2030, under ViDA, it will have to be an EN 16931 e-invoice reported to the tax authority.
How to produce and validate an EN 16931 invoice
Section titled “How to produce and validate an EN 16931 invoice”You never send “plain EN 16931”. You send a format built on it, chosen by country and customer:
| Customer | Usual format |
|---|---|
| German public body | XRechnung |
| German business | ZUGFeRD or XRechnung |
| French business | Factur-X, UBL or CII, through a Plateforme Agréée |
| Belgian business, or anyone on Peppol | Peppol BIS Billing 3.0 |
| Italian business | FatturaPA through SdI (not EN 16931) |
To create one, use your invoicing software’s e-invoice export, an e-invoicing API, or an open-source library such as Mustang (Java) or factur-x (Python, which can build CII or UBL from a dictionary keyed by BT numbers).
To validate one:
| Tool | What it checks |
|---|---|
| European Commission invoice validator | Free online check of UBL and CII files against the official EN 16931 rules (release 1.3.17) |
| eInvoicing-EN16931 artefacts | The same official rules, as schematron for your own pipeline |
| KoSIT validator | XRechnung, which includes the EN 16931 rules |
| FNFE-MPE validator | French reform files (Factur-X, UBL, CII) |
| Mustang | ZUGFeRD and Factur-X, including the PDF/A-3 part |
Passing the EN 16931 rules is necessary but not always enough. A national CIUS adds its own rules, so also run the national validator.
How GoodVat helps
Section titled “How GoodVat helps”An EN 16931 invoice is only as good as the VAT data in it. Picking the wrong VAT category code (S instead of AE, for example) or leaving out the buyer’s VAT number is a VAT error first and a validation error second. GoodVat Global Tax Compliance handles the VAT side:
- Maps your obligations: which e-invoicing mandates, formats and VAT rules apply in each country you invoice into, now and under ViDA
- Registers you for VAT, OSS or IOSS where you need it
- Calculates the right VAT and category for every sale, including the reverse charge, and sends compliant invoices
- Files your VAT returns in the EU, the UK and US states
GoodVat is not an e-invoicing platform, a Peppol access point or a format validator.
What is EN 16931?
Section titled “What is EN 16931?”EN 16931 is the European standard for electronic invoices, written by the European standards body CEN at the request of the European Commission. It defines which pieces of information an e-invoice contains and what each one means, and which XML syntaxes can carry them. National formats such as XRechnung, Factur-X and Peppol BIS Billing 3.0 are all built on it.
Is EN 16931 a file format?
Section titled “Is EN 16931 a file format?”Not on its own. EN 16931 is a data model: a list of business terms, such as the invoice number (BT-1) and the seller’s VAT number (BT-31), with rules about how they fit together. To make an actual file you express that model in one of the approved XML syntaxes, UBL 2.1 or UN/CEFACT CII, usually following a national rulebook such as XRechnung.
What is a CIUS?
Section titled “What is a CIUS?”A CIUS (Core Invoice Usage Specification) is a set of extra rules on top of EN 16931 for a country or sector. It can make optional fields mandatory or restrict their values, but every invoice that follows a CIUS still complies with the standard. XRechnung, Peppol BIS Billing 3.0 and the French reform’s EN 16931 profile are examples.
What is the difference between UBL and CII?
Section titled “What is the difference between UBL and CII?”They are two XML languages that can both carry an EN 16931 invoice. UBL 2.1 comes from OASIS and is used by Peppol. UN/CEFACT CII comes from the United Nations trade body and is used inside ZUGFeRD and Factur-X. The business data is the same, only the element names and structure differ.
Is EN 16931 mandatory?
Section titled “Is EN 16931 mandatory?”EU public bodies have had to accept EN 16931 e-invoices since 2019 or 2020 under Directive 2014/55/EU. For business-to-business invoices it depends on the country: Germany and France build their mandates on it. Under ViDA, from 1 July 2030, EU e-invoices must follow EN 16931, although countries may still allow other formats for domestic sales.
What changed in EN 16931-1:2026?
Section titled “What changed in EN 16931-1:2026?”CEN approved a revised edition of the core data model in March 2026 to support B2B invoicing and the ViDA reporting rules. It adds business terms for cases such as several orders on one invoice, VAT exemption reasons and payment discounts. The 2017 edition was withdrawn but invoices following it remain compliant during a migration period whose end date has not yet been set.
Is FatturaPA compliant with EN 16931?
Section titled “Is FatturaPA compliant with EN 16931?”No. FatturaPA is Italy’s own national XML format and predates the European standard. Italy’s exchange system, SdI, does accept EN 16931 invoices in UBL or CII for public sector customers, under an Italian CIUS, and converts them to FatturaPA internally.
How can I check if an invoice complies with EN 16931?
Section titled “How can I check if an invoice complies with EN 16931?”Use a validator that runs the official EN 16931 rules. The European Commission hosts a free online invoice validator for UBL and CII files, and the same rules are published as open validation artefacts on GitHub. For a national format, also run its own validator, such as the KoSIT validator for XRechnung.
Related guides
Section titled “Related guides”- E-invoicing in Europe: every EU mandate, formats and the full ViDA timeline
- XRechnung explained: Germany’s CIUS, the Leitweg-ID and the KoSIT validator
- ZUGFeRD explained: the hybrid PDF format, its versions and profiles
- Factur-X explained: the French hybrid format and the EXTENDED-CTC-FR profile
- E-invoicing in Germany: the German mandate built on EN 16931
- E-invoicing in France: the French reform and its three formats
- E-invoicing in Belgium: the Peppol BIS Billing 3.0 mandate
- E-invoicing in Italy: FatturaPA and SdI
- Selling to EU businesses: how the reverse charge works