How to validate an XRechnung (KoSIT validator explained)

By evoicely · Last checked 20 October 2026

To validate an XRechnung, you check the XML against three sets of rules: the UBL or CII XML schema, the EN 16931 business rules, and the German XRechnung rules (BR-DE-*). The official tool for this is the KoSIT validator, a Java program, run with KoSIT's XRechnung validator configuration. A file with no errors is "acceptable"; warnings don't change that. For a quick check without installing anything, upload the file to our free e-invoice validator. It applies the same official rule files, shows every error with its rule ID, and doesn't store your file.

What "valid" means

An XRechnung is checked in layers. Each layer has its own rule IDs, so the ID in an error message tells you which one it comes from:

The current configuration bundles the EN 16931 rules in version 1.3.16 and the XRechnung Schematron 2.6.0 for XRechnung 3.0.2 (validator configuration release of 31 August 2026; sources: EN 16931 validation artefacts, XRechnung Schematron).

Each rule has a severity. In KoSIT's configuration, a fatal or error finding makes the file "REJECT". A warning, such as BR-DE-19 for an IBAN with a wrong check digit, leaves it "ACCEPTABLE", and so does an information note.

How the validator picks the rules

The KoSIT validator is only an engine. In its own words, it "does not know anything about XML documents and has no own validation rules" (KoSIT validator on GitHub). The rules come from a configuration, whose scenarios.xml lists scenarios. Each scenario matches on the document's specification identifier (BT-24): cbc:CustomizationID in UBL, the guideline ID in rsm:ExchangedDocumentContext in CII.

For a standard XRechnung 3.0 that identifier must be exactly:

urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

The XRechnung configuration also has scenarios for the XRechnung Extension, for XRechnung CVD, and for plain EN 16931 files (identifier urn:cen.eu:en16931:2017), which get the EN 16931 rules only. A file whose identifier matches none of them, such as an old xrechnung_2.3 file, is rejected without any rule message: the report just says no scenario matched. If KoSIT rejects a file and lists no errors, check BT-24 first.

Option 1: check it online

Our free validator reads the specification identifier and picks the rules the same way, from the same KoSIT configuration (XRechnung 3.0.2, configuration of 31 August 2026). To use it:

1. Open the validator, choose the XML file (up to 10 MB) or paste the XML.
2. Click Check invoice. You get a "Valid" or "Not valid" verdict, the rule sets that ran, and each error and warning with its rule ID, the rule text and where in the document it applies.
3. Below the verdict, the invoice is laid out like a paper invoice, so you can see what the XML actually says.

It handles XRechnung in UBL and CII, ZUGFeRD / Factur-X (as XML or as a PDF with the XML embedded) and Peppol BIS Billing 3.0. The file is checked in memory and never stored. Unlike the KoSIT validator, when it doesn't recognise the specification identifier it still runs the EN 16931 core rules and tells you so, rather than only rejecting the file.

Passing means the file meets the published rules. It doesn't guarantee that a particular buyer or portal accepts it; some run checks of their own.

Option 2: run the KoSIT validator yourself

Run it yourself when you generate invoices in bulk or want the check in your build. You need Java 11 or later (usage instructions in the configuration repository).

# the validator engine (standalone jar)
curl -LO https://repo1.maven.org/maven2/org/kosit/validator/1.6.3/validator-1.6.3-standalone.jar

# the XRechnung configuration (rules, schemas, scenarios.xml)
curl -LO https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip
unzip xrechnung-3.0.2-validator-configuration-2026-08-31.zip -d xrechnung-config

# validate one or more files
java -jar validator-1.6.3-standalone.jar \
  -s xrechnung-config/scenarios.xml \
  -r xrechnung-config \
  -o reports -h invoice.xml

-s is the scenario file, -r the directory the configuration's paths are relative to, -o the output directory, and -h also writes an HTML version of the report. Check the configuration releases for newer versions before you pin one.

The console prints a summary table. This is the output for an invoice without a buyer reference (shortened):

|File          |Schema |Schematron|Acceptance|Error/Description            |
|invoice.xml   |   Y   |    N     |  REJECT  |[BR-DE-15] Das Element "Buyer|
|              |       |          |          | reference" (BT-10) muss übe…|
Acceptable:  0  Rejected:  1

The validator exits with status 1 when a file is rejected and 0 when all files are acceptable, so a CI job fails on errors and passes with warnings. For many files, pass them all in one call: starting the JVM takes longer than the checks. The validator also has a daemon mode (-D) that starts an HTTP server, by default on localhost port 8080, for services that validate continuously (KoSIT validator README).

Reading the report

For each file you get invoice-report.xml and, with -h, invoice-report.html. The HTML report is in German (Prüfbericht). It shows:

• the scenario that matched, which tells you which rules ran;
• the seller name, invoice number and issue date it found, as a sanity check that it read the right document;
• every finding with its rule ID, severity, text and an XPath to the element;
• the verdict: accept or reject.

The BR-DE rule texts are in German; the EN 16931 and Peppol ones in English. The rule ID is what to search for. Our guide to common XRechnung validation errors translates the ones Stripe sellers run into most and explains how to fix each.

What validation doesn't tell you

• Whether the content is right. The rules check that a VAT ID is there and starts with a country code, not that it's yours or that the VAT treatment is correct.
• Whether the buyer reference routes. Any non-empty BT-10 passes BR-DE-15. A public authority needs its exact Leitweg-ID.
• Whether a ZUGFeRD PDF is a valid PDF/A-3. The XRechnung configuration checks XML only. For ZUGFeRD, the embedded XML can be checked against EN 16931, but the PDF needs a separate PDF/A check.
• Peppol. Peppol BIS Billing 3.0 has its own rules from OpenPEPPOL (Peppol BIS Billing 3.0), which the XRechnung configuration doesn't include.

Which version to validate against

XRechnung 3.0 has applied since 1 February 2024, and KoSIT says it stays in force until at least 31 July 2027. The current bundle is 3.0.2 with the bugfix release of 31 August 2026. A preliminary XRechnung 4.0 was published in September 2026, with the final version expected in spring 2027 (XRechnung versions and bundles, xeinkauf.de). Validate against the configuration for the version your buyers expect; until 4.0 is final and in force, that's 3.0.

Related guides

• Common XRechnung validation errors (BR-DE-*): what each rule means and how to fix it.
• How to open and read an XRechnung XML file: when you need to see what's in it.
• XRechnung vs ZUGFeRD: which format your customers need.
• Germany's e-invoicing mandate for Stripe users: who has to send e-invoices, and from when.

Where evoicely fits

Check an XRechnung now, free and without signing up. If your invoices come from Stripe, evoicely turns them into XRechnung and ZUGFeRD and checks every file with these rules before it goes out. Get started: it's free for 10 e-invoices a month.

This is general information, not legal or tax advice. A file that passes validation is technically valid against the published rules; check what applies to your business with your tax advisor.