eRechnung mit der EN16931: 1 Standard, 2 Syntaxen, viele CIUSe

Bessere Interoperabilität und keine rein nationalen Erweiterungen. So soll die eRechnung ihren Siegeszug von der öffentlichen Verwaltung in Europa hin zur Wirtschaft führen. So die Idee der Väter der EN16931 vor. Nach der Veröffentlichung stellt sich die Frage, warum man sich nicht nur auf eine Syntax zur Umsetzung einigen konnte, da dies für die Umsetzung einfacher gewesen wäre. Diese eigentlich zunächst sehr logische Überlegung ist jedoch zu kurz gedacht. Denn der elektronische Austausch von Rechnungen ist kein neues Thema. Zumindest nicht für alle Marktteilnehmer in Europa. Bereits seit Jahrzehnten haben sich in der Wirtschaft verschiedene Verfahren etabliert, allen voran EDI insbesondere auf Basis von UN/EDIFACT. Dieser globale Standard ist der weltweit meistgenutzte Standard in der Wirtschaft.

Jedoch nicht bei öffentlichen Auftraggebern. Viele europäische Länder setzten im Bereich B2G mit UBL auf einen Standard, der auf XML basiert. Gerade in Frankreich und Deutschland hat die CrossIndustryInvoice in den letzten Jahren an Fahrt gewonnen, nicht zuletzt durch das ZUGFeRD – Format. In den Niederlanden werden Blumen und Agrarprodukte ebenfalls überwiegend auf Basis der CrossIndustryInvoice gehandelt. Die Wirtschaft ist hier – auf gesamteuropäischer Ebene betrachtet – der Verwaltung noch um einiges voraus.

Die EN16931 und die zugehörige Direktive richten sich jedoch insbesondere an öffentliche Auftraggeber als Rechnungsempfänger. Bei der Diskussion der Anzahl der Syntaxen sind daher auch die gesamtwirtschaftlichen Kosten aus der Kombination von Norm und Gesetzgebung zu betrachten. Die gemischte Gemengelage und der – in vielen Ländern noch bestehende – Vorsprung der Wirtschaft beeinflusst daher in nicht unerheblichem Standard die Entscheidung: Da UN/EDIFACT in der Verwaltung bisher kaum angewendet wird, in der Wirtschaft jedoch ein wichtiger Datenaustauschstandard ist, berücksichtigt die Norm diese Syntax ebenfalls. CEN/TS 16931-3-4 definiert daher die technische Abbildung des semantischen Datenmodells in UN/EDIFACT. Jedoch ist diese Syntax nicht verpflichtend umzusetzen, sondern kann auf freiwilliger Basis beibehalten oder auch neu umgesetzt werden.

Wenn ich nur die Pflichtelemente sende, habe ich weniger zu tun!?

Mit der Definition des Standards ist nun alles klar, vor allem da es sich ja nur um die Kernelemente einer eRechnung handelt. Ganz so einfach ist es leider nicht. Gemäß semantischem Datenmodell sind nämlich nur wenige Elemente verpflichtend anzugeben. Lässt man mal rechtliche Aspekte und Geschäftsregeln beiseite, siehe eine elektronische Rechnung, die nur die Pflichtangaben enthält, sehr mager aus.

Für das Ziel der automatisierten Verarbeitung und insbesondere der Rechnungsprüfung geschweige denn der Dunkelbuchung reichen diese Daten bei Weitem nicht aus. Jedoch benötigt auf der anderen Seite auch nicht jeder Empfänger alle verfügbaren Möglichkeiten, die das semantische Datenmodell hergibt. Genau um dieses Dilemma zu lösen, sieht die Norm die Idee der Core Invoice Usage Specification vor. Sie soll es dem Rechnungsempfänger ermöglichen zu definieren, welche der optionalen Elemente er für die automatisierte Rechnungsverarbeitung benötigt.

Und das ist an sich auch nichts Neues. Lediglich der Begriff CIUS ist dafür neu. In der Standarisierung ist genau für diesen Zweck sonst der Begriff der Anwendungsempfehlung üblich. Es soll dem Rechnungssteller eine Hilfestellung dafür sein, welche Informationen der Rechnungsempfänger über die Pflichtangaben (Datenmodell und steuerliche) hinaus benötigt. Solche Anwendungsempfehlungen existieren bisher sowohl für bestimmte Benutzergruppen, als auch manchmal bei großen Rechnungsempfängern. Kern dieser Empfehlungen ist es in den meisten Fällen, eine technische Zuordnung zwischen der Rechnungsdatei und dem System des Empfängers herzustellen. Typische Elemente hierfür sind zum Beispiel die Bestellnummer, Vertragsnummer, ein Kassenzeichen oder eine sonstige Transaktionsnummer. Auf einer Papierrechnung ist ein solches Feld häufig mit “Ihr Zeichen” beschriftet.

