Ein Beitrag unseres Partners Munich Data Quality GmbH, Dr. Matthias Nopper
Haben Sie schon einmal versucht, eine E-Rechnung mit unterschiedlichen Online- Validatoren zu überprüfen? Falls ja, könnte es Ihnen passiert sein, dass Sie bei der gleichen Nachricht unterschiedliche Ergebnisse erhalten haben. Eine Datei erschien in einer Prüfung korrekt, in der nächsten wurden zahlreiche Fehler bemängelt. Um dieses Phänomen zu erklären, zeigen wir zunächst, welche Tests Sie für die XML-Formate anwenden können, auf denen E-Rechnungen im Sinne der Norm EN 16931 basieren. Danach kommen wir zu den Besonderheiten von E-Rechnungs-Prüfungen.
Grundsätzlich existieren drei Ebenen von XML-Prüfungen. Die einfachste ist die Prüfung auf Wohlgeformtheit. Darunter wird die Einhaltung der Basis-Struktur einer XML-Datei verstanden. Ein Beispiel aus dieser Kategorie ist die Prüfung, ob nur ein einziges Wurzelelement existiert. XML-Dateien, die nicht wohlgeformt sind, können in aller Regel nicht durch das Zielsystem verarbeitet werden, an das sie geschickt werden.
Die nächste Ebene sind Prüfungen gegen eine Dokumenttypdefinition (DTD) oder ein XML-Schema (XSD). In beiden Fällen handelt es sich um Vorgaben, wie ein XML- Dokument aufgebaut werden muss. Sie geben beispielsweise vor, wie die Elemente ineinander verschachtelt sein müssen, damit die Datei korrekt verarbeitet werden kann. Da XSDs mehr Funktionen bieten als DTDs, werden Sie letztere nur noch selten vorfinden. Auch die Strukturvorgaben für die allermeisten E-Rechnungsformate werden in XSDs festgehalten.
Als dritte Ebene können Schematron-Regeln in eine XML-Validierung eingebunden werden. Mit ihnen überprüfen Sie insbesondere komplexere Zusammenhänge in einer Nachricht, oft über mehrere Elemente hinweg. Ein Beispiel: Sie möchten vergleichen, ob der angegebene Gesamtbetrag für alle Nachlässe auf Dokumentenebene der Summe der einzelnen Nachlässe auf Dokumentenebene entspricht. Da das Erstellen von Schematron-Regeln Zeit und Wissen erfordert, finden Sie diese Prüfungen nicht in allen XML-Prüfschnittstellen.
XML-Dateien, die gegen eine DTD-, XSD- oder Schematron-Prüfung verstoßen, können in manchen Fällen noch durch ein Zielsystem verarbeitet werden, werden aber in aller Regel Nacharbeiten nach sich ziehen.
Der Begriff „Elektronische Rechnung“ deckt ein weites Feld von Formaten und Inhalten ab. Beginnen wir damit, dass es zwei XML-basierte Formate gibt, mit denen eine E- Rechnung im Sinne der europäischen Norm EN 16931 umgesetzt werden kann: Die Cross-Industry-Invoice (CII) und die Universal Business Language (UBL), genauer gesagt das Rechnungs-Schema innerhalb der UBL.
Diese beiden Formate werden in unterschiedlichen Spezifikationen eingesetzt. Die in Deutschland bekanntesten dürften die XRechnung und die ZUGFeRD-Rechnung sein. Die ZUGFeRD-Rechnung ist mittlerweile auch unter dem Namen Factur-X bekannt. Sowohl XRechnung als auch Factur-X existieren in unterschiedlichen Versionen, neben dem aktuellen Stand gibt es Versionen, die außer Kraft getreten sind.
Es gehört zu den Charakteristiken der Norm EN 16931, dass sie zwischen einem europäischen Kernrechnungsmodell, nationalen Anwendungsspezifikationen (CIUS) und Erweiterungen unterscheidet. Dabei enthält das Kernrechnungsmodell eine begrenzte Anzahl an Vorgaben zu den Inhalten der Rechnung. Dazu gehört beispielsweise die Anforderung, dass Zuschläge auf Positionsebene einen Zuschlagsbetrag ausweisen müssen. In den CIUS können Anwender einschränken, welche Informationen verwendet werden dürfen. Mit einer Erweiterung können sie dem Kernrechnungsmodell dagegen Elemente hinzufügen.
In Deutschland ist die XRechnung die CIUS für das B2G-Umfeld, sie kann aber auch als Extension XRechnung verwendet werden. Dann kann sie beispielsweise Unterposition enthalten. Diese sind nicht im Kernrechnungsmodell enthalten. Grundsätzlich können aber auch private Unternehmen eine CIUS für ein EN 16931-Format erstellen und ihre Handelspartner auffordern, Rechnungen gemäß dieser Vorgabe zu erstellen.
Um sicherzustellen, dass nur korrekte Rechnungen verarbeitet werden, können die Rechnungsempfänger die drei Ebenen der XML-Validierungen anwenden. Wir nähern uns nun dem Kern unserer Fragestellung, denn während Prüfungen auf Wohlgeformtheit universell sind, können die Datenempfänger unterschiedliche XSDs oder Schematron- Regeln für ihre Prüfungen verwenden.
Wenn beispielsweise ein Datenempfänger über die Vorgaben der EN 16931 hinaus keine Anwendungsspezifikationen oder Erweiterungen verwendet, entfallen die damit verbundenen Prüfungen. Wenn dagegen die Handelspartner Rechnungen über das PEPPOL-Netzwerk austauschen, kommen die entsprechenden Schematron-Regeln für diesen Fall hinzu.
Fassen wir zusammen: Welche Vorgaben in einer Validierung enthalten sind, hängt von unterschiedlichen Faktoren ab:
Sie sollten also nachvollziehen, welche Prüfvorgaben verwendet werden, wenn Sie eine Datei validieren. Insbesondere bei Fehlermeldungen sollten Sie überlegen, ob die Sachverhalte überhaupt relevant für Ihre Geschäftsprozesse sind, ehe Sie eventuell unnötige Anpassungen an der Rechnungserzeugung vornehmen.
Bei unserem Partner Munich Data Quality verwenden wir für Validierungen von E-Rechnungen gemäß EN 16931 standardmäßig die CIUS XRechnung oder die Factur-X mit Profil EN 16931 im jeweils aktuellen Standard. Auf Wunsch passen wir aber auch gerne die Prüfungen an die Anforderungen unserer Kunden an.