Bei der Implementierung einer E-Rechnungs-Lösung ist es so gut wie ausgeschlossen, dass die ersten produzierten Rechnungen valide sind. Es wird daher dringend empfohlen, einen Validator zu benutzen, um sicherzustellen dass die erzeugten Rechnungen alle Anforderungen erfülen. Selbst, wenn die Lösung stabil läuft, ist es dennoch eine gute Idee, alle ausgehenden aber auch eingehenden Rechnungen zu validieren.
Elektronische Rechnungen müssen eine bestimmte Struktur aufweisen, die sich aus der ausgewahlte Syntax, entweder UBL oder CII ergibt. Die Syntax bestimmt, welche Elemente vorhanden sein müssen, und wo sie im Syntaxbaum verortet sind.
Die XML-Standards geben auch die genaue Reihenfolge der Elemente vor. Glücklicherweise sortiert E-Invoice-EU die Ausgabe automatisch, so dass man sich keine Gedanken um die Reihenfolge der Eingabedaten zu machen braucht. Dabei spielt es keine Rolle, ob sie über ein internen Rechnungsformat kommen.
Die korrekte Syntax wird von E-Invoice-EU sichergestellt. Die Software validiert die Eingabedaten gegen das jeweilge schema, wodurch sichergestellt ist, dass die Eingabe syntaktisch korrekt ist.
Das Schema enthält auch alle Codelisten, was garantiert, dass nur erlaubte Werte verwendet werden, soweit das für das jeweilige Element verlangt ist. Ebenso werden auch Zahlen- und Datumsformate auf Korrektheit überprüft.
Weiterhin gibt es semantische Anforderungen, die Business-Regeln genannt werden. Ein Beispiel für eine solche Regelung ist die Forderung, dass wenn die fällige Summe positiv ist, entweder ein Fälligkeitsdatum oder aber Zahlungsbedingungen angegeben werden müssen, siehe BR-CO-25.
Im allgemeinen werden diese Anforderungen von E-Invoice-EU nicht überprüft.
Viele dieser Regeln kommen aus dem Standard selbst. Andere Regeln werden von den Mitgliedsländern in Form von Core Invoice Usage Specifications (CIUS), siehe das Kapitel Erweiterungen, aufgestellt.
Beim Lesen dieser Regeln, taucht häufig die Abkürzung BT auf. BT steht für Business Term. Gemeint ist damit einfach ein Bezeichner für ein bestimmtes Rechnungsfeld. Zum Beispiel ist das Ausgabedatum einer Rechnung Business Term 2 oder kurz BT-2, siehe die Dokumentation für (cbc:IssueDate)[https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cbc-IssueDate/].
Diese Dokumentation enthält eine fast vollständige Liste von Business-Terms, siehe Business-Terms mit weiterführenden Links zur Dokumentation von Peppol UBL invoice.
Weil einem nichts anderes übrigbleibt. Validierungssoftware für E-Rechnungen zitiert diese Regeln in den Fehlermeldungen. Und es ist ziemlich schwer, diese Fehlermeldungen zu verstehen, wenn man nicht weiß, wofür die in der Regel erwähnten Business-Terms genau stehen.
Der Standard spricht auch von Business-Gruppen, abgekürzt als BG. Business-Gruppen sind einfach Gruppen verwandter Business-Terms. Zum Beispiel enthält BG-4 Informationen über die Ausstellerin wie elektronische und postalische Adressen, Steuerschemata, Informationen zur Rechtsform und so weiter, siehe cac:AccountingSupplierParty.
Diese Dokumentation enthält eine fast vollständige Liste von Business-Gruppen, siehe Business-Gruppen mit weiterführenden Links zur Dokumentation von Peppol UBL invoice.
Alle bekannten Validatoren sind in Java geschrieben und decken nur eine Teilmenge der verschiedenen Formate ab. Die einzige Ausnahme ist der Validator von Practical Peppol, der eine große Menge an Formaten validiert. Dieser Validator kann allerdings nicht ohne weiteres lokal aufgesetzt oder in andere Software integriert werden.
Das schränkt die Auswahl auf Online-Validatoren ein, was allerdings bedeuten würde, dass Rechnungsdaten über das Internet verschickt werden. Aus Datenschutzgründen sollte das aber nicht automatisch passieren, sondern Nutzer sollten dieses Feature explizit aktivieren.
Jedoch ist das Angebot einer automatischen Validierung ein für die Zukunft geplantes Feature, siehe GitHub-Issue #78.
E-Rechnungen können entweder zu einem Online-Validator hochgeladen werden oder von selbstgehosteter Software validiert werden.
Die folgende Liste von Software und Websites ist unvollständig. Um einen Eintrag zuzufügen, bitte ein [Ticket](https://github.com/gflohr/e-invoice-eu/issues) erstellen!
Online-Validatoren sind einfach zu benutzen. Man sollte jedoch daran denken, dass Rechnungen persönlische Daten oder sogar Geschäftsgeheimnisse enthalten können. Vor der Verwendung sollten deshalb alle rechtlichen Aspekte gewürdigt werden.
Die folgenden Online-Valdiatoren sind frei verfügbar:
Der Ecosio-Validator verwendet den Practical-Peppol-Validator. Für diese Validatoren muss das XML aus dem PDF extrahiert werden.
Der Validator von Practical-Peppol stellt eine SOAP-Schnittstelle zur Verfügung und ist damit für automatische Validierungsszenarien geeignet.
Der Ecosio-Validator verwendet intern den Validator von Practical Peppol.
Der Validator von Practical-Peppol stellt eine SOAP-Schnittstelle zur Verfügung und ist damit für automatische Validierungsszenarien geeignet.
Mustang project bietet Validierung von Rechnungen in den Formaten Factur-X/ZUGFeRD und XRechnung an. Zur Benutzung ist eine Java-Laufzeitumgebung erforderlich.
Ist Java installiert, muss die Datei Mustang-CLI-*VERSION*.jar von der
Release-Seite heruntergeladen und als Mustang-CLI.jar im Verzeichnis contrib/validators/factur-x gespeichert werden..
Danach lassen sich Factur-X/ZUGFeRD folgendermaßen validieren:
node contrib/validators/factur-x/factur-x-validate.mjs INVOICE_DOCUMENTIm Fehlerfall generiert die Software einen detaillierten Fehlerbericht, der aber leider nicht leicht zu verstehen ist.
Es lassen sich PDF-Dateien mit eingebetteten E-Rechnungen oder auch XML-Dateien übergeben. Der Validator prüft auch Dokumente, die dem Deutschen Standard XREchnung entsprechen. Die Homepage von Mustang Project liefert dazu aktuelle Informationen.
Ist der Java-Interpreter nicht im $PATH installiert, kann die Environment-Variable $JAVA gesetzt werden, um den Pfad zum Java-Interpreter anzugeben. Ebenso kann mit der Umgebungsvariablen $MUSTANG_CLI_JARder Pfad zur Jar-Datei von Mustang Project angegeben werden, sofern die Datei nicht untercontrib/factur-x/Mustang-CLI.jar` abgelegt wurde.
Der Validator von Practical Peppol kann ebenfalls lokal aufgesetzt werden. Dazu kann der Autor des Validators kontaktiert werden.
Die deutsche Koordinierungsstelle für IT-Standards -KoSIT bietet einen freien, quelloffenen Validator für beliebige E-Rechnungs-Formate an.
Benötigt wird eine Java-Laufzeitumgebung (Version 11 oder neuer) und es müssen mindestens zwei Software-Archive heruntergeladen werden, nämlich den eigentlichen Validator und ein sogenanntes Validierungs-Szenario mit den Schemata der unterstützten Formate.
Dzu muss die Datei validator-*VERSION*-distribution.zip heruntergeladen werden. Sie enthält eine Datei
validationtool-*VERSION*-standalone.jar, die als validationtool.jar
Verzeichnis contrib/validators/kosit gespeichert werden muss.
Mit diesem Kommando kann getestet werden, dass der Validator korrekt installiert wurde:
java -jar contrib/validators/kosit/validationtool.jarEs sollte eine Hilfeseite mit Informationen zur Benutzung ausgegeben werdne.
Ein „Szenario“ für XRechnung ist unter https://github.com/itplr-kosit/validator-configuration-xrechnung/releases verfügbar.
Die Datei validator-configuration-xrechnung_*VERSION*_*DATE*.zip muss ins Verzeichnis contrib/validators/kosit/xrechnung-scenario ausgepackt werden. Danach sollte dieses Kommando funktionieren:
ls contrib/validators/kosit/xrechnung-scenario/scenarios.xmlDieses Szenario enthält Schemata für UBL, CII, und verschiedene Versionen des deutschen Formats XRechnung.
Der Validator kann jetzt so gestartet werden:
node contrib/validators/kosit/validate.mjs invoice.pdfDas Ergebnis der Validierung wird auf die Konsole ausgegeben. Zusätzlich wird eine Datei *RECHNUNGS_DOKUMENT*-report.xml mit einem detaillierten Validierungs-Report und einer Visualisierung der Rechnung erzeugt. Trotz der Dateinamensendung .xml, handelt es sich bei diesem Report um eine HTML-Datei, die im Browser angezeigt werden kann.
Es lassen sich mehrere Dateien auf der Kommandozeile angeben, wenn mehrere Dokumente auf einmal validiert werden sollen.
Alternativ kann der Validator als Server gestartet werden:
node contrib/validators/kosit/validate.mjs --daemonDie Option -D ist ein Alias für --daemon.
Jetzt kann eine Web-Interface http://localhost:8080/ im Browser geöffnet werden, dass das Hochladen und die Validierung von Rechnungen erlaubt.
Alternativ dazu kann auch curl oder httpie verwendet werden:
$ curl POST -d @./invoice.xml http://localhost:8080/$ http POST -d @./invoice.xml http://localhost:8080/Für eine vollständig Beschreibung aller Optionen des Validators kann folgendes Kommando verwendet werden:
$ node contrib/validators/kosit/validate.mjs --helpEs ist zu beachten, dass das Wrapper-Skript immer die obligatorischen Optionen --scenarios und --repository übergibt.