Warum eine gültige XML-Datei trotzdem fehlschlagen kann

„Gültige XML“ bedeutet zunächst nur: Die Datei ist technisch lesbar und folgt den Grundregeln von XML. Für eine E-Rechnung reicht das nicht. Eine Rechnung muss zusätzlich zur richtigen Syntax, zum richtigen Schema, zu EN-16931-Geschäftsregeln und zum erwarteten Profil passen.

Darum kann eine Datei in einem XML-Editor ohne Fehler geöffnet werden, aber in einem E-Rechnungs-Validator scheitern. Der Validator prüft nicht nur, ob die Datei Text enthält, sondern ob die strukturierten Rechnungsdaten fachlich und technisch verarbeitbar sind.

Der häufigste Denkfehler ist, alle Arten von „gültig“ gleichzusetzen. Bei E-Rechnungen meint gültig je nach Ebene etwas anderes. Eine Datei kann eine Ebene bestehen und an der nächsten scheitern.

Die erste Ebene ist die technische XML-Syntax. Sie beantwortet nur die Frage, ob die Datei als XML gelesen werden kann. Sind Tags korrekt geschlossen? Ist die Zeichenkodierung lesbar? Gibt es unsichere oder verbotene XML-Konstrukte?

Wenn diese Ebene fehlschlägt, ist die Datei meist grundsätzlich kaputt oder unsicher. Wenn sie besteht, heißt das aber noch nicht, dass es eine brauchbare Rechnung ist. Es heißt nur, dass der Validator die Datei weiter untersuchen kann.

XSD-Schema-Validierung prüft, ob die XML-Struktur zur verwendeten Syntax passt, zum Beispiel UBL oder CII. Diese Ebene kontrolliert, welche Elemente wo stehen dürfen und welche Datentypen erwartet werden.

Ein Schema kann aber nicht jede fachliche Rechnungslogik prüfen. Es kann erkennen, dass ein Betragsfeld eine Zahl enthält. Es kann nicht allein sicherstellen, dass alle Summen nach den EN-16931-Regeln zusammenpassen oder dass der verwendete Steuergrund zur Steuerkategorie passt.

Viele wichtige E-Rechnungsregeln werden als Schematron- oder Business-Rule-Prüfung umgesetzt. Hier geht es um fachliche Zusammenhänge: Pflichtfelder, Codelisten, Steuerkategorien, Rundungsregeln, Summenlogik und Profilregeln.

Ein typisches Beispiel ist eine Rechnung, deren einzelne Positionen rechnerisch nicht zur Gesamtsumme passen. Die XML-Datei kann wohlgeformt sein, das Schema kann bestehen, und trotzdem scheitert die Rechnung an einer Business Rule wie BR-CO-10.

EN 16931 beschreibt das europäische Kernmodell. In der Praxis verwenden Länder oder Netzwerke zusätzliche Spezifikationen. XRechnung ist die deutsche CIUS. Sie konkretisiert und beschränkt die Nutzung des Kernmodells für bestimmte deutsche Prozesse.

Deshalb kann eine Rechnung formal EN-16931-nah sein, aber beim Empfänger trotzdem scheitern, wenn sie nicht dem erwarteten XRechnung-Profil, der geforderten Syntax oder den geforderten Zusatzregeln entspricht.

Bei ZUGFeRD und Factur-X gibt es zwei Ebenen in einer Datei: die sichtbare PDF-Ansicht und die eingebettete XML-Rechnung. Das PDF kann korrekt aussehen, während die XML-Schicht fehlerhaft, unvollständig oder im falschen Profil eingebettet ist.

Für die automatische Verarbeitung zählt die strukturierte XML-Schicht. Eine visuell plausible Rechnung ist deshalb kein Beweis dafür, dass die Datei als E-Rechnung angenommen werden kann.

Eine gute Fehlermeldung sollte nicht nur „invalid“ sagen. Sie sollte zeigen, welche Ebene betroffen ist, welche Regel ausgelöst wurde und welche Daten wahrscheinlich korrigiert werden müssen.

Praktisch hilft diese Reihenfolge: zuerst Format und Profil prüfen, dann Syntax, dann Schema, dann Business Rules. So lässt sich schneller erkennen, ob der Fehler aus einem kaputten XML, einem falschen Exportprofil oder einer fachlichen Rechnungslogik stammt.