What is EN 16931? The European e-invoicing standard, explained

EN 16931 is the European standard that defines the semantic data model for the core elements of an electronic invoice. It is the common “what an invoice means” layer underneath the French, German, and other EU mandates: a fixed list of business terms — seller, buyer, line items, VAT breakdown, totals — with rules about how they relate. It was developed by CEN (the European Committee for Standardization) and mandated for public procurement by EU Directive 2014/55/EU. It is a data-model and rules standard — not a transmission network and not a single file format.

This page explains what EN 16931 is; it is not legal or tax advice. National mandates layer their own rules (CIUS) on top of the core, and dates and requirements are set by each country’s authority. Confirm your obligations with a registered platform and the relevant authority before you rely on a specific rule or date. Slipstack tracks the invoice format, not your filing status.

The core: one model, ~160 business terms

EN 16931-1 specifies the core invoice: roughly 160 information elements, each a numbered business term (BT) grouped into business groups (BG) — for example BT-1 (invoice number), BG-4 (seller), BG-7 (buyer), BG-23 (VAT breakdown), BT-112 (invoice total with VAT). The standard also defines the business rules that tie them together: arithmetic checks (line totals sum to the document total), conditional requirements (a VAT category needs an exemption reason when zero-rated), and code-list constraints (currencies, VAT categories, units). Get the model and the rules right and the invoice is “EN 16931 core compliant” regardless of which syntax carries it.

Two syntaxes: UBL and CII

The standard binds that semantic model to two permitted XML syntaxes:

UBL 2.1 (OASIS Universal Business Language) — the syntax most XRechnung and Peppol invoices use in the wild.
UN/CEFACT CII (Cross Industry Invoice) — the syntax embedded inside a Factur-X / ZUGFeRD hybrid PDF.

Same business terms, different XML element names. A tool that maps your data to the EN 16931 model can emit either syntax — or wrap the CII inside a PDF/A-3 for a human-readable Factur-X file.

CIUS and extensions: the core is the floor, not the ceiling

National mandates rarely use the bare core. They publish a CIUS (Core Invoice Usage Specification) — a restriction that makes some optional fields mandatory and tightens code lists, while staying compatible with the core. XRechnung (Germany) and Peppol BIS Billing 3.0 are the two you will meet most. An extension goes the other way, adding fields beyond the core for a sector that needs them. The practical takeaway: passing the EN 16931 core rules is necessary but not always sufficient — your buyer’s platform may enforce a stricter CIUS on top.

Where Slipstack fits — and where it does not

Slipstack is a format generator and validator. It turns the JSON you already use into EN 16931 core CII or UBL XML — or a Factur-X / ZUGFeRD hybrid PDF — and checks the core business rules. It does not transmit invoices, exchange them with your buyers, or report anything to a tax authority; that is the job of a registered PDP. And it validates the EN 16931 core — not the KoSIT XRechnung CIUS, Peppol BIS, or any platform-specific profile, which are stricter. We are clear about that line so you do not ship a file you believe is fully compliant when a CIUS still has to pass.

Validate the core before anything downstream

Whether Slipstack builds your XML or your own code does, paste or upload the CII (or UBL) into the free EN 16931 / XRechnung core validator — up to 20 checks a day, no signup. Scope, stated plainly: it runs the EN 16931 core schematron (ConnectingEurope release v1.3.16). It does not check the KoSIT XRechnung CIUS, Peppol BIS, or any PDP-specific rules.

Generate EN 16931 core from one JSON call

Emit compliant CII / UBL XML or a Factur-X PDF, and validate the core rules for free first.

See pricing Validate an invoice free