Technische Deep-Dives
Warum Validator-Versionen bei E-Rechnungen wichtig sind
Dieselbe E-Rechnung kann je nach EN-16931-Artefakten, Codelisten und KoSIT-/XRechnung-Prüfstand unterschiedlich bewertet werden. Der Artikel erklärt, warum aktuelle Validierung der Standardweg ist und wann Diagnosevergleiche helfen.
Zuletzt fachlich geprüft: 10. Juli 2026
Direkte Antwort
Validator-Versionen sind bei E-Rechnungen kein technisches Detail am Rand. Sie bestimmen mit, welche Regeln, Codelisten, Fehlerschweregrade und Schematron-Prüfungen auf eine XML-Datei angewendet werden. Deshalb kann dieselbe Datei mit einem älteren Prüfstand ungültig sein, mit einem neueren Prüfstand aber nur Warnungen erzeugen oder gültig werden.
Das bedeutet nicht automatisch, dass ein Validator falsch ist. Häufig prüfen verschiedene Systeme schlicht mit unterschiedlichen Artefaktständen. Für Buchhaltung, ERP-Teams und Lieferanten ist deshalb wichtig: Ein Validierungsbericht sollte nicht nur das Ergebnis zeigen, sondern auch die verwendete Version des Prüfstands dokumentieren.
Praktische Konsequenz
Wenn ein Empfänger eine Rechnung ablehnt, sollte man nicht nur über die XML-Datei sprechen, sondern auch über Validator, XRechnung-Version, EN-16931-Artefakte, Codelisten und Regeldatum.
Warum sich Ergebnisse ändern können
E-Rechnungsvalidierung besteht aus mehreren Schichten. Zuerst muss die Datei technisch lesbar sein. Danach wird die XML-Struktur gegen UBL oder CII geprüft. Anschließend greifen EN-16931-Geschäftsregeln, Codelisten und bei XRechnung zusätzliche deutsche CIUS-Regeln.
Diese Schichten werden gepflegt und veröffentlicht. Die EU stellt im Registry of supporting artefacts technische Ressourcen wie Validation Artefacts und Codelisten bereit. KoSIT veröffentlicht XRechnung-Validator-Konfigurationen, die Schema- und Schematron-Regeln für die Prüfung von UBL- und CII-Rechnungen gegen XRechnung bündeln.
| Schicht | Was sie prüft | Warum Versionierung relevant ist |
|---|---|---|
| XML-Syntax | Ist die Datei technisch lesbar? | Parser- und Sicherheitslogik ändern sich selten, aber Fehler müssen getrennt ausgewiesen werden. |
| UBL/CII-Schema | Passt die XML-Struktur zur Syntaxfamilie? | Schemafamilie und Rechnungsformat müssen korrekt erkannt werden. |
| EN 16931 | Europäische Kernregeln, Summen, Steuerlogik, Pflichtfelder | Validation Artefacts und Codelisten werden aktualisiert. |
| XRechnung CIUS | Deutsche Einschränkungen und zusätzliche Anforderungen | KoSIT-Prüfstände und XRechnung-Bundles haben eigene Stände. |
| Empfängerregeln | Portal-, ERP- oder Peppol-spezifische Anforderungen | Nicht jede Empfängerumgebung ist auf demselben Stand. |
Typische Situationen in der Praxis
| Situation | Was wahrscheinlich passiert | Was Sie prüfen sollten |
|---|---|---|
| Aktuell gültig, früher ungültig | Eine Regel wurde geändert, abgeschwächt, entfernt oder durch neuere Codelisten anders bewertet. | Welcher ältere Prüfstand meldet welchen Fehlercode? |
| Aktuell ungültig, früher gültig | Neuere Regeln oder Codelisten erkennen ein Problem, das vorher nicht geprüft wurde. | Ist die Rechnung nach aktuellem Prüfstand wirklich korrigiert? |
| Nur Warnung statt Fatal Error | Der Fehlerschweregrad hat sich geändert oder die Regel wird im aktuellen Kontext anders eingeordnet. | Ob Empfänger Warnungen akzeptiert oder intern blockiert. |
| Portal lehnt ab, eigener Validator akzeptiert | Portal, ERP oder Dienstleister nutzt einen anderen Prüfstand. | Regeldatum und Artefaktversion beider Systeme vergleichen. |
| Alte Testdatei passt nicht mehr | Beispiel- oder Regressionstest wurde gegen einen früheren Stand erstellt. | Testdaten mit erwarteter Validator-Version dokumentieren. |
Wie ein guter Bericht damit umgehen sollte
Ein guter Validierungsbericht macht Versionierung sichtbar. Er sollte angeben, welches Profil die Rechnung deklariert, welche Syntax erkannt wurde, welcher Prüfstand angewendet wurde, welches Regeldatum gilt und welche wichtigsten Fehlercodes das Ergebnis bestimmen.
Für neu zu prüfende Rechnungen sollte der aktuelle Prüfstand der Standardweg bleiben. Ein optionaler Vergleich mit historischen KoSIT-/XRechnung-Prüfständen ist vor allem Diagnosematerial, wenn ERP-Systeme, Portale oder Empfänger abweichende Ergebnisse liefern.
- Standardmäßig mit dem aktuellen Prüfstand validieren.
- Version, Regeldatum, Syntax und Codelisten im Ergebnis zeigen.
- Bei Bedarf historische Prüfstände getrennt ausweisen.
- Fehlercodes je Version nicht vermischen.
- Warnungen und Fehler fachlich erklären, statt nur Regel-IDs zu zeigen.
Was das nicht bedeutet
Ein Prüfstandsvergleich ersetzt keine rechtliche, steuerliche oder buchhalterische Entscheidung. Er beantwortet eine technische Frage: Welche Validator-Version bewertet diese Datei wie?
Für den Nachweis ist wichtiger, die Rechnung zeitnah zu validieren und den damaligen Validierungsbericht mit der Originalrechnung im eigenen System zu archivieren. Ein Versionsvergleich ist hilfreich für Support und Integrationsdiagnose, aber nicht der normale Nachweisprozess.
Praktische Checkliste
- Validator-Version, Regeldatum und Artefaktstand im Bericht dokumentieren
- Rechnungsprofil der XML-Datei vom verwendeten Prüfstand trennen
- Bei widersprüchlichen Ergebnissen Codelisten und Schematron-Versionen vergleichen
- Alte Testdateien immer mit erwarteter Validator-Version pflegen
- Empfänger fragen, welchen Prüfstand Portal oder ERP tatsächlich nutzt
- Versionsvergleich nur aktivieren, wenn der Vergleich für Diagnose oder Support gebraucht wird
Wichtig
Ein grünes Ergebnis ohne Versionsangabe ist nur begrenzt reproduzierbar. Für Support, ERP-Regressionstests und Lieferantenklärung gehört der verwendete Prüfstand in den Bericht.