Ratgeber

XRechnung Validator: XRechnung und ZUGFeRD prüfen

Aktualisiert 2026-06-13

Eine E-Rechnung sieht im PDF-Viewer oft tadellos aus und scheitert trotzdem an der Validierung. Der Grund liegt darin, dass bei XRechnung und ZUGFeRD nicht das Layout zählt, sondern die eingebettete XML-Datei und ob sie hunderte formaler Geschäftsregeln einhält. Ein XRechnung Validator prüft genau das. Dieser Artikel erklärt, was bei der Validierung passiert, welche Fehler am häufigsten auftauchen und wie Sie eine Datei in wenigen Sekunden selbst prüfen, bevor sie beim Empfänger landet.

Warum eine E-Rechnung überhaupt validiert werden muss

Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen empfangen können. Ab dem 1. Januar 2027 wird das Ausstellen für Betriebe über 800.000 € Vorjahresumsatz Pflicht, ab dem 1. Januar 2028 für alle übrigen. Eine E-Rechnung im Sinne dieser Vorschrift ist ein strukturierter Datensatz nach der europäischen Norm EN 16931, in Deutschland praktisch umgesetzt als XRechnung (reine XML) oder ZUGFeRD (PDF mit eingebetteter XML). Ein einfaches PDF zählt an diesen Stichtagen im B2B-Bereich nicht mehr als E-Rechnung. Während der Übergangszeit ist ein reines PDF nur noch mit Zustimmung des Empfängers zulässig.

Strukturiert bedeutet, dass Beträge, Steuersätze, Adressen und Identifikatoren an genau definierten Stellen stehen und rechnerisch wie logisch zueinander passen müssen. Stimmt eine dieser Beziehungen nicht, kann das Buchhaltungssystem des Empfängers die Rechnung ablehnen. Dann hilft kein schönes Layout. Deshalb gilt: prüfen, bevor versendet wird, nicht erst, wenn der Kunde reklamiert.

Was der KoSIT-Validator prüft

Der offizielle Maßstab in Deutschland ist der KoSIT-Validator (Koordinierungsstelle für IT-Standards), zusammen mit der jeweils aktuellen XRechnung-Konfiguration. Faktwise prüft seine Ausgabe gegen genau dieses Werkzeug (aktuell Validator 1.6.0 mit der Konfiguration vom 31. Januar 2026). Die Prüfung läuft in mehreren Stufen ab:

XML-Wohlgeformtheit: Ist die Datei überhaupt gültiges XML, ohne abgeschnittene Tags oder kaputte Zeichen?
Schema-Prüfung: Entspricht der Aufbau der zugrunde liegenden Syntax (UBL 2.1 oder CII)? Stehen Pflichtelemente an der vorgesehenen Stelle?
Schematron-Geschäftsregeln: Das ist der eigentliche Kern. Hunderte Regeln aus EN 16931 (Codes mit dem Präfix BR-) und die deutschen Zusatzregeln der XRechnung-CIUS (BR-DE-) werden geprüft. Hier entscheidet sich, ob Beträge zusammenpassen, ob Pflichtangaben vorhanden sind und ob Codes erlaubt sind.

Das Ergebnis ist ein Report mit Meldungen in drei Schweregraden. Fatal und error verhindern eine konforme Rechnung, warning weist auf Auffälligkeiten hin, die der Empfänger meist toleriert, die Sie aber kennen sollten. Wer eine E-Rechnung wirklich versenden will, sollte error-frei durch den Validator kommen.

Wichtig zur Einordnung: Eine solche Prüfung sagt etwas über die formale und rechnerische Konformität der Datei zur Norm aus, nicht über Ihre steuerliche Beurteilung. Ein Validator ist Software, keine Steuerberatung. Ob ein Sachverhalt steuerlich richtig erfasst ist, klären Sie mit Ihrem Steuerberater.

