# EN 16931 rules explained Source: https://veriport.io/guides/en-16931-business-rules-explained (published 2026-10-28) An e-invoice is validated in layers: the XML schema of its syntax (UBL 2.1 or CII D16B), the business rules of the European norm EN 16931 (published by CEN as schematron, release 1.3.16 today), then the rules of the specification it claims (XRechnung for Germany, Peppol BIS Billing 3.0 on the Peppol network). Every rule has an id that says which layer and which family it belongs to: read the prefix and you know where to look. The ten failures below are the ones the engine’s tests and the evidence run produce most often. - BR-01 … BR-65: presence rules (an invoice has a number, a seller name, at least one line). - BR-CO-*: calculations and conditions across fields (totals, VAT per breakdown, due date or payment terms). - BR-S, BR-Z, BR-E, BR-AE, BR-IC, BR-G, BR-O …: the rules of each VAT category (standard, zero, exempt, reverse charge, intra-Community, export, not subject). - BR-DEC-*: at most two decimals on amounts; BR-CL-*: code lists (currencies, countries, units, VATEX); UBL-CR-* / CII-SR-*: syntax restrictions. ## The layers above the norm A CIUS (core invoice usage specification) narrows EN 16931 for one community. **XRechnung** adds BR-DE-* rules (buyer reference, seller contact, payment instructions) and carries a few Peppol rules (PEPPOL-EN16931-R010 and R020: both electronic addresses). **Peppol BIS Billing 3.0** adds PEPPOL-EN16931-R* (one note at most, a buyer or order reference, no empty elements), PEPPOL-EN16931-CL* code lists, PEPPOL-COMMON-* identifier checks (R043: the Belgian enterprise number) and national rule sets (DE-R, NL-R, NO-R, SE-R …). A ZUGFeRD / Factur-X EN 16931 file is held to EN 16931 alone: no BR-DE rule applies unless the file claims XRechnung. ## Severities, and who may change them Each rule carries a flag: `fatal` rejects the document, `warning` does not. A validator configuration may change the level of a rule for its community: the KoSIT XRechnung configuration lowers **BR-CL-23** (unit code) and **BR-CL-21** (item scheme) to warnings and raises UBL-CR-646 and some CII-SR rules to errors. The same file can therefore pass as an XRechnung and fail as a Peppol document. The Veriport validator applies the KoSIT levels to XRechnung documents, and the evidence shows it reaches the same verdict as KoSIT on every sample. ## The ten failures seen most, and the fix | Rule | What it says | Fix | |---|---|---| | BR-CO-10 | The sum of line net amounts (BT-106) is not the sum of the lines | Compute BT-106 from the rounded line nets, not from unrounded quantities × prices. | | BR-CO-13 | Total without VAT (BT-109) ≠ lines − allowances + charges | Write BT-107 / BT-108 when there are document-level allowances or charges, and subtract or add them. | | BR-CO-14 | Total VAT (BT-110) ≠ the sum of the breakdown tax amounts | Sum the VAT of the breakdown groups, not the VAT of each line. | | BR-CO-15 / BR-CO-16 | Total with VAT or amount due does not add up | BT-112 = BT-109 + BT-110; BT-115 = BT-112 − paid + rounding. | | BR-S-08 | A breakdown taxable amount is not the lines of that rate minus allowances plus charges | One breakdown per category and rate, allowances and charges of the same rate included. | | BR-CO-17 | Breakdown VAT is not taxable × rate, rounded | Round the VAT per breakdown group, once, to two decimals. | | BR-DE-15 | XRechnung without buyer reference (BT-10) | Give the buyer reference: the Leitweg-ID for a German public body, else the order number or cost centre. | | PEPPOL-EN16931-R010 | No buyer electronic address (BT-49) | Give the buyer’s address: e-mail under EM for XRechnung, a Peppol identifier (0208, 9944 …) on Peppol. | | BR-33 / BR-38 | A document-level allowance or charge without reason or reason code | Give a reason text, a reason code (UNCL5189 / UNCL7161), or both. | | BR-CL-23 | Unit code outside UN/ECE Recommendation 20/21 | Use C62 (piece), HUR, DAY, MON, KGM, LTR, LS…; XRechnung reports it as a warning, Peppol as an error. | ## Reading a validation report `POST https://veriport.io/api/v1/einvoice/validate` answers with `valid`, the detected `profile` and two lists. Each finding has the `rule` (as published, or `XSD` for a schema error), the `severity`, the `path` (an XPath to the element, or the line of a schema error), the published `message` (CEN and Peppol in English, the BR-DE rules in German) and the `source` (`schema`, `cen-ubl`, `xrechnung-cii`, `peppol-ubl` …). Findings with `source: "veriport"` are Veriport’s own checks of national practice (a German VAT number check digit, a Belgian structured communication): never published rules, always warnings. ```bash curl -X POST "https://veriport.io/api/v1/einvoice/validate" \ -H "Content-Type: application/xml" \ --data-binary @invoice.xml ``` ```bash curl -X POST "https://veriport.io/api/v1/einvoice/validate" \ -H "Authorization: Bearer vp_live_YOUR_KEY" \ -F "file=@rechnung.pdf" ``` ```json { "valid": true, "profile": "xrechnung", "format": "xrechnung-ubl", "syntax": "ubl", "container": "xml", "attachment": null, "errors": [], "warnings": [], "checks": { "schema": { "status": "passed", "name": "UBL 2.1 (OASIS) and UN/CEFACT CII D16B XML schemas, from the KoSIT XRechnung validator configuration v2026-08-31" }, "ruleSets": [ { "id": "cen-ubl", "name": "CEN EN 16931 validation artefacts (UBL)", "release": "1.3.16", "sha256": "bafada015efbc5248bf5e05ad2191e1d9833ef96e9dd5f4bce420a747342da85", "fatal": 0, "warnings": 0 }, { "id": "xrechnung-ubl", "name": "XRechnung 3.0.2 schematron (UBL)", "release": "2.6.0", "sha256": "ca5e07afd04e72cd283d581590ffff3a15f4aac9d2f40c993345d78e67ea22b4", "fatal": 0, "warnings": 0 } ], "pdfa": null, "veriport": 0 }, "ms": 84 } ``` ## Preventing the arithmetic failures Most rejected invoices fail BR-CO-* because totals were computed from unrounded values. The rules expect line nets rounded to cents first, then sums of those, VAT computed once per category and rate. `POST https://veriport.io/api/v1/einvoice/create` does not take totals from the caller: it computes them from the lines, allowances and charges, so these rules hold by construction, and it refuses a caller’s `totals` field rather than ignoring it. ## Questions ### Where are the rules published? CEN TC 434 publishes the EN 16931 validation artefacts (schematron for UBL and CII) with the European Commission; KoSIT publishes the XRechnung rules; OpenPeppol publishes the Peppol BIS rules. The sources below link each release. ### Why does the same rule id appear twice in a report? A rule fires once per element it applies to: two lines with a wrong unit code give two findings with the same id and two paths. ### Can I check a file without an account? Yes, 4 checks a day per address on the [XRechnung](/tools/xrechnung-pruefen), [Factur-X](/tools/valider-factur-x) and [Peppol](/tools/peppol-validator) tool pages. ## Read next - [Peppol BIS Billing 3.0 validator](https://veriport.io/guides/peppol-bis-billing-3-validator) - [XRechnung erstellen per API](https://veriport.io/guides/xrechnung-erstellen-api) - [The e-invoice API](https://veriport.io/einvoice-api) - [Free XRechnung check](https://veriport.io/tools/xrechnung-pruefen) ## Sources - EN 16931 validation artefacts 1.3.16 (UBL and CII schematron, the business rules BR-*) — https://github.com/ConnectingEurope/eInvoicing-EN16931/releases/tag/validation-1.3.16 (2026-10-28) - Validator configuration XRechnung v2026-08-31 (XRechnung 3.0.2, CEN schematron 1.3.16, xrechnung-schematron 2.6.0) — https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/tag/v2026-08-31 (2026-10-28) - XRechnung — the German CIUS of EN 16931 (standard, versions and bundles; version 3.0.2 in force) — https://xeinkauf.de/xrechnung/ (2026-10-28) - Peppol BIS Billing 3.0 release 3.0.21: PEPPOL-EN16931-UBL.sch and the CEN files it ships — https://github.com/OpenPEPPOL/peppol-bis-invoice-3/tree/3.0.21/rules/sch (2026-10-28) - Directive 2014/55/EU on electronic invoicing in public procurement (the mandate behind EN 16931) — https://eur-lex.europa.eu/eli/dir/2014/55/oj (2026-10-28)