# EN 16931 — the semantic core

The one thing every European e-invoice has in common. Everything else — syntax, CIUS, channel — sits on top of this model.

## Authoritative basis

| Artefact | Designation | Status |
|---|---|---|
| Semantic data model | `EN 16931-1:2017, Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic invoice` | Reference published by Commission Implementing Decision (EU) 2017/1870 of 16.10.2017, Art 1 |
| List of syntaxes | `CEN/TS 16931-2:2017, Electronic invoicing — Part 2: List of syntaxes that comply with EN 16931-1` | Same decision, Annex |
| Syntax binding, UBL | CEN/TS 16931-3-2 | UBL invoice and credit note messages as defined in ISO/IEC 19845:2015 (Annex to Impl. Dec. 2017/1870) |
| Syntax binding, CII | CEN/TS 16931-3-3 | UN/CEFACT Cross Industry Invoice XML message as specified in XML Schemas 16B (SCRDM — CII) (same Annex) |
| Validation artefacts | Schematron + XSLT, EUPL 1.2 | `v1.3.16`, published **2026-04-13**, github.com/ConnectingEurope/eInvoicing-EN16931/releases. Release cadence is roughly twice a year (April and October). |

Only two syntaxes are listed in the Implementing Decision. Any other file — EDIFACT INVOIC, X12 810, a JSON API payload, a national XML like FatturaPA — is not a syntax of EN 16931, even where national law accepts it. `[[UNVERIFIED: whether CEN has published an amendment A1/A2 to EN 16931-1 later than the 2017 edition — the Implementing Decision reference is to EN 16931-1:2017 and the validation artefacts repository is the practical source of truth for rule content]]`

## Structure: BT and BG

The model is a flat list of **business terms** (`BT-nn`) grouped into **business groups** (`BG-nn`). A BT is a single value; a BG is a repeatable or non-repeatable container. Both numbers are stable across syntaxes — the same BT-31 is `cac:PartyTaxScheme/cbc:CompanyID` in UBL and `ram:SpecifiedTaxRegistration/ram:ID` in CII.

Groups that matter in almost every invoice:

| Group | Meaning | Cardinality in the core model |
|---|---|---|
| BG-4 | SELLER | 1..1 |
| BG-5 | SELLER POSTAL ADDRESS | 1..1 |
| BG-7 | BUYER | 1..1 |
| BG-8 | BUYER POSTAL ADDRESS | 1..1 |
| BG-13 | DELIVERY INFORMATION | 0..1 |
| BG-14 | INVOICING PERIOD | 0..1 |
| BG-16 | PAYMENT INSTRUCTIONS | 0..1 |
| BG-20 | DOCUMENT LEVEL ALLOWANCES | 0..n |
| BG-21 | DOCUMENT LEVEL CHARGES | 0..n |
| BG-22 | DOCUMENT TOTALS | 1..1 |
| BG-23 | VAT BREAKDOWN | 1..n |
| BG-25 | INVOICE LINE | 1..n |
| BG-29 | PRICE DETAILS | 1..1 per line |
| BG-30 | LINE VAT INFORMATION | 1..1 per line |
| BG-31 | ITEM INFORMATION | 1..1 per line |

## The unconditionally mandatory terms

These are enforced by rules BR-01 to BR-16, whose exact messages are reproduced in `validation-errors.md`. Reproduced here as a build target — an invoice missing any of these will never validate anywhere.

| BT | Name | UBL path | CII path |
|---|---|---|---|
| BT-24 | Specification identifier | `cbc:CustomizationID` | `ram:GuidelineSpecifiedDocumentContextParameter/ram:ID` |
| BT-1 | Invoice number | `cbc:ID` | `rsm:ExchangedDocument/ram:ID` |
| BT-2 | Invoice issue date | `cbc:IssueDate` | `ram:IssueDateTime/udt:DateTimeString` (`format="102"`) |
| BT-3 | Invoice type code | `cbc:InvoiceTypeCode` | `rsm:ExchangedDocument/ram:TypeCode` |
| BT-5 | Invoice currency code | `cbc:DocumentCurrencyCode` | `ram:InvoiceCurrencyCode` |
| BT-27 | Seller name | `cac:AccountingSupplierParty/…/cac:PartyLegalEntity/cbc:RegistrationName` | `ram:SellerTradeParty/ram:Name` |
| BT-40 | Seller country code | `…/cac:PostalAddress/cac:Country/cbc:IdentificationCode` | `ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID` |
| BT-44 | Buyer name | `cac:AccountingCustomerParty/…/cbc:RegistrationName` | `ram:BuyerTradeParty/ram:Name` |
| BT-55 | Buyer country code | `…/cac:PostalAddress/cac:Country/cbc:IdentificationCode` | `ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID` |
| BT-106 | Sum of Invoice line net amount | `cac:LegalMonetaryTotal/cbc:LineExtensionAmount` | `ram:LineTotalAmount` |
| BT-109 | Invoice total amount without VAT | `cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` | `ram:TaxBasisTotalAmount` |
| BT-112 | Invoice total amount with VAT | `cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount` | `ram:GrandTotalAmount` |
| BT-115 | Amount due for payment | `cac:LegalMonetaryTotal/cbc:PayableAmount` | `ram:DuePayableAmount` |
| BG-25 | At least one invoice line | `cac:InvoiceLine` (1..n) | `ram:IncludedSupplyChainTradeLineItem` (1..n) |
| BG-23 | At least one VAT breakdown | `cac:TaxTotal/cac:TaxSubtotal` | `ram:ApplicableTradeTax` |
| BT-151 | Invoiced item VAT category code per line | `cac:Item/cac:ClassifiedTaxCategory/cbc:ID` | `ram:ApplicableTradeTax/ram:CategoryCode` |