ZUGFeRD bringt zwei zusätzliche Prüfebenen mit. Die Datei muss ein gültiges PDF/A-3 sein (das archivierbare PDF-Format), und die XML muss korrekt eingebettet sein (als factur-x.xml mit den passenden Metadaten). Eine ZUGFeRD-Prüfung schaut also auf den PDF-Container und auf die XML darin.

Die häufigsten Validierungsfehler und was dahintersteckt

BR-CO-17: Rundungsdifferenz bei der Umsatzsteuer

Der mit Abstand häufigste harte Fehler. EN 16931 verlangt, dass die Umsatzsteuer je Steuersatz-Gruppe berechnet wird, nicht pro Zeile aufsummiert. Konkret werden für jede Steuerkategorie die Netto-Zeilenbeträge zusammengezählt und erst auf diese Summe der Steuersatz angewendet, kaufmännisch auf zwei Stellen gerundet. Die Gesamtsteuer ist dann die Summe dieser bereits gerundeten Gruppenbeträge.

Viele Systeme machen es falsch herum: Sie runden die Steuer pro Rechnungszeile und addieren danach. Bei mehreren Positionen entstehen so Centdifferenzen, und der Validator meldet BR-CO-17 (oder die verwandte Regel BR-CO-14 auf Dokumentebene). Die Toleranz liegt bei null. Schon ein Cent Abweichung zwischen ausgewiesener und nachgerechneter Steuer lässt die Prüfung scheitern. Die einzige saubere Lösung ist, die Steuer von vornherein gruppenweise zu rechnen und die Pro-Zeilen-Steuer höchstens als unverbindliche Anzeige zu behandeln.

Fehlende oder falsch platzierte Leitweg-ID

Die Leitweg-ID ist die Adressierung für Rechnungen an öffentliche Auftraggeber. Sie gehört technisch in das Feld Buyer reference (BT-10) und ist bei deutschen Rechnungen an die öffentliche Hand (B2G) Pflicht, geprüft über die Regel BR-DE-15. Fehlt sie bei einer B2G-Rechnung, scheitert die Validierung.

Zur Einordnung: Im klassischen Onlinehandel an Geschäfts- und Privatkunden (B2B und B2C) brauchen Sie in der Regel keine Leitweg-ID. Der Fehler tritt vor allem auf, wenn Behörden zu Ihren Kunden gehören und die ID nicht erfasst wurde. Umgekehrt sollten Sie auch keine erfundene Leitweg-ID eintragen, nur weil ein Feld danach fragt.

Falsche CustomizationID

Die CustomizationID ist der Ausweis der Rechnung. Sie sagt dem Empfänger, nach welcher Spezifikation die Datei gebaut wurde. Für eine XRechnung muss hier exakt der erwartete Wert stehen, derzeit urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Steht dort ein abweichender, veralteter oder selbst zusammengesetzter String, ordnet der Validator die Datei dem falschen Regelwerk zu oder weist sie ab. Dieser Fehler entsteht oft beim manuellen Basteln von XML oder bei veralteten Exportvorlagen.

Falsches ZUGFeRD-Profil

ZUGFeRD gibt es in mehreren Profilen. Die deutsche Mandatspflicht erfüllen nur die Profile BASIC, EN 16931 und EXTENDED. Die schlanken Profile MINIMUM und BASIC WL reichen nicht aus, weil ihnen Pflichtangaben fehlen. Eine Datei kann technisch ein gültiges ZUGFeRD sein und trotzdem im falschen Profil stecken. Achten Sie beim Erzeugen auf das Profil EN 16931, das die Vorgaben sauber abdeckt.

Fehlende deutsche Pflichtangaben (BR-DE-Regeln)

Die deutsche XRechnung-CIUS verlangt mehr als die europäische Basis. Häufige Stolperstellen sind die fehlende Kontaktangabe des Verkäufers (Name, Telefon, E-Mail, geprüft über BR-DE-2 und verwandte Regeln) und fehlende Zahlungsangaben. Diese Felder wirken nebensächlich, sind aber Pflicht, und ihr Fehlen erzeugt klare error-Meldungen.

