Eine Rechnung als PDF öffnen, Beträge kontrollieren, fertig. Bei elektronischen Rechnungen reicht das nicht unbedingt. Entscheidend sind auch die strukturierten XML-Daten, die bei XRechnung direkt als XML oder bei ZUGFeRD und Factur-X in einer PDF-Datei eingebettet vorliegen.
Mit erechnung.tools ist jetzt ein kostenloser Validator online, der genau diese Daten prüft. XRechnung sowie ZUGFeRD- und Factur-X-Dateien lassen sich hochladen, validieren und anschließend in einer lesbaren Rechnungsansicht darstellen.
Interessant wird das vor allem bei Rechnungen, die auf den ersten Blick völlig korrekt aussehen.
Das PDF stimmt, die E-Rechnung trotzdem nicht
Bei ersten Tests mit realen Rechnungen zeigte sich genau dieser Fall. Die sichtbare PDF-Rechnung war unauffällig: Positionen, Beträge, Umsatzsteuer und Rechnungssumme passten.
Der Validator meldete trotzdem Fehler in den eingebetteten Rechnungsdaten.
In einem Fall schlug die Regel BR-DEC-23 an. Sie begrenzt die Anzahl der Nachkommastellen beim Nettobetrag einer Rechnungsposition. Während das PDF bereits einen sauber gerundeten Betrag zeigte, enthielt das strukturierte XML Werte mit zu vielen Dezimalstellen.
Ein zweites Beispiel lieferte PEPPOL-EN16931-R008. Dort enthielt das XML ein leeres Element. Auch davon war in der sichtbaren PDF-Darstellung nichts zu erkennen.
Das zeigt eine Besonderheit hybrider E-Rechnungen ziemlich deutlich: Menschen sehen das PDF, Buchhaltungs- und ERP-Systeme verarbeiten das XML.
Was erechnung.tools prüft
Bei einer reinen XRechnung kann das enthaltene XML direkt untersucht werden. Bei ZUGFeRD und Factur-X muss zunächst das in der PDF-Datei eingebettete Rechnungs-XML gefunden und extrahiert werden.
Danach erkennt das Tool unter anderem Rechnungsformat, Syntax und Profil und übergibt die strukturierten Daten an den Validator.
Das Prüfergebnis zeigt nicht nur „gültig“ oder „nicht gültig“. Angezeigt werden auch konkrete Fehlercodes, betroffene Stellen im XML und – für bereits aufbereitete Regeln – eine verständliche deutsche Erklärung.
Die Rechnungsdaten selbst werden parallel in einer lesbaren Ansicht dargestellt. Dazu gehören unter anderem Verkäufer, Käufer, Rechnungsdatum, Positionen, Mengen, Preise, Netto, Umsatzsteuer und Gesamtbetrag.
Technische Fehlermeldungen werden übersetzt
Validierungsregeln sind ursprünglich nicht für normale Anwender geschrieben. Eine Meldung wie Document MUST not contain empty elements sagt einem Buchhalter oder Unternehmer zwar, dass etwas nicht stimmt, aber noch nicht unbedingt, was zu tun ist.
erechnung.tools verbindet deshalb technische Validatorausgaben mit einer eigenen Fehlerdatenbank.
Aus BR-DEC-23 wird beispielsweise die verständlichere Erklärung „Positions-Nettobetrag hat zu viele Nachkommastellen“. Zusätzlich wird beschrieben, welches Rechnungsfeld betroffen ist und wie der Fehler typischerweise behoben werden kann.
Die technische Originalmeldung bleibt trotzdem erhalten und kann bei Bedarf eingeblendet werden. Damit eignet sich das Ergebnis auch für die Weitergabe an Softwareanbieter oder IT-Dienstleister.
1.440 Regeln im technischen Katalog
Die eigentliche Rechnungsvalidierung wird nicht von erechnung.tools neu erfunden. Grundlage sind KoSIT und die installierten Regelwerke für elektronische Rechnungen.
Aus den aktuell eingesetzten Validator-Artefakten wurden 1.440 technische Regeln automatisch katalogisiert. Dazu gehören unter anderem EN-16931-, XRechnung-, Peppol-, UBL- und Factur-X-Regeln.
Aus diesen 1.440 Regeln werden allerdings nicht automatisch ebenso viele öffentliche Seiten erzeugt. Zum Start gibt es ausführliche Erklärungen nur für eine Auswahl relevanter Fehlercodes.
Dazu zählen etwa BR-DE-15 für eine fehlende Käuferreferenz, BR-CO-17 für eine fehlerhafte Umsatzsteuerberechnung, BR-DEC-23 für zu viele Nachkommastellen sowie PEPPOL-EN16931-R008 für leere XML-Elemente.
Weitere Regeln sollen vor allem danach ergänzt werden, welche Fehler bei tatsächlichen Prüfungen auftreten.
Rechnungen werden nicht dauerhaft gespeichert
Ein öffentlicher Rechnungsvalidator verarbeitet zwangsläufig sensible Geschäftsdaten. Deshalb wurde die Verarbeitung so aufgebaut, dass hochgeladene Rechnungen nicht dauerhaft gespeichert werden.
Eine Datei wird nur in einem temporären Arbeitsbereich verarbeitet. Bei einer ZUGFeRD- oder Factur-X-Datei wird dort zusätzlich das eingebettete XML extrahiert. Nach Abschluss der Prüfung werden Originaldatei, XML und temporäre Validator-Dateien wieder entfernt.
Die Rechnungen landen weder in der WordPress-Mediathek noch dauerhaft in einer Datenbank. Auch für die Erklärung eines Fehlers werden die Rechnungsinhalte nicht an einen externen KI-Dienst geschickt.
Ein Validator entscheidet nicht über den Vorsteuerabzug
Eine technische Fehlermeldung ist allerdings nicht automatisch eine steuerliche Bewertung.
Eine E-Rechnung kann gegen eine XRechnung-, EN-16931- oder Peppol-Regel verstoßen, ohne dass dadurch automatisch der Vorsteuerabzug entfällt. Umgekehrt können bestimmte fehlende oder falsche Rechnungsangaben steuerlich relevant sein und eine Rechnungsberichtigung erforderlich machen.
Der Validator beantwortet deshalb zunächst eine technische Frage: Entspricht die elektronische Rechnung den geprüften Regeln?
Die steuerliche oder rechtliche Bedeutung eines konkreten Fehlers muss davon getrennt betrachtet werden.
Warum der Blick ins XML wichtiger wird
Mit der E-Rechnung entsteht eine interessante Verschiebung. Die für Menschen sichtbare Rechnung und die für Software maßgeblichen Daten können unterschiedlich aussehen.
Ein sauber gerendertes PDF ist deshalb kein Beweis dafür, dass auch die eingebetteten Rechnungsdaten korrekt sind. Umgekehrt kann ein Validator einen sehr technischen Fehler melden, obwohl die eigentlichen Rechnungsbeträge stimmen.
Genau diese Lücke soll erechnung.tools schließen: Datei hochladen, Format erkennen, strukturierte Rechnungsdaten prüfen und anschließend verständlich anzeigen, was tatsächlich gefunden wurde.
Der kostenlose Validator ist unter erechnung.tools erreichbar und unterstützt sowohl XML-Rechnungen als auch ZUGFeRD- und Factur-X-PDFs.
