Validate an XRechnung without sending it to anyone

What the check runs

Counts are per grammar because the two are validated by different artefacts, and they are assertions, not rule ids: one id is usually two assertions, one written against CII and one against UBL. Numbers quoted elsewhere are often ids, or one grammar only, which is how “XRechnung has 205 rules” and “XRechnung has 862 rules” both circulate.

Order matters, and so does severity. The engine checks the document's XML structure first — an element where the grammar does not allow one, an element in the wrong place, an attribute the schema does not permit — and reports those as SCHEMA findings rather than as rule ids. Only then does it run the Schematron rules, and it runs them in their artefacts' own phases: EN16931-model-phase, codelist_phase, syntax_phase and xrechnung-model. Of the 862 assertions it applies to a CII invoice, 379 are fatal, 482 are warnings and exactly 1 is informational.

The severity comes from the artefact's own wording: a rule that says muss is fatal and one that says soll is a warning. Almost all of XRechnung's additions are muss; the warnings are the ones people argue about, and both this page and the command-line tool still call the invoice not valid when only warnings fire, because that is how the buyers' gates treat them. The one informational assertion is BR-DE-TMP-32, a should about stating a delivery date or an invoicing period, which is reported without failing anything.

Every rule XRechnung 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.

The rules that catch people out

Rejections are not spread evenly over the rule set. These are the ones that turn up most in practice, in plain English — the table above has each id's own wording, and the search box finds it.

• BR-DE-15, BR-DE-16 — the buyer reference (BT-10) is the Leitweg-ID, and it is mandatory for public-sector invoices. A private buyer without one still needs something in BT-10.
• BR-DE-2, BR-DE-27, BR-DE-28 — the seller contact group (BG-6) is mandatory under XRechnung even though the norm only asks for it conditionally, and once it is there the phone number wants at least three digits and the email address has to look like one.
• BR-DE-23, BR-DE-24, BR-DE-25 — the payment means code (BT-81) has to match the payment group you filled in: 30 or 58 means a credit transfer (BG-17) and nothing else, 48/54/55 means a card (BG-18), 59 means a direct debit (BG-19). Each of those is really two assertions: one requiring the group, one forbidding the other two.
• BR-DE-10, BR-DE-11 — if you fill in a ship-to address (BG-15), the city and the post code are not optional in Germany.
• BR-DEX-04 to BR-DEX-08 — party identifier scheme ids have to come from the ISO 6523 ICD list and endpoint scheme ids from the CEF EAS list, so GLN written freehand fails where a code would pass.
• BR-TMP-7 — dates in CII carry format="102" and are written YYYYMMDD. This is the classic one for anyone generating XML by hand: 2026-11-03 is not a date as far as the artefacts are concerned.
• BR-DE-CVD-01 to BR-DE-CVD-05 — vehicle deliveries get their own checks: contract reference (BT-12) and tender or lot reference (BT-17) become mandatory, and the CVD classification identifier has to carry an allowed vehicle category.

Warnings are the cheap fixes and the ones people leave: BR-DE-21 wants BT-24 to state the XRechnung specification identifier, BR-DE-26 wants a corrected invoice (BT-3 = 384) to reference the invoice it corrects, and BR-DE-19 and BR-DE-20 check the IBAN you put in when you said the payment was SEPA credit transfer or direct debit.

XRechnung, ZUGFeRD and Peppol: what actually runs

XRechnung is a CIUS: a national tightening of EN 16931 that may add rules and may not relax any. ZUGFeRD and Factur-X are a different axis — they are the same invoice embedded in a PDF/A-3 file, so a ZUGFeRD invoice destined for a German public buyer is normally checked as Factur-X envelope plus XRechnung business rules. Peppol BIS Billing 3.0 is a network profile with its own copy of the norm's artefacts, and Germany's participation in Peppol adds the DE-R country rules on top of that.

Pick the rule set you are being judged by, not the one that sounds closest: the validator on this page, the Factur-X checker, the CLI and the API all take the same choice, and the rule-set comparison counts exactly what each one adds.

The same check in a pipeline

The browser is for looking at one invoice. For checking a thousand, or for a rule that must fail a build, the engine is also a static binary with the rule sets embedded — no Java, no Saxon, no rule files to install beside it:

einv validate -cius xrechnung invoice.xml
einv validate -json -cius xrechnung invoice.xml | jq '.findings[].id'
einv artefacts -cius xrechnung
einv rules -json -syntax cii -cius xrechnung | wc -l

Exit status is non-zero when a document fails, so einv drops into CI as-is, and the JSON is the same findings the page shows. It is the same library that runs in this tab and behind the hosted API: see the command-line and Go library page for the library API and the batch mode.

The data behind this page

These figures get wrong when somebody retypes them into a tender response or a procurement policy, so the files the page is built from are published beside it:

• rule-sets.csv — every assertion each rule set adds, with rule_set, rule_set_version, syntax, rule_id, severity, added_over, phase, message and engine. Filter rule_set to XRechnung and you have the 52 CII and 56 UBL rules on this page, with the artefact version each was counted under.
• rule-sets.json — the same comparison in the shape the build reads, including the counts in the tables above.
• rules.csv and the rule reference for the norm underneath, and the data-element index when you know the element (BT-10) but not the rule.

Every number on this page is generated at build time from the artefacts the pinned engine loads, and the build stops if that data was counted from a different engine than the one the site ships — a stale figure here is a failed build rather than a paragraph nobody remembered to edit. The version they were counted under is v0.2.9.

The rules themselves are other people's publications: the norm's Schematron artefacts from the Connecting Europe Facility (EUPL 1.2) and XRechnung's from KoSIT (Apache 2.0), embedded unmodified. What is published here is the counting and the runner; sources and licences are spelled out in the engine repository's NOTICE.md.

Frequently asked