Elf Online-Validatoren, dieselbe Rechnung, ein Tag

Der BDI hat im Juli 2026 festgestellt, dass E-Rechnungs-Validatoren sich uneinig sind. Geschrieben wurde darüber viel, gemessen wurde es nicht. Hier ist die Messung: drei Dateien aus der offiziellen KoSIT-Testsuite, an einem Tag durch elf frei zugängliche Prüfseiten geschickt.

Durchlauf · Referenz-Regelwerk v2026-08-31

Warum es das gibt

Wer wissen will, ob seine Rechnung durchgeht, lädt sie bei einem kostenlosen Validator hoch. Kommt „gültig“ zurück, ist die Sache erledigt — so die Annahme.

Diese Annahme trägt nicht. Drei der elf geprüften Seiten verarbeiten eine XRechnung in UBL überhaupt nicht, drei weitere arbeiten mit einem Regelwerk von vor dem 2. September 2026. Ein „gültig“ bedeutet in diesen Fällen nicht, dass die Rechnung in Ordnung ist, sondern dass diese Seite nichts gefunden hat.

Methode

Alle Dateien stammen aus der offiziellen KoSIT-Testsuite v2026-08-31 (Apache-2.0), veröffentlicht am selben Tag wie das Regelwerk. Keine Kundendaten, und jede Datei lässt sich nachbauen.

Jede Änderung betrifft genau eine Sache. Vorab wurde gegen den offiziellen KoSIT-Validator geprüft, dass sie auch genau die vorgesehene Regel auslöst — zwei Entwürfe fielen dabei durch, weil sie schon am XSD scheiterten, und wurden ersetzt.

Jede Zeile unten ist eine Beobachtung: was ein Werkzeug an diesem Tag zu dieser Datei gemeldet hat, im Wortlaut seines eigenen Berichts. Keine Bewertung von Produktqualität.

Die drei Dateien

A1
Unveränderte Konformitätsinstanz aus der KoSIT-Testsuite. Jeder Validator sollte sie annehmen.
B1
Wie A1, aber das Rechnungsdatum trägt einen Zeitzonen-Offset: 2016-04-04+02:00. Nach XSD gültig, seit v2026-08-31 aber BR-TMP-6 (Warnung).
C1
Wie A1, aber ohne BT-10 "Buyer reference" — die Leitweg-ID. Verstößt gegen BR-DE-15.

Was die Werkzeuge gemeldet haben

Regelwerk von vor dem 2. September (3)

Diese drei lesen UBL, wenden die deutschen Regeln an und erkennen die fehlende Leitweg-ID. Für B1 melden sie aber keine Warnung, während die Fassung v2026-08-31 dort BR-TMP-6 meldet. Alle drei zeigen an anderer Stelle Feststellungen unterhalb der Fehlerschwelle an — das Fehlen ist also ein Befund und keine Anzeigefrage.

Serviceportal Baden-Württemberg

Eigene Versionsangabe: 5.0.10
Datei C1
Fehler: 1, Warnungen: 0 — "Es wird empfohlen das Dokument zurückzuweisen."
Codes: keine genannt
Datei B1
Fehler: –, Warnungen: – — "Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten."
Codes: keine genannt

Liest UBL korrekt — das geänderte Datum wird als 2016-04-04+02:00 zurückgegeben — und erkennt die fehlende Leitweg-ID. Für B1 werden keine Warnungen gemeldet, während die KoSIT-Konfiguration v2026-08-31 dort BR-TMP-6 als Warnung meldet. Dass bei C1 dieselben Felder "1" und "0" zeigen, belegt: die Zähler werden befüllt, wenn es etwas zu melden gibt.

invoice-portal.de

Eigene Versionsangabe: XRechnung 3.0.2
Datei C1
XSD 0 · CEN-EN16931-UBL 0 · XRechnung 3.0.2: 2
Codes: BR-DE-15, BR-DE-TMP-32
Datei B1
XRechnung 3.0.2: 1
Codes: BR-DE-TMP-32

Der Bericht benennt jeden Prüfschritt mit seinem Artefakt. C1 stimmt code-genau mit dem offiziellen Lauf überein. Bei B1 fehlt BR-TMP-6, während BR-DE-TMP-32 auf Informationsstufe weiterhin angezeigt wird.

portinvoice

Eigene Versionsangabe: 2.26.0
Datei C1
XRechnung 3.0 STANDARD — 11 Regeln bestanden, 2 gescheitert
Codes: BR-DE-15, BR-DE-TMP-32
Datei B1
XRechnung 3.0 STANDARD — "Format-Validierung war erfolgreich", 1 gescheitert
Codes: BR-DE-TMP-32

Nennt die erkannte Profil-URN und die Engine-Version. BR-DE-15 verschwindet korrekt, sobald die Leitweg-ID wieder eingesetzt wird. BR-TMP-6 wird bei B1 nicht gemeldet, BR-DE-TMP-32 auf Informationsstufe schon.

