Eleven online validators, the same invoice, one day
In July 2026 the BDI observed that e-invoice validators disagree with each other. A great deal has been written about that; none of it was measured. This is the measurement: three files from the official KoSIT test suite, put through eleven freely accessible checking sites on one day.
Run · Reference rule set v2026-08-31
Why this exists
Anyone who wants to know whether their invoice will go through uploads it to a free validator. If "valid" comes back, that settles it — so the assumption goes.
The assumption does not hold. Three of the eleven sites tested do not process an XRechnung in UBL at all, and three more are working from a rule set predating 2 September 2026. In those cases "valid" does not mean the invoice is sound; it means this site found nothing.
Method
Every file comes from the official KoSIT test suite v2026-08-31 (Apache-2.0), published the same day as the rule set. No customer data, and every file can be reproduced.
Each change touches exactly one thing. Before the run, each was checked against the official KoSIT validator to confirm it triggers precisely the intended rule — two drafts failed that check because they were rejected by the XSD first, and were replaced.
Every entry below is an observation: what a tool reported about this file on this day, in the wording of its own report. Not an assessment of product quality.
The three files
A1
Unmodified conformance instance from the KoSIT test suite. Every validator should accept it.
B1
As A1, but the issue date carries a timezone offset: 2016-04-04+02:00. Valid per XSD, but since v2026-08-31 it triggers BR-TMP-6 (warning).
C1
As A1, but without BT-10 "Buyer reference" — the Leitweg-ID. Violates BR-DE-15.
What the tools reported
Rule set predating 2 September (3)
These three read UBL, apply the German rules and catch the missing Leitweg-ID. But for B1 they report no warning, where v2026-08-31 reports BR-TMP-6. All three display findings below error level elsewhere, so the absence is a result rather than a question of presentation.
Fehler: 1, Warnungen: 0 — "Es wird empfohlen das Dokument zurückzuweisen."
Codes: none named
File B1
Fehler: –, Warnungen: – — "Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten."
Codes: none named
Reads UBL correctly — it echoes the changed date back as 2016-04-04+02:00 — and catches the missing Leitweg-ID. For B1 it reports no warnings, where the KoSIT configuration v2026-08-31 reports BR-TMP-6 as a warning. That the same two fields read "1" and "0" for C1 shows the counters are populated when there is something to report.
The report names every step with its artefact. C1 matches the official run code for code. On B1, BR-TMP-6 is absent while BR-DE-TMP-32 is still shown at information level.
XRechnung 3.0 STANDARD — 11 Regeln bestanden, 2 gescheitert
Codes: BR-DE-15, BR-DE-TMP-32
File B1
XRechnung 3.0 STANDARD — "Format-Validierung war erfolgreich", 1 gescheitert
Codes: BR-DE-TMP-32
Names the detected profile URN and the engine version. BR-DE-15 correctly disappears once the Leitweg-ID is restored. BR-TMP-6 is not reported for B1; BR-DE-TMP-32 is, at information level.
Does not process XRechnung in UBL (3)
XRechnung permits two syntaxes, UBL and CII. Which one is required is decided by the receiver, not the sender. These three sites do not process the UBL variant — and do not always report that as what it is.
"weder Fehler noch Warnungen … konform" — empfohlen anzunehmen
Codes: none named
Its own report names the detected document type as "EN16931 (CII)", though the file is UBL and declares the German CIUS in cbc:CustomizationID. It is checked against the CII schema accordingly; the single error on B1 concerns ram:IssueDateTime, a CII element that does not appear in the submitted file. For C1 no Schematron step appears and the word "XRechnung" is absent from the report — an invoice with no Leitweg-ID is recommended for acceptance.
The page advertises "XRechnung XML oder ZUGFeRD PDF". Given an XRechnung in UBL it answers that it found no CII element, quoting the submitted file's UBL root element back.
Reads UBL, catches the missing Leitweg-ID and names the rule code. Nothing can be said about BR-TMP-6: the interface shows a pass/fail verdict rather than a list of findings, so silence is not evidence either way.
Validates something else, deliberately (2)
Validates a different standard or catalogue. Silence on the German rules is correct here, not a defect.
Validates EN 16931, not the German CIUS. Not reporting BR-DE-15 is correct here, not a defect. The practical consequence: "it passed the EU validator" says nothing about a German B2G invoice.
Within what was tested, the profile catalogue contains no XRechnung and no EN 16931 profile; the public demo profiles are EDIFACT INVOIC, SAP XML ZORDERS05, UBL 2.0 Invoice and EDIFACT DESADV. Validating against "UBL 2.0 Invoice" would be a schema check and not an XRechnung result, so it was not run.
Not tested (1)
Could not be tested with this method. That is a limit of the method, not a statement about the tool.