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

Gemessen und gegen den offiziellen KoSIT-Validator geprüft von Dmytro Yalanskyi, NormAPI.

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. Am Tag der Messung verarbeiteten drei der elf geprüften Seiten eine XRechnung in UBL überhaupt nicht — eine davon hat es am Tag darauf behoben, weshalb die Tabelle unten zwei zeigt —, drei weitere arbeiteten 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.

„Derzeit sehen sich Unternehmen sowohl auf der Ausgangsseite als auch auf der Eingangsseite mit unterschiedlichen Validierungslösungen und -ergebnissen konfrontiert […]. Es ist unklar, wessen Validierungsergebnis das maßgebliche ist.“
Der Satz, auf den sich das bezieht: BDI, „Probleme mit der E-Rechnung“, 6. Juli 2026

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 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 (2)

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

erechnungs-validator.de (winball)

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.

easyfirma.net

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 (3)

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

inoxision (belegpostfach)

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.

kostenlose-erechnung.de

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.

e-rechnung.tools

Datei C1
Nicht konform, 1 Fehler — "Käuferreferenz (Leitweg-ID, BT-10) ist erforderlich."
Codes: BR-DE-15
Datei B1
Mit Warnungen, keine Fehler — "[BR-TMP-6] Datumsangaben in UBL müssen im Format JJJJ-MM-TT (YYYY-MM-DD) übermittelt werden."
Codes: BR-TMP-6

Liest UBL, erkennt die fehlende Leitweg-ID und meldet BR-TMP-6 namentlich — eine Regel, die drei andere geprüfte Werkzeuge nicht melden. Kleinigkeit am Rande: In der Feldübersicht erscheint das Rechnungsdatum mit Zeitzonen-Offset als "Invalid Date"; geprüft wird es korrekt.

Korrigiert

Am 15. September: Am 15. September verarbeitete die Seite eine XRechnung in UBL nicht und antwortete mit "Kein CrossIndustryInvoice-Element gefunden."

Nachgeprüft: Der Betreiber hat am 16. September geschrieben, die Vorerkennung habe UBL nur an einem Wurzelelement ohne Namespace-Präfix erkannt, und das sei behoben. Nachgeprüft mit denselben beiden Dateien: stimmt. Die Seite liest UBL jetzt und meldet BR-DE-15 und BR-TMP-6.

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.

ITB (Europäische Kommission)

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.

Truugo

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.

e-rechnungs-checker.de

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.

Die Daten

Der vollständige Korpus — neun Dateien, von denen die drei oben durch alle elf Seiten geschickt wurden —, der offizielle KoSIT-Lauf als Kontrolle, der ITB-Lauf der Europäischen Kommission und jede einzelne Beobachtung als JSON. Dazu die Skripte, die den Korpus bauen und prüfen, dass jede Datei genau die vorgesehene Regel auslöst. Ergebnisse und Skripte unter CC BY 4.0, der Korpus bleibt bei Apache-2.0.

Rohdaten auf GitHub

So zitieren Sie diese Messung

NormAPI (2026). Elf Online-Validatoren, dieselbe Rechnung, ein Tag. https://normapi.de/studie/online-validatoren

Eine Momentaufnahme eines Tages. Werkzeuge ändern sich; eine Korrektur wird als solche vermerkt und nie stillschweigend eingearbeitet. Gegenprobe ist die Fassung v2026-08-31 — erscheint eine neue, wiederholen wir den Lauf und schreiben das Datum hier fort.

Was diese Messung nicht zeigt

  • Eine Momentaufnahme eines Tages. Werkzeuge werden aktualisiert; ein Befund von heute kann morgen überholt sein.
  • Geprüft wurden drei Dateien, nicht der Funktionsumfang. Wer BR-TMP-6 nicht meldet, kann in allem anderen tadellos sein.
  • Wo ein Werkzeug nur ein Bestanden/Nicht-bestanden-Urteil anzeigt, lässt sich aus dem Fehlen einer Warnung nichts schließen. Das ist oben jeweils vermerkt.
  • Der Validator des Serviceportals Baden-Württemberg ist von außerhalb Deutschlands nicht erreichbar; gemessen wurde über eine deutsche Verbindung.
  • Korrekturen sind willkommen. Ist eine Angabe falsch, schreiben Sie uns — sie wird mit Datum korrigiert.

Die andere Hälfte der Frage: zwei Prüfprogramme, 29 Dokumente, dasselbe Regelwerk · 810 Beispielrechnungen aus dem Netz im Test

English version

NormAPI liefert technische Validierung, keine Steuer- oder Rechtsberatung.