XRechnung-Validator: E-Rechnung prüfen

Was der Validator prüft

Die KoSIT, die Koordinierungsstelle für IT-Standards, beschreibt die Prüfung einer XRechnung in der Spezifikation 3.0.2 in drei Schritten: „Prüfung der Verwendung eines korrekten Syntaxschemas“, „Prüfung der EN 16931-Regeln“ und „Prüfung der XRechnungs-Regeln“. Der Validator führt diese Prüfschritte mit den Dateien der Validatorkonfiguration XRechnung vom 31.08.2026 aus. Bei Rechnungen nach EN 16931 ohne XRechnung-Kennung, etwa ZUGFeRD COMFORT, entfällt Schritt 3.

Welche Prüfregeln gelten, erkennt der Validator an der Spezifikationskennung (BT-24) in der Datei, so wie der KoSIT-Validator. Geprüft werden XRechnung 3.0 in UBL und CII, auch in den Varianten Extension und CVD, sowie Rechnungen nach EN 16931 ohne nationale Erweiterung. Entspricht eine Datei schon nicht dem XML-Schema, bricht die Prüfung wie beim KoSIT-Validator nach Prüfschritt 1 ab.

Vergleich mit dem KoSIT-Validator: 1.695 Dateien

Ein Validator ist nur so viel wert wie seine Übereinstimmung mit der Referenz. Die Referenz ist der KoSIT-Validator, ein Java-Programm ohne eigene Regeln, das die KoSIT zusammen mit der Prüfkonfiguration herausgibt. Am 4. November 2026 haben wir per Skript 1.695 Dateien mit diesem Validator (in Node und in Chrome) und mit dem KoSIT-Validator 1.6.3 geprüft, beide mit der Prüfkonfiguration vom 31.08.2026, und die Berichte verglichen. Die beschädigten Dateien haben wir aus den gültigen erzeugt, je Datei ein Fehler: ein gelöschtes Element, ein geänderter Betrag, ein falscher Code, ein ungültiges Datum oder eine falsche IBAN.

Aus dem ZUGFeRD-Korpus haben wir alle 126 PDFs genommen; aus 125 ließ sich die Rechnungs-XML lesen. „Gleiche Entscheidung“ heißt: Beide Programme haben die Datei angenommen, abgelehnt oder als nicht prüfbar erkannt. „Gleiche Meldungen“ heißt: dieselben Regelcodes mit derselben Einstufung. Bei Schemafehlern formulieren und zählen die beiden Programme ihre Meldungen unterschiedlich; dort haben wir verglichen, ob das Schema erfüllt ist. Die eine Abweichung betrifft BR-S-08 bei einer Differenz von genau 1,00 Euro, also an der Toleranzgrenze der Regel. Hier meldet dieser Validator einen Fehler, der KoSIT-Validator nicht; Ursache ist die unterschiedliche Umwandlung von Gleitkommazahlen in Java und im Browser.

Eine Stelle der Prüfregeln haben wir angepasst. Die IBAN-Prüfung der XRechnung (BR-DE-19) rechnet mit Zahlen von mehr als 16 Stellen, die der XSLT-Prozessor SaxonJS 2.7 nicht genau genug verarbeitet. Wir haben die Funktion durch eine schrittweise Modulo-97-Rechnung ersetzt, sie mit 5.000 IBANs gegen eine exakte Rechnung getestet und mit dem KoSIT-Validator an 225 Dateien bestätigt, dass die geänderten Prüfregeln dieselben Berichte liefern wie die originalen.

Fehler, Warnung, Hinweis: was die Meldungen bedeuten

Jede Regel hat eine Einstufung. Fehler führen zur Empfehlung, die Rechnung abzulehnen; Warnungen und Hinweise nicht. Die Entscheidung über die Annahme liegt laut KoSIT-Spezifikation bei der empfangenden Stelle. Die Prüfkonfiguration stuft einzelne Regeln anders ein als die CEN-Regeln; so ist eine unbekannte Mengeneinheit (BR-CL-23) in XRechnung nur eine Warnung. Diese Einstufungen übernimmt der Validator. Zu jeder Meldung zeigt er den Regelcode, den Regeltext auf Deutsch, den Originaltext der Regel und die Stelle in der Datei.

pdfvera.com/de/xrechnung-validator

Fehlt BT-10 in einer Rechnung zwischen Unternehmen, genügt laut BMF umsatzsteuerlich ein Platzhalter wie „-“, weil im B2B-Bereich keine Leitweg-ID nötig ist (Fragen und Antworten, Frage 6). Die Regel BR-DE-15 ist mit einem Platzhalter erfüllt. Ob eine Leitweg-ID richtig aufgebaut ist, prüft BR-DE-15 nicht; dafür gibt es die Leitweg-ID-Prüfung.

Ist eine E-Rechnung mit Fehlern noch eine E-Rechnung?