Source for UBL paths and cardinalities: docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/tree/. Source for CII paths: the CEN reference example `cii/examples/CII_business_example_01.xml` in the validation-artefacts repository.

## Conditional terms that behave as mandatory in practice

| BT | Condition | Rule |
|---|---|---|
| BT-9 Payment due date **or** BT-20 Payment terms | Amount due for payment (BT-115) is positive | BR-CO-25 |
| BT-29 Seller identifier **or** BT-30 Seller legal registration identifier **or** BT-31 Seller VAT identifier | Always — at least one of the three | BR-CO-26 |
| BT-110 Invoice total VAT amount | Any VAT is charged; must equal the sum of BT-117 | BR-CO-14 |
| BT-116 / BT-117 / BT-119 per BG-23 | Each VAT category present on lines, allowances or charges needs its own breakdown | BR-S-01 … BR-O-01 |
| Exemption reason code (BT-121) or text (BT-120) | VAT category is E, AE, G, K or O | BR-E-10, BR-AE-10, BR-G-10, BR-IC-10, BR-O-10 |
| BT-48 Buyer VAT identifier | Reverse charge (AE) or intra-Community supply (K) | BR-AE-02, BR-IC-02 |
| BT-70/BT-80 delivery country, BT-72 actual delivery date or BG-14 period | Intra-Community supply (K) | BR-IC-11, BR-IC-12 |
| BT-10 Buyer reference **or** BT-13 Purchase order reference | Peppol BIS Billing 3.0 (not the core standard) | Peppol rule; German public sector uses BT-10 for the Leitweg-ID |

## What EN 16931 deliberately does not do

- It does not define transport. Nothing in the standard says how the file reaches the buyer.
- It does not define a document envelope, signature or receipt.
- It does not cover order, despatch advice or payment — those are separate Peppol/UBL documents.
- It does not decide VAT liability. The category codes describe a treatment; the treatment comes from Directive 2006/112/EC and national law (`vat-content.md`).

## CIUS versus extension

- A **CIUS** (Core Invoice Usage Specification) only *restricts*: it may make optional terms mandatory, narrow code lists, or forbid terms. A document valid against a CIUS is always valid against EN 16931. Examples: Peppol BIS Billing 3.0, XRechnung, RO_CIUS.
- An **extension** *adds* information beyond the core model. A document using an extension is conformant but not compliant, and its CustomizationID uses `#conformant#` rather than `#compliant#` — compare `urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic` with `urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended` (profile identifiers as implemented in the ZUGFeRD reference library mustangproject, `Profiles.java`).
- A receiver that only supports EN 16931 core may reject an extension. Never send an extension profile unless the target specification names it.

## Checkpoints

- [ ] `cbc:CustomizationID` / `ram:GuidelineSpecifiedDocumentContextParameter/ram:ID` copied verbatim from the target specification, not composed
- [ ] All 16 unconditionally mandatory terms populated
- [ ] BR-CO-26: at least one of BT-29 / BT-30 / BT-31 present
- [ ] BR-CO-25: BT-9 or BT-20 present whenever BT-115 > 0
- [ ] One BG-23 per distinct VAT category + rate combination
- [ ] Exemption reason present for every non-standard-rate category
- [ ] Validated against EN 16931 validation artefacts v1.3.16, not only against the XSD
- [ ] Validated a second time against the target CIUS Schematron
- [ ] Extension profiles used only where the receiving specification names them