So prüfen Sie eine Datei selbst

Sie müssen für eine schnelle Kontrolle weder Java installieren noch den KoSIT-Validator von der Kommandozeile starten. Mit unserem kostenlosen Rechnungs-Validator prüfen Sie eine Datei direkt im Browser:

Datei auswählen: Laden Sie Ihre XML (XRechnung) oder Ihr PDF (ZUGFeRD) hoch. Bei ZUGFeRD wird die eingebettete XML automatisch herausgelesen.
Prüfung starten: Die Datei wird gegen die EN-16931- und die deutschen XRechnung-Regeln geprüft.
Report lesen: Sie sehen die Meldungen mit Regel-Code (zum Beispiel BR-CO-17) und Schweregrad. So erkennen Sie sofort, ob es ein harter Fehler ist oder nur ein Hinweis, und welche Stelle der Rechnung betroffen ist.

So fangen Sie Fehler ab, bevor eine Rechnung beim Geschäftskunden im Buchhaltungssystem auf Ablehnung läuft. Den technischen Hintergrund zu beiden Formaten finden Sie im XRechnung-Guide für Shopify und im ZUGFeRD-Guide.

FAQ

Was ist der Unterschied zwischen einem XRechnung Validator und einem ZUGFeRD Validator?

Im Kern prüfen beide dieselbe XML gegen dieselben EN-16931- und XRechnung-Regeln. Ein ZUGFeRD Validator prüft zusätzlich den PDF/A-3-Container und ob die XML korrekt im PDF eingebettet ist. Bei reiner XRechnung gibt es keinen PDF-Teil.

Reicht es, wenn das PDF korrekt aussieht?

Nein. Bei E-Rechnungen ist die strukturierte XML maßgeblich, nicht die sichtbare Darstellung. Ein optisch perfektes PDF kann an einer Rundungsregel oder einer fehlenden Pflichtangabe scheitern. Genau deshalb gibt es die Validierung.

Mein Validator meldet BR-CO-17. Was tun?

Das ist fast immer eine Rundungsdifferenz bei der Umsatzsteuer. Prüfen Sie, ob die Steuer pro Steuersatz-Gruppe (Summe der Nettobeträge mal Satz) gerechnet wird und nicht pro Zeile aufaddiert. Korrigieren Sie die Berechnungslogik, nicht den ausgewiesenen Betrag von Hand.

Brauche ich immer eine Leitweg-ID?

Nein. Die Leitweg-ID ist nur für Rechnungen an deutsche öffentliche Auftraggeber (B2G) Pflicht. Im üblichen Handel an Geschäfts- und Privatkunden brauchen Sie sie nicht und sollten kein Pseudo-Feld erfinden.

Ersetzt der Validator eine Steuerberatung?

Nein. Ein Validator und auch Faktwise sind Software, keine Steuerberatung. Geprüft wird die formale und rechnerische Konformität der Datei zur Norm, nicht ob Ihr Sachverhalt steuerlich richtig erfasst ist. Bei inhaltlichen Steuerfragen sprechen Sie mit Ihrem Steuerberater.

Wenn Sie Validierungsfehler gar nicht erst sehen wollen, lohnt sich der Blick auf die Quelle. Faktwise erzeugt aus jeder Shopify-Bestellung automatisch eine ZUGFeRD- oder XRechnung-Datei und prüft die Ausgabe gegen den offiziellen KoSIT-Validator, bevor sie ankommt. Die Umsatzsteuer wird gruppenweise gerundet (kein BR-CO-17), Pflichtangaben und CustomizationID sitzen korrekt, und alle Belege landen in einem GoBD-konformen Archiv. Was auf Sie ab 2027 und 2028 zukommt, erklärt der Guide zur E-Rechnungspflicht 2027/2028. Kostenlos bis 5 Rechnungen pro Monat.