EN 16931

Short definition

EN 16931 is the European standard that defines the semantic data model for electronic invoices. Published by CEN (European Committee for Standardization) in 2017, it is today the shared foundation for every relevant European e-invoice format: XRechnung, Peppol BIS Billing 3.0, ZUGFeRD 2.x, Factur-X.

The standard is the technical implementation of EU directive 2014/55/EU, which mandated electronic invoicing in public procurement.

What EN 16931 covers

EN 16931 does not define how an invoice looks in XML — it defines which fields an invoice must contain semantically:

• Core Invoice Model — a data model with around 140 Business Terms (BT) plus Business Groups (BG)
• Syntax bindings — two permitted XML realisations: UN/CEFACT CII and OASIS UBL
• Business rules — mandatory semantic consistency rules (e.g. “sum of line items = line-item net before discount”)

The standard does not cover national specifics — no German Leitweg-ID, no French SIRET references, no Norwegian VAT rules. Those live in CIUS.

Business Terms (BT) and Business Groups (BG)

Every relevant field carries a BT number:

• BT-1 — Invoice number
• BT-2 — Invoice issue date
• BT-3 — Invoice type (380 = invoice, 381 = credit note, …)
• BT-10 — Buyer reference (in Germany: Leitweg-ID)
• BT-112 — Invoice total amount with VAT
• BG-25 — Invoice line (Group, contains BT-126 through BT-141)

This numbering is language- and syntax-independent — a German, a French and a Norwegian EN 16931 invoice carry the same semantic meaning in field BT-10.

CIUS — Core Invoice Usage Specifications

Because EN 16931 is intentionally neutral, it allows national or industry-specific restrictions via so-called CIUS. A CIUS can make optional fields mandatory, restrict allowed code values or fix text lengths. It cannot extend the standard — only tighten it.

Well-known CIUS:

• XRechnung (Germany, KoSIT)
• Peppol BIS Billing 3.0 (OpenPeppol)
• Factur-X / ZUGFeRD profile EN 16931 (DE/FR)

Every CIUS ships its own Schematron that checks the additional rules.

Validation chain

An EN 16931 invoice passes through multiple layers:

1. XSD schema of the chosen syntax (UBL 2.1 or CII) — purely structural
2. EN 16931 Schematron — around 150 business rules from the standard
3. CIUS Schematron — national additional rules (e.g. Leitweg-ID format for XRechnung)
4. optionally transport layer — Peppol Schematron, recipient-specific rules

Only when every layer passes is the invoice considered valid.

EN 16931 with the Dokmatiq API

All e-invoicing endpoints in the Dokmatiq API produce documents validated against the full EN 16931 validation chain:

curl -X POST https://api.dokmatiq.com/v1/einvoice/validate \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -H "Content-Type: application/xml" \
  --data-binary "@invoice.xml"

The response lists each rule hit — which layer reports the violation, with BT/BR references. That makes it easy to tell whether a defect is a core EN 16931 issue or a CIUS-specific one.

Common pitfalls

1. BT number ≠ XML tag — the BT number is semantic, the XML tag is syntactic. A BT-10 can have different tag names in UBL and CII
2. Overlooking CIUS rules — EN 16931-compliant does not automatically mean XRechnung-compliant
3. Legacy data — older ZUGFeRD 1.0 documents follow the predecessor logic, not EN 16931
4. Underestimating business rules — many validators only check the schema layer; real EN 16931 conformance requires the Schematron too