Bei einem Formatfehler nein, bei einem Geschäftsregelfehler umsatzsteuerlich grundsätzlich ja. Das BMF unterscheidet im BMF-Schreiben vom 15. Oktober 2025 beide Arten. Ein Formatfehler liegt vor, wenn die Datei „nicht den zulässigen Syntaxen bzw. deren technischen Vorgaben entspricht“ oder sich bei ZUGFeRD die XML nicht richtig und vollständig auslesen lässt; die Datei ist dann eine „sonstige Rechnung“ (Rn. 6a). Am nächsten kommen dem im Prüfbericht die Meldungen zum XML-Schema und ein PDF ohne lesbare Rechnungs-XML. Einzelnen Regelcodes ordnet das BMF Formatfehler nicht zu.

Geschäftsregelfehler behandelt das BMF getrennt (Rn. 6b). Als Beispiele nennt es eine fehlende Käuferreferenz BT-10 und einen Steuerbetrag, der nicht zum Steuersatz passt. Laut dem ergänzenden BMF-Schreiben vom 15. Oktober 2026 ist eine Datei mit Geschäftsregelfehler, aber ohne Formatfehler, umsatzsteuerlich „dennoch prinzipiell eine E-Rechnung im Sinne von § 14 UStG“ (Rn. 23). Ein Geschäftsregelfehler hat nur dann einen Inhaltsfehler zur Folge, wenn er eine umsatzsteuerliche Pflichtangabe betrifft (Rn. 22). Ordnungsmäßig ist die Rechnung, wenn die Pflichtangaben nach §§ 14 und 14a UStG richtig und vollständig sind. Ob ein Fehler Ihren Vorsteuerabzug berührt, klärt im Einzelfall Ihr Steuerberater.

Muss man E-Rechnungen validieren?

Vorgeschrieben ist es nicht. Das BMF schreibt in seinen Fragen und Antworten (Frage 7, Stand Oktober 2026): „Eine Validierung ist zwar keine unmittelbare Voraussetzung für die steuerliche Anerkennung der Rechnung“. Es nennt sie aber „sinnvoll“ und empfiehlt, sie schon bei Erstellung und Versand durchzuführen. Eine bestimmte Validierungsanwendung empfiehlt das BMF nicht.

Als Empfänger bleiben Sie selbst zuständig. Laut BMF-Schreiben vom 15. Oktober 2025 „ersetzt“ eine Validierung „nicht die dem Empfänger obliegende Pflicht zur Überprüfung der Rechnung auf Vollständigkeit und Richtigkeit“; zum Nachweis biete es sich an, den Validierungsbericht aufzubewahren (Rn. 35a). Den Prüfbericht dieses Validators können Sie mit Dateiname, Datum und allen Meldungen als PDF speichern. Fachliche Fehler findet ein Validator nicht: Ein falscher, aber formal gültiger Steuersatz kann alle Regeln bestehen (Rn. 35a). Wann welche Unternehmen E-Rechnungen ausstellen und empfangen müssen, steht im Ratgeber zur E-Rechnungspflicht.

ZUGFeRD-Validator: welche Profile geprüft werden

Eine ZUGFeRD-Rechnung ist ein PDF mit eingebetteter XML-Datei. Der Validator liest die XML aus dem PDF und prüft sie mit dem XML-Schema CII D16B und den Regeln der EN 16931. Die deutschen XRechnung-Regeln (BR-DE) gelten nur für Dateien mit XRechnung-Kennung, also für das Profil XRECHNUNG. Für die übrigen Profile enthält die KoSIT-Prüfkonfiguration keine Regeln; das Forum elektronische Rechnung Deutschland (FeRD) liefert eigene Schematron-Dateien je Profil, die dieser Validator nicht ausführt.

Im ZUGFeRD-Korpus lagen 56 der 125 lesbaren Dateien außerhalb dieser Prüfkonfiguration. Solche Rechnungen erkennt der Validator und nennt das Profil; lesbar anzeigen können Sie sie im XRechnung-Viewer. Das PDF selbst prüft der Validator nicht, also auch nicht, ob es dem Standard PDF/A-3 entspricht. Laut FeRD sind solche PDF/A-Fehler „lediglich als Warnung zu beachten und sind keine schwerwiegenden Fehler“.

Andere Validatoren: KoSIT und service-bw

Den KoSIT-Validator gibt es kostenlos und quelloffen auf GitHub (Apache-Lizenz 2.0); er läuft als Kommandozeilenprogramm mit Java. Ohne Installation prüft der E-Rechnungs-Validator des Landes Baden-Württemberg, betrieben von IT Baden-Württemberg (BITBW). Er nimmt XML-Dateien bis 15 MB an, keine PDFs, braucht keine Anmeldung und schickt die Datei zur Prüfung an seinen Server (laut Programmcode der Seite, abgerufen am 04.11.2026). Die Rechnungseingangsplattform des Bundes prüft Rechnungen beim Einreichen; dafür ist eine Registrierung nötig.

Dieser Validator lädt die Prüfregeln von pdfvera.com und prüft die Datei auf Ihrem Rechner. Im Netzwerk-Reiter der Entwicklerwerkzeuge sehen Sie, welche Dateien die Seite lädt, und die eine Nutzungsmeldung, die sie sendet. Herkunft und Lizenzen der Prüfregeln und Programmdateien stehen in den Lizenzhinweisen.