Verarbeitet XRechnung in UBL nicht (3)

XRechnung erlaubt zwei Syntaxen, UBL und CII. Welche verlangt wird, entscheidet der Empfänger, nicht der Absender. Diese drei Seiten verarbeiten die UBL-Variante nicht — und melden das nicht immer als das, was es ist.

Datei A1
"weder Fehler noch Warnungen … konform"
Codes: keine genannt
Datei B1
"1 Fehler / 0 Warnungen … nicht konform" — Schritt: CII-XSD
Codes: cvc-complex-type.2.4.b
Datei C1
"weder Fehler noch Warnungen … konform" — empfohlen anzunehmen
Codes: keine genannt

Der eigene Prüfbericht nennt als erkannten Dokumenttyp "EN16931 (CII)", obwohl die Datei UBL ist und in cbc:CustomizationID das deutsche CIUS deklariert. Geprüft wird entsprechend gegen das CII-Schema; der einzige Fehler bei B1 betrifft ram:IssueDateTime, ein CII-Element, das in der eingereichten Datei nicht vorkommt. Bei C1 erscheint kein Schematron-Schritt und das Wort "XRechnung" kommt im Bericht nicht vor — eine Rechnung ohne Leitweg-ID wird zur Annahme empfohlen.

Datei C1
"Kein CrossIndustryInvoice-Element gefunden."
Codes: keine genannt

Die Seite wirbt mit "XRechnung XML oder ZUGFeRD PDF". Auf eine XRechnung in UBL antwortet sie mit dem Hinweis, kein CII-Element gefunden zu haben, und zitiert dabei das UBL-Wurzelelement der eingereichten Datei zurück.

Datei A1
"Kein E-Rechnungs-Profil erkannt · Weder ZUGFeRD/Factur-X noch XRechnung"
Codes: keine genannt
Datei C1
"Kein E-Rechnungs-Profil erkannt · Weder ZUGFeRD/Factur-X noch XRechnung"
Codes: keine genannt

Betrifft auch A1, also die unveränderte Konformitätsinstanz aus der offiziellen KoSIT-Testsuite. An der Datei wurde nichts geändert.

Deckungsgleich mit dem offiziellen Lauf (2)

Auf allem, was geprüft wurde, dasselbe Ergebnis wie der offizielle KoSIT-Lauf.

Datei C1
Ungültig — Profil: X-Rechnung 3.0
Codes: keine genannt
Datei B1
Gültig — Profil: X-Rechnung 3.0
Codes: keine genannt

Erkennt das XRechnung-Profil und kommt bei beiden Dateien zum selben Ergebnis wie der offizielle Lauf. Kontingent: zehn Prüfungen pro Tag.

Datei C1
Prüfung nicht bestanden — XRechnung 3.0
Codes: BR-DE-15
Datei B1
Prüfung bestanden — XRechnung 3.0
Codes: keine genannt

Liest UBL, erkennt die fehlende Leitweg-ID und nennt den Regelcode. Zu BR-TMP-6 lässt sich nichts sagen: die Oberfläche zeigt ein Bestanden/Nicht-bestanden-Urteil und keine Liste der Feststellungen, Schweigen ist hier also kein Beleg.

Prüft bewusst etwas anderes (2)

Prüft eine andere Norm oder einen anderen Katalog. Schweigen zu den deutschen Regeln ist hier richtig und kein Mangel.

Datei C1
SUCCESS — 0 Fehler
Codes: keine genannt
Datei B1
SUCCESS — 0 Fehler
Codes: keine genannt

Prüft EN 16931, nicht das deutsche CIUS. Dass BR-DE-15 hier nicht gemeldet wird, ist richtig und kein Mangel. Praktische Folge: "hat den EU-Validator bestanden" sagt für eine deutsche B2G-Rechnung nichts aus.

Der Profilkatalog enthält im getesteten Umfang kein XRechnung- und kein EN-16931-Profil; die öffentlichen Demo-Profile sind EDIFACT INVOIC, SAP XML ZORDERS05, UBL 2.0 Invoice und EDIFACT DESADV. Eine Prüfung gegen "UBL 2.0 Invoice" wäre eine Schemaprüfung und kein XRechnung-Ergebnis, deshalb wurde sie nicht durchgeführt.

Nicht getestet (1)

Ließ sich mit dieser Methode nicht prüfen. Das ist eine Grenze der Methode und keine Aussage über das Werkzeug.

Konnte nicht getestet werden: das Formular verarbeitet nur Uploads aus einer echten Nutzerinteraktion. Das ist eine Grenze unserer Testmethode und keine Aussage über das Werkzeug.

Was diese Messung nicht zeigt

Die andere Hälfte der Frage: zwei Prüfprogramme, 29 Dokumente, dasselbe Regelwerk

English version

NormAPI liefert technische Validierung, keine Steuer- oder Rechtsberatung.