What XRechnung and Peppol BIS add to EN 16931, counted

Every assertion a rule set adds

Search Severity any fatal warning information Syntax any CII UBL

Nothing matches everything in the box. The search needs every word to appear somewhere in a row, so try dropping one.

How to read the difference

A CIUS (Customisation of the European Invoice Standard) is a national tightening of the norm: Germany’s XRechnung keeps every EN 16931 rule and adds its own — the BR-DE-* family, plus BR-DEX-*, BR-DE-CVD-* and the BR-TMP-* checks that arrive with XRechnung 3.0. It cannot relax anything, because a CIUS is allowed only to add.

A profile such as Peppol BIS Billing 3.0 is a published bundle: its own copy of the norm’s artefacts, plus network rules (BR-AF-*, BR-AG-*, PEPPOL-EN-*, PEPPOL-COMMON-R-*) and the country rule sets the network ships (DE-R, DK-R, SE-R, NL-R, IT-R, NO-R, GR-R, IS-R and friends). That is why its totals move for two different reasons: it genuinely adds rules, and it carries a slightly older copy of the norm — Peppol BIS 3.0.21 ships EN 16931 Schematron 1.3.16 while the artefacts this engine loads for the plain norm are 1.3.17. Reading “Peppol has more rules” as “Peppol is stricter” misses half of it.

Severity comes from the artefacts, not from our preference: fatal is a shall, warning is a should, and EN 16931 itself does not reject a document on a warning. Peppol and most national gateways do promote warnings to failures, so if the invoice is going through an access point, fix both.

Get the same numbers in a terminal

These are not screenshots of a database. The command that answers the question is the one the library enforces:

einv artefacts -json -cius xrechnung
einv rules -json -syntax ubl -cius xrechnung | wc -l
einv validate -cius xrechnung invoice.xml
einv validate -profile peppol invoice.xml

einv is a static binary with the rule sets embedded — no Java, no Saxon, no rule files to install beside it. It is the same engine the pages on this site run in your browser and the hosted API runs behind a key: see the command-line and library page and the API & licences page.

The data behind the page

These figures get wrong when someone retypes them into a tender response, a procurement policy or a support ticket. Both files this page is generated from are published beside it, so the numbers can be cited instead of copied:

• rule-sets.csv — one row per added assertion, 408 rows under rule_set, rule_set_version, syntax, rule_id, severity, added_over, phase, message, engine. The wording is the artefact’s own, quoted the RFC 4180 way, so commas and quotation marks survive an import into a spreadsheet.
• rule-sets.json — the same comparison in the shape the page builder reads: the counts in the tables above, for all 3 rule sets and both grammars, with every added assertion listed in full.

Both files are rebuilt from the engine the site pins, and the build stops if the tracked file was counted from a different version than the one it ships with — so a stale number here is a failed build rather than an out-of-date paragraph. The version they were counted under is v0.2.9.

The assertions are other people’s publications: the norm’s Schematron artefacts from the Connecting Europe Facility (EUPL 1.2), XRechnung’s from KoSIT (Apache 2.0), Peppol BIS’s from OpenPEPPOL. What is published here is the counting; the sources and licences are spelled out in the engine repository’s NOTICE.md. If you republish the wording, keep that attribution with it.

Frequently asked