Einen Validierungsbericht richtig lesen

Lesen Sie einen Validierungsbericht nicht wie ein technisches Logfile. Beginnen Sie mit dem Gesamtstatus, trennen Sie blockierende Fehler von Warnungen, notieren Sie Regel-ID und betroffenen Rechnungsbereich und übersetzen Sie den Befund danach in eine konkrete Korrekturaufgabe.

Für Buchhaltung, Lieferanten und ERP-Teams ist die entscheidende Frage nicht nur, welche Regel verletzt wurde. Entscheidend ist, ob die Rechnung verarbeitet werden kann, welche fachliche Information fehlt oder widersprüchlich ist und wer die Datenquelle korrigieren muss.

Validierungsberichte verbinden mehrere Ebenen: XML-Struktur, EN-16931-Geschäftsregeln, XRechnung- oder ZUGFeRD-Profilregeln, Code-Listen und manchmal zusätzliche Hinweise des Validators. Wer diese Ebenen vermischt, zieht schnell die falsche Schlussfolgerung.

Ein XML-Pfad zeigt, wo ein Problem gefunden wurde. Eine Regel-ID zeigt, welche Bedingung verletzt wurde. Beides erklärt aber noch nicht automatisch, ob die Ursache im ERP-Mapping, in den Stammdaten, in einer manuellen Rechnungsergänzung oder beim Lieferanten liegt. Genau diese Übersetzung macht den Bericht erst nutzbar.

1. Gesamtstatus prüfen: Ist die Datei valide, invalide oder nur mit Hinweisen auffällig?
2. Blockierende Fehler zuerst lesen: Fatal Errors, Errors oder vergleichbare Schweregrade haben Vorrang vor Warnungen.
3. Format und Profil notieren: XRechnung, ZUGFeRD/Factur-X, UBL, CII und Profilversion beeinflussen die Interpretation.
4. Regel-ID und Rechnungsbereich sichern: zum Beispiel Steuer, Summe, Käuferreferenz, Zahlungsdaten, Position oder Adresse.
5. Fachliche Ursache formulieren: Welche Angabe fehlt, passt nicht zusammen oder verwendet den falschen Code?
6. Korrekturverantwortung festlegen: Lieferant, Buchhaltung, Einkauf, Stammdatenpflege oder ERP-Team.
7. Nach Korrektur erneut validieren: Nicht nur die einzelne Fehlermeldung prüfen, sondern den kompletten Bericht neu erzeugen.

Die Bezeichnungen können je nach Validator leicht abweichen. Wichtig ist, dass Ihr Team eine interne Priorisierung hat: blockierende Fehler zuerst, dann wiederkehrende Warnungen, dann Hinweise für Prozessverbesserungen.

Eine Regel-ID wie eine BR-, BT- oder profilbezogene Meldung ist ein Diagnoseanker. Sie sollte in Lieferantenkommunikation und ERP-Tickets erhalten bleiben, weil sie dem technischen Team hilft, die genaue Prüfbedingung zu finden.

Der XML-Pfad ist dagegen kein guter Text für die Buchhaltung. Er zeigt die technische Stelle, aber nicht die fachliche Bedeutung. Übersetzen Sie ihn in normale Rechnungssprache: Rechnungsnummer, Rechnungsdatum, Käuferreferenz, Umsatzsteuergruppe, Positionsbetrag, IBAN, Einheitencode oder Zahlungsbedingung.

Nicht jeder Fehler gehört zum selben Team. Wenn diese Verantwortung unklar bleibt, werden Berichte weitergeleitet, aber nicht gelöst. Eine gute Auswertung ordnet jede relevante Meldung einer Datenquelle und einer Personengruppe zu.

• Lieferant: falsche oder fehlende Rechnungsdaten, falsches Format, falsches Profil, fehlende Referenzen, sichtbare Rechnung stimmt nicht zur XML.
• Buchhaltung: fachliche Prüfung von Steuerfall, Leistungsdatum, Zahlungsbedingungen, Rechnungstyp und Freigabeentscheidung.
• Einkauf oder Fachbereich: Bestellnummer, Vertragsreferenz, Kostenstelle, Projektbezug oder Empfängerangaben.
• ERP-Team: Mapping, Rundungslogik, Code-Listen, Exportprofil, UBL/CII-Syntax, ZUGFeRD-Einbettung oder XRechnung-Version.
• Stammdatenpflege: Adressen, Länder, Umsatzsteuer-IDs, IBAN, Einheiten, Kundennummern und Standardreferenzen.

Senden Sie Lieferanten nicht nur einen Screenshot aus dem Validator. Hilfreich ist ein kurzes Fehlerpaket: Originaldatei oder Referenz auf die Rechnung, Validierungsbericht, die wichtigsten blockierenden Meldungen, gewünschtes Zielformat und eine klare Bitte um korrigierte Neuausstellung.

Formulieren Sie den Befund fachlich. Statt nur einen XML-Pfad zu schicken, schreiben Sie zum Beispiel: Die Käuferreferenz fehlt im strukturierten Feld, obwohl sie für unseren Empfangsprozess benötigt wird. Bitte senden Sie eine neue XRechnung oder ZUGFeRD-Datei mit der vereinbarten Referenz.

Warnungen sind nicht automatisch nebensächlich. Eine Rechnung kann technisch akzeptiert werden und trotzdem später im Freigabe-, Zahlungs- oder Steuerprozess Probleme verursachen. Besonders relevant sind Warnungen, die wiederholt bei demselben Lieferanten auftreten oder Daten betreffen, die Ihr Unternehmen für Buchung und Freigabe benötigt.

• Warnungen zu Referenzen können spätere Zuordnung erschweren.
• Warnungen zu Zahlungsdaten können manuelle Nacharbeit oder Zahlungsrisiken erzeugen.
• Warnungen zu Steuer- oder Summenlogik sollten nicht ignoriert werden, wenn sie fachlich unplausibel wirken.
• Warnungen nach einem Standard- oder Validator-Update können zeigen, dass ein ERP-Export künftig angepasst werden muss.

Für wiederkehrende Verarbeitung sollte der Bericht Teil eines festen Ablaufs sein. So vermeiden Teams, dass jede Meldung neu diskutiert wird.

1. Eingang prüfen und Datei eindeutig der Rechnung zuordnen.
2. Validierungsbericht erzeugen und zusammen mit der lesbaren Ansicht prüfen.
3. Blockierende Fehler in eine kurze Korrekturliste übertragen.
4. Ursache einer Datenquelle zuordnen.
5. Lieferant oder internes Team mit Regel-ID und fachlicher Übersetzung informieren.
6. Korrigierte Datei erneut prüfen und alten Bericht nicht als Nachweis für die neue Datei verwenden.