Wie XRechnung-Validierung funktioniert

Eine XRechnung ist gültig, wenn sie nicht nur technisch lesbares XML ist, sondern auch zum richtigen Rechnungsstandard, zur richtigen Syntax und zu den fachlichen Regeln passt. Ein Validator prüft deshalb schrittweise: Kann die Datei gelesen werden? Ist sie UBL oder CII? Passt die XML-Struktur? Stimmen die EN-16931-Geschäftsregeln? Und erfüllt sie die deutschen XRechnung-Anforderungen?

Genau diese Schichten erklären, warum manche Fehlerberichte zuerst sehr technisch aussehen. Ein guter Bericht sollte daraus aber eine praktische Aussage machen: welches Feld betroffen ist, warum es scheitert und wer es korrigieren muss.

In der Praxis ist Validierung keine einzelne Ja/Nein-Prüfung. Eine Rechnung kann in einer frühen Schicht scheitern, bevor spätere Regeln überhaupt sinnvoll ausgeführt werden können.

Der erste Schritt ist die Frage, was überhaupt vorliegt: eine reine XML-Datei, ein ZUGFeRD- oder Factur-X-PDF mit eingebettetem XML, oder ein normales PDF ohne strukturierte Rechnungsdaten. Diese Unterscheidung ist wichtig, weil jede Variante anders behandelt werden muss.

Bei einer reinen XRechnung wird direkt die XML-Struktur geprüft. Bei ZUGFeRD oder Factur-X muss zuerst die eingebettete XML-Rechnung aus dem PDF gelesen werden. Das sichtbare PDF-Bild allein ist nicht der Validierungsgegenstand.

Bevor Fachregeln greifen, muss die Datei well-formed XML sein. Dazu gehören korrekte öffnende und schließende Tags, gültige Zeichen, korrekt deklarierte Namespaces und eine saubere Kodierung.

Fehler in dieser Schicht sind meistens technische Export- oder Übertragungsfehler. Die Buchhaltung kann sie selten fachlich korrigieren; hier muss meist das ERP-System, der Exportprozess oder der Softwareanbieter geprüft werden.

Die XSD-Prüfung kontrolliert, ob die XML-Datei zur verwendeten Syntax passt. UBL und CII haben unterschiedliche Strukturen. Ein Element kann fachlich sinnvoll wirken, aber technisch an der falschen Stelle stehen oder den falschen Datentyp haben.

XSD beantwortet aber nicht alle fachlichen Fragen. Eine Datei kann schema-gültig sein und trotzdem fachlich falsch sein, zum Beispiel wenn Summen nicht zusammenpassen oder eine Steuerregel verletzt wird.

Viele E-Rechnungsregeln lassen sich nicht sinnvoll nur mit XSD ausdrücken. Dafür werden Schematron-Regeln verwendet. Sie prüfen Zusammenhänge innerhalb der Rechnung: Pflichtfelder, Summenformeln, Steuerlogik, Referenzen und Bedingungen zwischen mehreren Feldern.

Ein klassisches Beispiel ist eine Summe, die rechnerisch zu Positionswerten, Zuschlägen, Abschlägen und Steuern passen muss. Die XML-Struktur kann korrekt sein, aber die Business Rule schlägt trotzdem fehl.

EN 16931 definiert das europäische semantische Kernmodell für elektronische Rechnungen. XRechnung ist die deutsche Core Invoice Usage Specification auf dieser Grundlage. Praktisch bedeutet das: Eine XRechnung muss zur europäischen Basis passen und zusätzlich die deutschen Einschränkungen erfüllen.

Deshalb kann ein Validator mehrere Regelpakete ausführen. Erst wird die allgemeine EN-16931-Konformität geprüft, dann die XRechnung-spezifische Ausprägung. Bei Peppol-Kontexten können zusätzlich Peppol-Regeln relevant sein.

Viele Werte in einer E-Rechnung sind keine freien Texte. Einheiten, Länder, elektronische Adressschemata, Steuerkategorien und Dokumenttypen stammen aus Codelisten. Diese Listen ändern sich und werden in Validierungsartefakten versioniert.

In der Praxis entstehen Fehler, wenn ein ERP-System alte Codes nutzt, eine falsche XRechnung-Version exportiert oder Empfänger und Sender unterschiedliche Prüfstände verwenden. Deshalb ist es wichtig, nicht nur die Rechnung, sondern auch den verwendeten Validator und dessen Artefakt-Version zu kennen.

Ein technischer Validator meldet oft Regelkennungen, XPath-Stellen und englische Regeltexte. Für die operative Arbeit reicht das selten. Buchhaltung und Lieferanten brauchen eine Übersetzung in klare Rechnungsbereiche: Rechnungskopf, Käufer, Verkäufer, Positionen, Steuern oder Summen.

Ein guter Bericht trennt außerdem Fehler von Warnungen. Fehler verhindern die Annahme oder Verarbeitung. Warnungen zeigen Risiken, Unklarheiten oder potenzielle Empfängerprobleme, die nicht immer formal ungültig sind.

Angenommen, eine Rechnung ist syntaktisch korrekt, nutzt die richtige UBL-Struktur und enthält alle Pflichtbereiche. Trotzdem kann sie an einer Summenregel scheitern, wenn der Steuerbetrag nicht zur Bemessungsgrundlage und zum Steuersatz passt.

Dieser Fehler erscheint erst in der Schematron-Schicht. Das ist kein Widerspruch. Es bedeutet nur: Die Datei ist technisch lesbar, aber die fachliche Rechnung stimmt nicht.

ERP-Teams sollten Validierung nicht als letzten manuellen Schritt behandeln. Besser ist eine Vorabprüfung direkt nach dem Export, mit klarer Protokollierung der verwendeten Versionen: XRechnung-Version, Syntax, EN-16931-Artefakte, Codelisten und Validator-Konfiguration.

Für Lieferantenkommunikation sollte der Fehlerbericht so aufbereitet sein, dass nicht nur die technische Regel, sondern auch die fachliche Korrektur sichtbar wird. Sonst bleibt die Fehlerbehebung unnötig langsam.