Was ist EN 16931? Ein Leitfaden zum europäischen E-Rechnungsstandard

Lange Zeit bezeichnete »elektronische Rechnung« in Europa schlicht das, worauf sich der jeweilige Softwarehersteller festgelegt hatte. Ein französisches ERP erzeugte ein bestimmtes XML-Format, ein deutsches System ein anderes, eine italienische Plattform ein drittes. Wer grenzüberschreitend handelte, musste für jedes Format seiner Kunden eine eigene Schnittstelle pflegen — und die öffentliche Hand, verpflichtet zur Annahme von Rechnungen aus allen Quellen, trug die Hauptlast. Mit EN 16931, im Jahr 2017 vom Europäischen Komitee für Normung (CEN) veröffentlicht, wurde diese Zersplitterung beendet.

Ein semantisches Modell, kein Dateiformat

Die erste Überraschung an EN 16931 ist, dass die Norm gar kein Dateiformat festlegt. Sie definiert ein semantisches Datenmodell: rund 160 Geschäftsbegriffe mit Bezeichnungen wie »Buyer reference«, »VAT category code« oder »Item net price«, gegliedert in Geschäftsgruppen wie »Seller party« oder »VAT breakdown«. Die Norm schreibt vor, was eine Rechnung enthalten muss, um als gültiges Geschäftsdokument zu gelten; sie schweigt darüber, welche Bytes auf der Festplatte stehen.

Diese Trennung ist gewollt. Indem CEN das »Was« vom »Wie« trennte, konnte die Norm stabil bleiben, während sich die zugrunde liegenden Dateiformate unabhängig weiterentwickeln. Dieselbe Rechnung lässt sich folglich in zwei verschiedenen XML-Formaten ausdrücken und bleibt in jeder relevanten Hinsicht dieselbe Rechnung.

Die zwei Syntaxen: UBL und CII

Die Norm erkennt zwei XML-Syntaxen für die Übertragung an:

Beide sind XML, beide drücken dasselbe semantische Modell aus, beide sind EN 16931. Die Wahl zwischen ihnen ist im Wesentlichen eine Frage des Ökosystems, in dem sich Kunden und Steuerverwaltung bewegen. Einen echten technischen Vorteil bietet keines der beiden Formate für sich genommen; die Entscheidung ist politischer und historischer Natur.

Wer sich je gefragt hat, warum das europäische E-Rechnungswesen zwei konkurrierende XML-Formate für denselben Inhalt bereithält, findet hier die Antwort: zwei Standardisierungsgremien waren zuerst da, keines war bereit, seine Arbeit aufzugeben, und CEN hat beide anerkannt, statt einen Sieger zu küren. Eine eingehendere Gegenüberstellung der beiden findet sich in UBL gegen CII.

Nationale Anpassungen: das CIUS-Konzept

EN 16931 ist die europäische Grundnorm. Nationale Steuerbehörden dürfen darüber hinaus eigene Anforderungen formulieren — was die Norm als CIUS (»Core Invoice Usage Specification«) bezeichnet. Ein CIUS darf Felder verlangen, die EN 16931 freistellt, Codelisten auf eine nationale Teilmenge einschränken oder eigene fachliche Regeln hinzufügen. Was er nicht darf, ist abschwächen: jede CIUS-konforme Rechnung ist automatisch EN-16931-konform, der umgekehrte Schluss gilt nicht.

Die wichtigsten CIUSe sind heute:

Die meisten übrigen Mitgliedstaaten haben entweder einen eigenen CIUS veröffentlicht oder bereiten ihn vor — in der Regel auf Basis von PEPPOL BIS und nicht von Grund auf neu.

Validierung: die Schematron-Schicht

Was »EN-16931-Konformität« zu einer belastbaren Aussage macht, ist die Tatsache, dass die Norm ein maschinenlesbares Regelwerk mitbringt. Die Regeln sind in Schematron geschrieben — einem ISO-Standard zur Formulierung von Geschäftsregeln über XML-Dokumenten — und gliedern sich in mehrere Familien:

Jeder CIUS schichtet seine eigenen Regeln darüber. XRechnung fügt die BR-DE-*-Familie hinzu; PEPPOL ergänzt um PEPPOL-EN16931-*; der französische CIUS bringt BR-FR-* ein. Eine typische Rechnung wird gegen 200 bis 300 Regeln geprüft; insgesamt belaufen sich die uns bekannten Regeln aller CIUSe auf rund 2.000. Der vollständige Katalog steht in unserer Regel-Referenz.

Was Konformität leistet

Eine konforme Rechnung lässt sich von jeder EN-16931-fähigen Software:

Für Verkäufer bedeutet dies eine Rechnung, die beim Kundensystem im ersten Anlauf akzeptiert wird. Für Käufer kann die Kreditorenbuchhaltung die Standardfälle ohne Eingriff abwickeln. Für Steuerbehörden wird eine automatisierte Meldung möglich — und mehrere Mitgliedstaaten nutzen eben diese Eigenschaft bereits zur Vorausfüllung der Umsatzsteuererklärung.

Es lohnt, die Grenzen dieser Vorteile genau zu benennen. EN-16931-Konformität ist die notwendige Mindestbedingung dafür, dass diese Vorteile überhaupt eintreten können; sie ist für sich genommen nicht hinreichend. Eine wirkliche Automatisierung greift erst, wenn beide Seiten die Norm in ihre Systeme aufgenommen haben. Der praktische Beitrag der Norm besteht heute darin, eine Reibungsquelle — die Formataushandlung — zu beseitigen, damit die darüberliegenden Schichten (Übermittlung, Archivierung, Streitbeilegung) überhaupt bearbeitbar werden. Die hinreichenden Bedingungen liegen in jenen oberen Schichten und unterscheiden sich nach Land, Branche und vertraglichem Verhältnis.

Die Grenzen der Norm

Mehrere Bereiche fallen vollständig außerhalb von EN 16931:

Wer ein als »EN-16931-konform« beworbenes Produkt prüft, sollte daher die richtigen Fragen stellen: welche CIUSe es unterstützt, welche Übermittlungswege, was es zur Archivierung beiträgt und wie es mit den Lebenszyklus-Meldungen umgeht, die die zuständige Steuerbehörde verlangt.

Wie sich die Konformität feststellen lässt

Um zu wissen, ob eine Rechnung konform ist, schickt man sie durch einen Validator. Die Stärke der Norm — dass sie ausführbare Regeln mitbringt — bedeutet zugleich, dass für jede einzelne Datei ein definitives Ja oder Nein existiert. Es gibt kein Ermessen und kein »sieht ungefähr richtig aus«: das Schematron schlägt aus oder eben nicht.

Unser kostenloser Validator prüft jede UBL- oder CII-Rechnung gegen die EN-16931-Grundnorm und die wichtigsten CIUSe. Ein grüner Bericht heißt: die Datei wird von jedem konformen Empfangssystem akzeptiert. Ein roter Bericht nennt die Regel, die ausgelöst hat, die Stelle des Verstoßes und eine allgemeinverständliche Erklärung dessen, was zu beheben ist.