Ein weiterer Aspekt einer Anwendungsempfehlung besteht in der Regel darin zu definieren, welche Werte von Codelisten auf Empfängerseite verarbeitet werden können. So enthält alleine die Liste der möglichen Mengeneinheiten mehr als 2000 unterschiedliche Werte. Darüber hinaus unterstützt die Norm mehr als 40 verschiedene Dokumententypen, die Varianten der Rechnung oder Gutschrift darstellen können.

Mehr oder weniger Interoperabilität der eRechnung dank der CIUS

Doch genau hier beginnt die Herausforderung mit der Interoperabilität. Denn was bedeutet es in der Praxis, wenn ein Rechnungsempfänger eine Rechnung ablehnt, weil er einen bestimmten Dokumententyp nicht verarbeiten kann? Dann wird der Rechnungssender dies mit hoher Wahrscheinlichkeit in seinem System hinterlegen müssen. Die Interoperabilität ist hier gerade gesunken, da nun plötzlich die Systeme zwischen verschiedenen Rechnungsempfängern unterscheiden müssen. Ein Beispiel hierfür ist die Diskussion, ob man eine Rechnungskorrektur mit der Dokumentenart 381 – Credit note versendet, oder als 380 – Invoice mit negativen Summen. Die Norm lässt hier explizit beide Möglichkeiten vor. So versenden zum Beispiel die Niederlande heute ausschließlich negative Rechnungen für diesen Zweck. In in vielen anderen Ländern ist dagegen die Credit Note üblich.

Wenn nun die Niederlande eine CIUS erstellen, die die entsprechende Codeliste derart beschränkt, dass keine Credit note – Instanzen mehr zulässig sind, ein anderer Mitgliedstaat jedoch die Verwendung der negativen Rechnung ausschließt, existiert keine Interoperabilität mehr. Beim Austausch von Rechnungen zwischen diesen beiden Ländern ist eine Konvertierung zwangsweise notwendig.

Bei der Definition der CIUS sieht darüber hinaus die Norm noch eine weitere mögliche Einschränkung vor, die die Interoperabilität vermindert. Das explizite Verbot, optionale Elemente zu senden. Die Nutzung dieser Möglichkeit bedeutet, dass zwangsweise für diese Empfängergruppe ein neuer Kanal für den Rechnungsversand entsteht und die Kosten der Umsetzung steigen.

Empfehlung zur Nutzung der CIUS

Die Grundidee der CIUS ist hervorragend. In der Praxis ermöglicht erst eine CIUS tatsächlich die automatisierte Verarbeitung von Rechnungen. Eine CIUS bietet die Möglichkeit, an zentraler Stelle zu definieren, welche Informationen eine Empfängergruppe für die automatisierte Verarbeitung benötigt. Insbesondere die Verwendung generischer Elemente zur technischen Übermittlung dieser Zuordnungswerte steigern die Interoperabilität enorm. In diesem Fall ist die technische Umsetzung von den fachlichen Anforderungen getrennt. Benötigt eine Empfängergruppe zum Beispiel die Angabe einer Kostenstelle, die zweite eine Leitwegs-ID und die dritte eine Transaktionsnummer, so müssen dafür nicht drei verschiedene technische Umsetzungen definiert werden. Alle drei Informationen könnten zum Beispiel im Feld BuyerReference übermittelt werden. Die fachliche Bedeutung definiert dann der Empfänger. Er übermittelt in der Regel – wie zum Beispiel beim Kassenzeichen – dem Rechnungssteller bereits bei der Bestellung zu anzugebende Information.

Die CIUS ermöglicht grundsätzlich auch eine weitere Möglichkeit, mit nicht benötigten Informationen umzugehen. Es gibt eine Alternative zum Verbot nicht benötigter optionaler Elemente. Definiert stattdessen eine CIUS klar und transparent, dass diese Informationen bei der Rechnungsprüfung und Verarbeitung ignoriert werden, schränkt dies die Interoperabilität nicht ein. Der Sender muss seine Software nicht mehr neu konfigurieren, sondern kann die gleiche Struktur an alle Rechnungsempfänger senden.

Ausblick für Umsetzer und Rechnungssteller

Wenn sich möglichst viele Spezifizierer einer CIUS an diesen Empfehlungen orientieren, wird die Komplexität der Implementierung deutlich reduziert. Eine Herausforderung verbleibt jedoch. In der Regel benötigt ein Rechnungsempfänger lediglich 20 bis 25 Informationen, um eine Rechnung automatisiert verarbeiten zu können: Etwa 15 Informationen für die (steuerlichen) Pflichtangaben, und den Rest in Abhängigkeit von den jeweiligen Rechnungsprozessen. Und genau diese Anforderungen ändern sich von Empfängergruppe zu Empfängergruppe. Zur einfacheren Umsetzung sollten diese jedoch nicht individuell, sondern möglichst in einem Verband, oder auf der Ebene des Landes definiert werden. Dennoch ist bereits heute absehbar, dass die Anzahl der CIUSen in Europa stark steigen wird. Ein zentraler Zugang zu solchen Informationen ist daher besonders wünschenswert.