E-Rechnung
XRechnung und ZUGFeRD prüfen
Laden Sie Ihre XRechnung oder Ihr ZUGFeRD-/Factur-X-PDF hoch — welches Format es ist, erkennen wir selbst. Enthält ein PDF eine eingebettete Rechnung, wird diese geprüft, gegen das offizielle Regelwerk der KoSIT.
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 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, offizieller Regeltext und Fundstelle:
Rechnung ist nicht gültig
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, die Fundstelle im Dokument und der offizielle Regeltext. Bei den häufigen Regeln führt der Code auf eine eigene Seite, die sie im Klartext erklärt: was sie bedeutet, woran es meistens liegt, wie man es behebt.
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.
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.
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.