What Is EN 16931?
EN 16931 is a European standard published in 2017 by CEN Technical Committee 434 (CEN/TC 434). Its official title is "Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic invoice". It was created to implement EU Directive 2014/55/EU, which mandated that all EU public sector entities accept e-invoices in a standard format.
The standard defines a semantic data model — not a file format. It specifies 176 business terms that describe the information an e-invoice can contain: seller data, buyer data, line items, tax breakdowns, payment instructions, allowances, charges, and delivery information.
The standard is syntax-agnostic. It can be serialised in two official syntaxes: UBL 2.1 (used by Peppol, Italy, Belgium, Spain) and UN/CEFACT Cross-Industry Invoice (CII) (used by France, Germany). Both are equally valid under the standard.
The Semantic Model
The EN 16931 semantic model organises its 176 business terms into logical business groups. Each term has a unique identifier (e.g., BT-1 for Invoice Number, BT-2 for Issue Date) and a cardinality (mandatory, conditional, or optional).
BG-2 Process Control
BT-23 Business process type, BT-24 Specification identifier
Mandatory: Yes
BG-4 Seller
BT-27 Seller name, BT-30 Legal registration, BT-31 VAT identifier
Mandatory: Yes
BG-7 Buyer
BT-44 Buyer name, BT-48 VAT identifier
Mandatory: Yes
BG-22 Document Totals
BT-106 Sum of line net amounts, BT-112 Total with VAT, BT-115 Amount due
Mandatory: Yes
BG-25 Invoice Line
BT-126 Line identifier, BT-129 Invoiced quantity, BT-131 Net amount
Mandatory: Yes (repeatable)
BG-23 VAT Breakdown
BT-116 VAT category base, BT-117 VAT amount, BT-118 Category code
Mandatory: Yes (repeatable)
BG-16 Payment Instructions
BT-81 Payment means type, BT-82 Payment means text
Mandatory: Yes
BG-13 Delivery Information
BT-70 Deliver to party name, BT-72 Actual delivery date
Mandatory: No
Understanding these groups is essential because validation rules differ by country. A field that is optional in the core model may become mandatory when a specific CIUS (Core Invoice Usage Specification) is applied.
Syntax Bindings
EN 16931 supports two official XML syntaxes. Each one maps the 176 semantic business terms to specific XML elements:
UBL 2.1 (OASIS)
The most widely used syntax globally. Peppol BIS Billing 3.0 is built on UBL 2.1. Also used by Italy (FatturaPA maps to it), Belgium, Ireland, and the Nordic countries. UBL's namespace is urn:oasis:names:specification:ubl:schema:xsd:Invoice-2.
UN/CEFACT CII D16B
Used primarily in the DACH region and France. XRechnung (Germany) supports both UBL and CII, but many German entities prefer CII. Factur-X (France) embeds CII XML inside a PDF/A-3 document, creating a hybrid human-and-machine-readable invoice.
Both syntaxes are semantically equivalent — the same 176 business terms, the same validation rules, the same business meaning. The difference is purely in XML structure. InvoStaq's engine converts between them automatically, so your ERP only needs to generate one format.
Country Extensions (CIUSs)
EN 16931 allows countries and communities to create Core Invoice Usage Specifications (CIUSs) — extensions that tighten or constrain the base standard without breaking compatibility. A CIUS can:
- Make optional fields mandatory (e.g., requiring a buyer VAT ID)
- Restrict code list values (e.g., limiting to specific VAT category codes)
- Add business rules (e.g., "Line net amount = quantity × price")
- NOT make mandatory fields optional
- NOT change semantics of existing fields
🇩🇪 XRechnung 3.0
Syntax: UBL 2.1 + CII
Mandatory buyer reference (BT-10). Leitweg-ID required for B2G.
🇫🇷 Factur-X 1.07
Syntax: CII in PDF/A-3
5 profiles: Minimum → Extended. Hybrid approach (human + machine-readable).
🇮🇹 CIUS-IT / FatturaPA
Syntax: UBL 2.1 (via SDI)
CodiceDestinatario mandatory. Bollo virtuale stamp duty field.
🇧🇪 Peppol BIS BE
Syntax: UBL 2.1
Follows Peppol BIS 3.0 with Belgian-specific routing via Hermes.
🇪🇸 CIUS-ES / Facturae
Syntax: UBL 2.1
Double-reporting: Verifactu (tax) + e-invoice (commercial). NIF/CIF required.
🇵🇱 CIUS-PL / KSeF
Syntax: National XML (FA-2)
Poland's KSeF uses its own FA(2) schema — not standard UBL or CII. Unique in the EU.
Practical Compliance
EN 16931 compliance requires meeting three layers of validation simultaneously:
Schema Validation
The XML document must conform to the UBL 2.1 or CII D16B XML Schema. This catches structural errors: missing elements, wrong namespaces, invalid data types.
Semantic Business Rules
EN 16931 defines ~90 business rules (e.g., BR-01: 'An Invoice shall have a Specification identifier', BR-CO-15: 'Invoice total amount with VAT = Invoice total without VAT + Invoice total VAT amount'). Each rule has a severity level.
CIUS-Specific Rules
Country extensions add their own rules on top. XRechnung adds ~30 German-specific rules. Factur-X adds French-specific rules. KSeF has its own validation logic. Your invoice must pass ALL three layers.
InvoStaq's validation engine performs all three layers in under 200ms, before your invoice reaches any government system. We maintain up-to-date rule sets for 14+ CIUS variants across Europe, so you never submit an invoice that will be rejected.
One Standard. Many Formats. One API.
InvoStaq validates, transforms, and routes EN 16931 invoices across UBL, CII, XRechnung, Factur-X, FatturaPA, and Peppol BIS — all from a single integration.