EN 16931 — the European semantic invoice model

A model, not a format

EN 16931-1 defines the semantic data model of an electronic invoice: the list of business terms an invoice may or must contain, what each one means, how many times it may appear, and the rules that relate them. It does not define an XML format.

The format comes from a syntax binding. EN 16931-3 binds the model to two syntaxes: OASIS UBL 2.1 and UN/CEFACT CII. The binding says which element in each syntax carries which business term. That is why an invoice can be moved between the two syntaxes without loss within the core model — the model is the same, only the serialisation differs.

Business terms

Every field in the model has an identifier. BT- prefixes a business term — a leaf value — and BG- prefixes a business group, a structure containing others.

• BT-1 — invoice number.
• BT-2 — invoice issue date.
• BT-3 — invoice type code.
• BT-5 — invoice currency code.
• BT-9 — payment due date.
• BT-24 — specification identifier, the CIUS or profile being claimed.
• BG-4 / BG-7 — the seller and the buyer.
• BG-25 — an invoice line.
• BG-23 — a VAT breakdown entry.
• BT-112 / BT-115 — total with VAT, and amount due for payment.

These identifiers are what validation findings refer to, which is why a report that only says "invalid" is unhelpful: the useful information is which business term and which rule.

The same invoice in two syntaxes

A few business terms, and where each syntax puts them:

• BT-1 invoice number — UBL cbc:ID; CII rsm:ExchangedDocument/ram:ID.
• BT-2 issue date — UBL cbc:IssueDate as an ISO date; CII ram:IssueDateTime/udt:DateTimeString with a format qualifier.
• BT-9 due date — UBL cbc:DueDate on the document; CII ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime, on the payment terms.
• BT-31 seller VAT identifier — UBL cac:PartyTaxScheme/cbc:CompanyID with a nested VAT tax scheme; CII ram:SpecifiedTaxRegistration/ram:ID with schemeID="VA".
• BT-115 amount due — UBL cac:LegalMonetaryTotal/cbc:PayableAmount; CII ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:DuePayableAmount.

Same meaning, materially different structure. This is why the viewers on this site map both syntaxes to a common model for genuinely shared fields while keeping the syntax-specific arrangement visible in the parsed data.

How the rules are organised

The business rules are published as Schematron and grouped by what they check. The prefix tells you what kind of failure you are looking at:

• BR-* — presence and cardinality. "An invoice shall have an invoice number." A failure means something is missing or repeated when it should not be.
• BR-CO-* — conditions and calculations. "The sum of line net amounts shall equal the total of line net amounts." These are the arithmetic rules, and they are where real invoices most often fail.
• BR-CL-* — code lists. "The VAT category code shall be from UNTDID 5305." A failure means the value is not in the required list.
• BR-S-*, BR-Z-*, BR-E-*, BR-AE-*… — category-specific rules, one family per VAT category: standard rate, zero rated, exempt, reverse charge and so on.

CIUS and Extension

A CIUS — Core Invoice Usage Specification — narrows EN 16931 for a country or sector. It may make an optional term mandatory or restrict a code list, but it may not add terms outside the core model or relax a rule. Peppol BIS Billing 3.0, the German XRechnung and the Dutch NLCIUS are CIUSes.

An Extension may go further and add information beyond the core model. The Factur-X EXTENDED profile is an example.

Which one applies is declared in BT-24, the specification identifier — UBL's cbc:CustomizationID or CII's guideline identifier. That is a claim by the producer. Checking it means running the corresponding rule set.

Why validation must be layered

Validating an invoice is not one operation. It is at least five:

• Well-formedness — is this parseable XML at all?
• Syntax detection — is it UBL, CII, or something else?
• XML Schema — is the structure and are the data types correct for that syntax and release?
• EN 16931 business rules — do the semantic and arithmetic rules hold?
• Country and profile rules — does it satisfy the CIUS or national rule set it claims?

A document can pass every schema check and fail a dozen business rules, because XML Schema cannot express "these amounts must add up". Reporting a single verdict hides which layer failed, which is the only thing that helps you fix it. It also matters that a layer which has not been executed is reported as not run rather than passed — the tools on this site are explicit about which layers have actually executed.

Try it

See the model resolved from a real document in the UBL viewer or the CII viewer.