EN 16931: the European e-invoice standard, explained for developers
EN 16931 defines what an electronic invoice must contain and how it is checked, independent of the file format. XRechnung, ZUGFeRD, Factur-X and Peppol BIS are all built on it, so its business rules are the errors you will see most, whatever format you produce.
Updated 19 October 2026
What the standard is
The EU's public-procurement directive 2014/55/EU asked the European standards body CEN for a common e-invoice model, and obliged public authorities to receive and process invoices that follow it (from April 2019; sub-central authorities from April 2020 at the latest). The result is the EN 16931 series, maintained by CEN/TC 434:
- EN 16931-1, the semantic data model: about 160 business terms (BT-1 Invoice number, BT-112 Invoice total amount with VAT …) in business groups (BG-4 Seller, BG-25 Invoice line …), plus the business rules.
- CEN/TS 16931-2, the list of syntaxes: UBL 2.1 and UN/CEFACT CII.
- CEN/TS 16931-3-2 and 3-3, the bindings that say where each business term goes in UBL and CII.
The validation artefacts (Schematron for UBL and CII) are published by CEN/TC 434 on GitHub. Every serious validator, including the KoSIT validator and Invoir, runs these files.
CIUS and extensions
Countries and communities adapt the core model in two ways:
- A CIUS (Core Invoice Usage Specification) only restricts: it makes optional fields mandatory or narrows code lists. Every CIUS invoice is still a valid EN 16931 invoice. XRechnung and Peppol BIS Billing 3.0 are CIUS; so are the BASIC and EN 16931 profiles of ZUGFeRD/Factur-X.
- An extension adds fields the core lacks. Its files are "conformant" rather than "compliant". Factur-X EXTENDED and the XRechnung extension are examples.
The specification identifier (BT-24) says which one a file follows: urn:cen.eu:en16931:2017 for the plain standard, followed by #compliant#… for a CIUS or #conformant#… for an extension.
The business rules
Rule IDs tell you what kind of problem you have:
| Prefix | Checks | Example |
|---|---|---|
BR-01 … BR-65 | Mandatory fields and groups | BR-16 An Invoice shall have at least one Invoice line (BG-25). |
BR-CO-* | Calculations and conditions | BR-CO-15 Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). |
BR-CL-* | Code lists | BR-CL-23 Unit code must be coded according to UN/ECE Recommendation 20 with Rec 21 extension. |
BR-S-*, BR-Z-*, BR-E-*, BR-AE-*, BR-IC-*, BR-G-*, BR-O-*, BR-AF-*, BR-AG-* | One set per VAT category: standard rate (S), zero rate (Z), exempt (E), reverse charge (AE), intra-community supply (K), export (G), not subject to VAT (O), Canary Islands (L) and Ceuta/Melilla (M) | BR-AE-02 Reverse charge needs the seller's and the buyer's VAT identifiers. |
The rules that fail most, and the fix
BR-CO-10,BR-CO-13,BR-CO-15,BR-CO-16Totals don't add up- The document totals must be exact sums of the values in the file: line nets (BT-131) → sum of lines (BT-106) → minus allowances, plus charges → total without VAT (BT-109) → plus VAT (BT-110) → total with VAT (BT-112) → minus prepaid, plus rounding → amount due (BT-115). Compute the totals from the rounded values you write, never from unrounded internal numbers.
BR-CO-17,BR-S-09VAT amount off by a cent- VAT is computed per VAT category and rate on the taxable amount, then rounded to two decimals. Rounding VAT per line and adding the lines up gives a different result. Do it per rate.
BR-S-08VAT breakdown doesn't match the lines- For each rate, the taxable amount in the breakdown (BG-23) must equal the line nets at that rate plus charges minus allowances at that rate. One breakdown entry per category and rate.
BR-S-02,BR-CO-09,BR-CO-26Seller identification- Standard-rated invoices need the seller's VAT ID (or tax registration ID); VAT IDs need a country prefix like
DE,FR,BE; and the seller needs at least one identifier. BR-AE-02,BR-AE-08,BR-AE-10Reverse charge- Both VAT IDs, a breakdown entry for category AE, and an exemption reason (code or the text "Reverse charge").
BR-E-10Exempt without a reason- A breakdown with category E needs an exemption reason code (BT-121) or text (BT-120).
BR-CL-23Unit code- Use UN/ECE Rec 20/21 codes:
C62(one/piece),HUR(hour),DAY,KGM,MTR. "pcs" or "Stk" fail. BR-61Credit transfer without an account- Payment means 30 or 58 (credit transfer, SEPA) needs the payment account identifier (BT-84), usually the IBAN.
Where EN 16931 is required
- Germany: an e-invoice is one that follows EN 16931 (or an agreed format the data can be extracted from) (BMF FAQ, question 7). See the German mandate.
- France: the reform's formats (UBL, CII, Factur-X) are EN 16931 syntaxes. See the French mandate.
- Belgium: Peppol BIS, or another EN 16931 format both parties agree on. See the Belgian mandate.
- Cross-border in the EU: Council Directive (EU) 2025/516 (VAT in the Digital Age) introduces e-invoicing and digital reporting for intra-EU business transactions from 1 July 2030, based on the European standard.
Check a file in your browser, or over the API. The free validator runs the official rules (KoSIT, CEN and Peppol Schematron, Mustang, veraPDF) and lists every error with its rule ID. Nothing is stored. The same check is one HTTP call with a free API key: 25 documents a month, no credit card.
Sources
- Directive 2014/55/EU on electronic invoicing in public procurement.
- CEN/TC 434 validation artefacts (rule texts quoted above).
- Council Directive (EU) 2025/516 of 11 March 2025 (ViDA).
- Bundesministerium der Finanzen: FAQ E-Rechnung, question 7.