XRechnung: zwei Validatoren liefern unterschiedliche Ergebnisse

Dieselbe XML-Datei ist im eigenen System „gültig“, beim Empfänger oder einem anderen Werkzeug wird sie abgewiesen. Beide Oberflächen nennen XRechnung 3.0.2. Ein Mustang-Bericht zeigt, warum diese Bezeichnung nicht genügt: Die tatsächlich verwendeten Validierungsartefakte können unterschiedlich alt sein. Ein Teilupdate kann außerdem eine neue technische Inkompatibilität erzeugen. Q1

Formatversion ist nicht der komplette Prüfstand

Zum Vergleich gehören Validator, Konfigurationspaket, Regelartefakte und erkanntes Szenario. KoSIT veröffentlicht Konfigurationsreleases mit Angaben zu zusammengehörigen Komponenten und Änderungen an der Fehlerbewertung. Q2 Eine unveränderte Formatbezeichnung bedeutet deshalb nicht automatisch identische Prüfergebnisse.

Den Unterschied reproduzierbar machen

1. Identische Eingabe sichern. Vergleiche die Prüfsummen der tatsächlich geprüften XML-Dateien. Ein aus einer PDF extrahierter Inhalt und ein separat versendeter Export können unterschiedliche Stände sein.
2. Beide Prüfstände erfassen. Notiere Toolversion, Konfigurationsrelease, Regeldateien und Einstellungen. Bei einer eingebetteten Bibliothek zählt der tatsächlich ausgelieferte Stand, nicht nur die Versionsangabe im Quellcodeprojekt.
3. Szenario und Profil vergleichen. Prüfen beide Werkzeuge dieselbe Syntax und denselben vorgesehenen Austauschkontext? Eine andere Szenarioerkennung kann andere Regeln auslösen. Halte diese Entscheidung im Bericht fest.
4. Eine abweichende Regel verfolgen. Wähle den ersten konkreten Unterschied mit Regel-ID, Fundstelle und Schweregrad. Vergleiche dazu den veröffentlichten Änderungsverlauf. Ein Fehler, eine Warnung und ein abgebrochener Verarbeitungslauf dürfen nicht als dasselbe Ergebnis behandelt werden.
5. Zusammengehöriges Paket testen. Erprobe einen dokumentiert kompatiblen Prüfstand in einer getrennten Umgebung. Tausche nicht wahllos nur eine XSL-Datei aus. Eine neue Exception nach dem Update kann eine Integrationsinkompatibilität sein und sagt zunächst nichts über die Rechnung aus.

Einen stabilen Prüfprozess definieren

Vereinbare für den konkreten technischen Austausch einen nachvollziehbaren Prüfstand und dokumentiere dessen Aktualisierung. Halte Regressionstestdateien vor, die wichtige bisherige Fehler und erfolgreiche Fälle abdecken. Wenn der Empfänger einen anderen Stand verlangt, muss diese Anforderung in den Vergleich aufgenommen werden; ein beliebiger grüner Onlinetest ersetzt sie nicht.

Für Unterstützung helfen beide vollständigen Berichte, die Versionsmatrix und eine minimierte Beispieldatei. Die Anleitung betrifft technische Regelanwendung. Sie entscheidet nicht über steuerliche Sachverhalte oder die rechtliche Ordnungsmäßigkeit einer Rechnung.

Häufige Fragen

Welcher Validator hat recht?

Das lässt sich ohne Eingabeidentität, Szenario und Regelstand nicht aus der Oberfläche ablesen. Beginne mit dem konkreten Regelunterschied.

Soll ich immer sofort die neueste Einzeldatei einsetzen?

Nein. Verwende ein zusammenpassendes, für deine Integration geprüftes Paket und halte die Änderung nachvollziehbar fest.

Fall beschreiben