E-Rechnung
XRechnung Validator und ZUGFeRD Validator: E-Rechnung kostenlos prüfen
Kostenlos und ohne Anmeldung: Laden Sie Ihre XRechnung oder Ihr ZUGFeRD-/Factur-X-PDF hoch und validieren Sie die E-Rechnung online — welches Format es ist, erkennen wir selbst. Geprüft wird mit dem offiziellen KoSIT-Validator und der aktuellen XRechnung-Konfiguration; aus einem PDF wird die eingebettete Rechnung herausgelöst.
Oder XML einfügen
XML oder PDF, bis 5 MB — Datei auch einfach hierher ziehen. Ohne Anmeldung, ohne Kontingent.
Ihre Datei wird nur im Arbeitsspeicher eines Servers in Deutschland geprüft und danach verworfen. Wir speichern keine Rechnungsinhalte.
Keine Rechnung zur Hand?
Ein Klick prüft die Datei hier — Download optional.
- GültigGültige Rechnung (UBL)
Besteht die Prüfung ohne Fehler. Guter Startpunkt für ein eigenes Mapping.
Datei - GültigGültige Rechnung (CII)
Dieselbe Rechnung in der zweiten zulässigen Syntax, UN/CEFACT CII.
Datei - GültigGültige Rechnung (ZUGFeRD-PDF)
Hybrid aus lesbarem PDF und eingebetteter CII-Rechnung — erzeugt von der NormAPI-Generierung, geprüft wie alle Beispiele.
Datei - BR-DE-15Käuferreferenz fehlt
Ohne BT-10 — bei Behördenrechnungen steht dort die Leitweg-ID.
Datei - BR-DE-2Ansprechpartner fehlt
Die Kontaktgruppe BG-6 fehlt vollständig — der häufigste Mapping-Fehler.
Datei - BR-CO-16Zahlbetrag geht nicht auf
Der Zahlbetrag passt nicht zur Summe — der klassische Rundungsfehler.
Datei - BR-DE-18Skonto falsch notiert
PROZENT=2 statt PROZENT=2.00 — die Notation begonnen, aber nicht eingehalten.
Datei - SchemaSchema-Fehler: Rechnungsnummer fehlt
Scheitert am XML-Schema. Die fachlichen Regeln werden gar nicht erst geprüft — eine leere Fehlerliste heißt hier nicht „alles in Ordnung“.
Datei - Nicht geprüftProfil ohne Prüf-Szenario (Factur-X MINIMUM)
Deklariert MINIMUM, das keine EN-16931-Rechnung ist. Kein Szenario passt, also läuft keine Regel — das Ergebnis ist weder gültig noch ungültig, sondern „nicht geprüft“.
Datei
So sieht ein Befund aus
Das Beispiel „Zahlbetrag geht nicht auf“ oben, geprüft. Kein Screenshot, sondern der Bericht selbst — Regelcode, Schweregrad, die Erklärung im Klartext und aufklappbar der offizielle Regeltext mit Fundstelle:
Rechnung ist nicht gültig
- Was die Regel verlangt
- Der Zahlbetrag (BT-115) muss rechnerisch aufgehen: Bruttobetrag (BT-112) minus bereits gezahlter Betrag (BT-113) plus Rundungsbetrag (BT-114).
- Wie Sie es beheben
- Rechnen Sie Beträge durchgängig mit Dezimalarithmetik, nicht mit float oder double, und runden Sie erst bei der Ausgabe auf zwei Nachkommastellen. Prüfen Sie außerdem, ob ein Anzahlungsbetrag (BT-113) gesetzt ist, den Ihre Berechnung nicht berücksichtigt.
KoSIT-Regeltext und Fundstelle
Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).
Fundstelle: /Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]/Q{urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2}LegalMonetaryTotal[1]
Regelwerk v2026-08-31Geprüft als EN16931 XRechnung (UBL Invoice)
Der Regelcode führt auf seine eigene Seite. Die Fundstelle ist der Pfad im Dokument in Clark-Notation, nicht eine Zeilennummer — dieselbe Angabe, die auch die API zurückgibt.
Was geprüft wird
Zwei Schichten, in dieser Reihenfolge. Zuerst das XML-Schema: ob die Datei strukturell überhaupt eine XRechnung ist. Erst wenn sie das besteht, laufen die fachlichen Regeln — weshalb der Bericht ein eigenes Feld dafür führt, ob sie gelaufen sind. Ohne dieses Feld wären die beiden Fälle „nichts gefunden“ und „nicht geprüft“ von außen nicht zu unterscheiden.
Danach die Geschäftsregeln: rund 300 Prüfungen der EN 16931 und ihrer deutschen Ausprägung, mit Codes wie BR-DE-15, BR-CO-16 oder BR-CL-23. Geprüft wird mit dem Validierungswerkzeug der KoSIT selbst gegen die offizielle Konfiguration — nicht mit einer Nachbildung, und gegen dieselbe Fassung, die auch die Prüfstellen der Verwaltung einsetzen.
Welche Dateien gehen
XRechnung als reines XML in beiden Syntaxen, UBL und UN/CEFACT CII, sowie ZUGFeRD- und Factur-X-PDFs — aus einem PDF wird die eingebettete Rechnung herausgelöst und diese geprüft. Welches Format vorliegt, erkennen wir am Inhalt der Datei, nicht an ihrer Endung.
Abgedeckt sind XRechnung 3.0, reines EN 16931 und die Factur-X-/ZUGFeRD-Profile BASIC, EN 16931 und EXTENDED. MINIMUM und BASIC WL sind keine EN-16931-Rechnungen: sie enthalten bewusst weniger Felder, als die Norm verlangt, und lassen sich deshalb nicht dagegen prüfen. Für eine deutsche B2B-Rechnung genügen sie ohnehin nicht.
Was im Bericht steht
Je Fund der Regelcode, der Schweregrad und im Klartext, was die Regel verlangt und wie Sie den Fehler beheben; aufgeklappt der offizielle Regeltext und die Fundstelle im Dokument. Der Code führt auf die Erklärung der Regel, bei den häufigen Regeln mit der typischen Ursache und einem XML-Beispiel. Scheitert die Datei schon am XML-Schema, steht dort dessen Meldung.
Eine Warnung macht eine Rechnung nicht ungültig, und das Regelwerk gibt auch auf einwandfreien Rechnungen Hinweise aus. Das Urteil steht deshalb getrennt von der Fundliste: eine Rechnung mit drei Hinweisen und ohne Fehler ist annehmbar.
Unter den Funden steht die Rechnung selbst, lesbar aufbereitet: Verkäufer, Käufer, Positionen, Umsatzsteuer, Summen und Zahlungsdaten, jedes Feld mit seiner BT-Nummer, auf die sich die Regeltexte beziehen. Bei einem ZUGFeRD-PDF ist das die eingebettete XML. Den ganzen Bericht können Sie drucken oder als PDF speichern; er nennt Zeitpunkt, Regelwerk und die SHA-256-Prüfsumme der geprüften Datei.
Was mit Ihrer Datei passiert
Der Hinweis über dem Formular ist wörtlich gemeint: geprüft wird im Arbeitsspeicher, danach ist die Datei fort. Wichtiger ist, was daraus für den Rechnungseingang folgt — der Prüfbericht entsteht bei Ihnen und bleibt bei Ihnen. Wer ihn als Nachweis aufbewahren muss, kann das tun, ohne dass eine zweite Kopie irgendwo anders liegt.
Was diese Prüfung nicht sehen kann
Ob der Steuersatz der richtige ist, ob die Leistungsbeschreibung zutrifft, ob überhaupt der richtige Empfänger adressiert wurde. Das BMF-Schreiben vom 15. Oktober 2025 führt das als eigene Fehlerklasse, und keine technische Prüfung erkennt sie. Eine Rechnung kann jede der 300 Regeln bestehen und inhaltlich falsch sein.
Häufige Fragen
Ist der Validator kostenlos?
Ja, ohne Anmeldung und ohne Kontingent. Auch dieselbe Prüfung per API bleibt kostenlos; bezahlt wird bei NormAPI nur das Erzeugen von Rechnungen.
Müssen E-Rechnungen validiert werden?
Eine ausdrückliche Pflicht zur technischen Prüfung gibt es nicht. Aber eine Datei, die nicht dem Format entspricht, gilt nach dem BMF-Schreiben vom 15. Oktober 2025 nicht als E-Rechnung — und sobald die E-Rechnung Pflicht ist, steht damit der Vorsteuerabzug des Empfängers in Frage. Deshalb prüfen viele Empfänger eingehende Rechnungen automatisch und weisen fehlerhafte zurück. Wer Rechnungen erzeugt, prüft sie am besten vor dem Versand.
Was bedeutet „E-Rechnung nicht valide“?
Die Datei verletzt mindestens eine Regel: entweder das XML-Schema, also die Struktur, oder eine Geschäftsregel der EN 16931 bzw. der XRechnung, etwa BR-DE-15 „Käuferreferenz fehlt“. Der Bericht nennt jeden Fehler mit Regelcode, Fundstelle und Behebung. Warnungen allein machen eine Rechnung nicht ungültig.
Kann man eine Rechnung prüfen lassen?
Technisch ja, hier kostenlos: Datei hochladen, das Ergebnis kommt in Sekunden. Ob Steuersatz, Leistung und Empfänger stimmen, prüft dagegen keine Software; das bleibt Aufgabe der Buchhaltung oder der Steuerberatung.
Wie kann ich eine ZUGFeRD-Datei validieren?
Das PDF oben hochladen. Der Validator holt die eingebettete XML heraus (factur-x.xml, zugferd-invoice.xml oder xrechnung.xml), erkennt das Profil und prüft sie gegen Schema und Geschäftsregeln. Die PDF/A-3-Konformität der Datei selbst wird dabei nicht geprüft.
Welches ZUGFeRD-Format ist gültig?
Als E-Rechnung gilt ZUGFeRD ab Version 2.0.1 in den Profilen BASIC, EN 16931, EXTENDED und XRECHNUNG. MINIMUM und BASIC WL nicht: Sie enthalten weniger Angaben, als die EN 16931 verlangt (BMF-Schreiben vom 15. Oktober 2024). Ältere Fassungen wie ZUGFeRD 1.0 kennt das aktuelle Regelwerk nicht mehr.
Wie erkenne ich, ob eine PDF eine ZUGFeRD ist?
Am Anhang: Ein ZUGFeRD-PDF trägt eine XML-Datei namens factur-x.xml, zugferd-invoice.xml oder xrechnung.xml, sichtbar in der Anhang-Leiste vieler PDF-Programme. Ohne diesen Anhang ist das PDF keine E-Rechnung. Einfacher: hier hochladen — der Validator sagt, ob und welche Rechnung darin steckt.
Ist das der offizielle KoSIT-Validator?
Ja. Geprüft wird mit dem Validierungswerkzeug der KoSIT gegen die offizielle XRechnung-Konfiguration; welche Fassung, steht unter jedem Ergebnis. Ergänzt haben wir nur Szenarien für Factur-X BASIC und EXTENDED, für die die offizielle Konfiguration keines mitbringt.
Welche Dateien kann ich prüfen?
XRechnung als XML in beiden Syntaxen, UBL und CII, sowie ZUGFeRD- und Factur-X-PDFs in den Profilen BASIC, EN 16931 und EXTENDED, bis 5 MB. MINIMUM und BASIC WL enthalten weniger Angaben, als die EN 16931 verlangt, und sind deshalb keine E-Rechnung im Sinne der Norm.
UBL oder CII — was ist der Unterschied?
Zwei XML-Syntaxen für denselben Inhalt nach EN 16931. Die XRechnung gibt es in beiden, ZUGFeRD und Factur-X verwenden CII. Für die Prüfung macht es keinen Unterschied: Der Validator erkennt die Syntax am Inhalt.
Kann ich eine XRechnung lesbar anzeigen?
Ja. Unter dem Ergebnis steht der Inhalt der Rechnung: Verkäufer, Käufer, Positionen, Umsatzsteuer, Summen und Zahlungsdaten, auch aus der XML in einem ZUGFeRD-PDF. Den Prüfbericht samt Rechnungsinhalt können Sie drucken oder als PDF speichern.
Wird meine Rechnung gespeichert?
Nein. Die Datei wird im Arbeitsspeicher geprüft und danach verworfen; wir speichern keine Rechnungsinhalte.
Prüft der Validator auch PDF/A-3?
Ja. Bei einem ZUGFeRD- oder Factur-X-PDF prüft der Validator die eingebettete Rechnung gegen das KoSIT-Regelwerk und die Datei selbst mit veraPDF auf PDF/A-3, dazu ob das Profil in den XMP-Metadaten zum XML passt. Verstöße beim PDF erscheinen als Warnung: Steuerlich ist das XML die Rechnung, aber der ZUGFeRD-Standard verlangt PDF/A-3, und manche Empfänger weisen Dateien ohne ab.
Ist eine gültige E-Rechnung auch steuerlich richtig?
Nicht unbedingt. Der Validator prüft Format und Geschäftsregeln. Ob Steuersatz, Leistungsbeschreibung und Empfänger stimmen, kann keine technische Prüfung erkennen.
Kann ich die Prüfung automatisieren?
Ja. Dieselbe Prüfung läuft als API: ein HTTP-Request mit der Datei, die Antwort als JSON mit Urteil und Fundliste. Für Software, die mit horstoeko, Mustang oder einer anderen Bibliothek erzeugt, gibt es eine Anleitung mit Beispielen.
Warum nicht irgendein kostenloser Prüfer?
Weil sie sich uneinig sind, und das haben wir gemessen statt behauptet: dieselben drei Dateien aus der offiziellen KoSIT-Testsuite, an einem Tag durch elf frei zugängliche Prüfseiten. Drei verarbeiteten eine XRechnung in UBL überhaupt nicht, drei weitere prüften gegen ein Regelwerk von vor dem 2. September 2026. Ein „gültig“ heißt dort nicht, dass die Rechnung in Ordnung ist, sondern dass diese Seite nichts gefunden hat.
Elf Online-Validatoren, dieselbe Rechnung, ein Tag
Auch zwei ernstzunehmende Implementierungen desselben Regelwerks kommen nicht überall zum selben Ergebnis: bei 29 Dokumenten waren sie sich bei 22 einig und bei 7 nicht. Deshalb läuft hier das Validierungswerkzeug der KoSIT selbst gegen die offizielle Konfiguration — dieselbe Fassung, die auch die Prüfstellen der Verwaltung einsetzen.