EN 16931: Die europäische E-Rechnungsnorm erklärt

EN 16931 ist die europäische Norm, die festlegt, was eine elektronische Rechnung enthält: ein semantisches Datenmodell aus Geschäftsbegriffen, ihrer Bedeutung, ihrer Kardinalität und den Regeln zwischen ihnen. Sie ist kein Dateiformat. Zwei XML-Syntaxen tragen das Modell — UBL 2.1 und UN/CEFACT Cross Industry Invoice — und nationale oder branchenspezifische Spezifikationen wie XRechnung, ZUGFeRD, Factur-X und Peppol BIS Billing 3.0 schränken es ein oder erweitern es. Öffentliche Auftraggeber in der EU müssen EN-16931-Rechnungen annehmen; Deutschland, Frankreich und Belgien haben ihre B2B-Pflichten darauf aufgebaut.

Warum es EN 16931 gibt

EN 16931 gibt es, weil die Richtlinie 2014/55/EU eine einheitliche europäische Norm verlangte, die die inkompatiblen nationalen E-Rechnungsformate ablösen sollte, welche die öffentliche Auftragsvergabe zersplitterten. Die Richtlinie verlangte, dass die Norm technologieneutral, mit internationalen Normen kompatibel, für KMU praktikabel und im B2B-Handel nutzbar ist und mit einer „begrenzten Zahl von Syntaxen" einhergeht.

CEN/TC 434 lieferte sie 2017. Die Kommission veröffentlichte die Fundstelle der EN 16931-1:2017 und die Syntaxliste am 17. Oktober 2017 im Amtsblatt (Durchführungsbeschluss (EU) 2017/1870), womit die Frist für die B2G-Empfangspflicht zu laufen begann. Seitdem ist die Norm zum gemeinsamen Nenner der europäischen E-Rechnung geworden: Das deutsche Umsatzsteuergesetz definiert die E-Rechnung durch Verweis auf sie, die in Frankreich zugelassenen Formate sind EN-16931-Syntaxen, und das belgische Standardformat ist eine EN-16931-CIUS. Den EU-Kontext beschreibt die Seite EU-Anforderungen.

Die Teile der Norm

EN 16931 ist eine Dokumentenfamilie: ein normativer Teil mit dem semantischen Modell, eine technische Spezifikation mit der Syntaxliste sowie ergänzende Bindungen und Berichte.

Nur die Teile 1 und 2 sind kostenlos, aufgrund der Lizenzvereinbarung zwischen der Kommission und CEN. Alles, was ein Implementierer für die Validierung braucht, ist jedoch öffentlich: Die Schematron-Artefakte werden vom eInvoicing-Team der Kommission auf GitHub veröffentlicht.

Das semantische Modell: Geschäftsbegriffe und Gruppen

Das semantische Modell listet jedes Informationselement auf, das eine Rechnung tragen kann, nummeriert als Geschäftsbegriffe (Business Terms, BT) und zusammengefasst in Gruppen (Business Groups, BG), mit einer Kardinalität, die angibt, ob das Element verpflichtend, optional oder wiederholbar ist.

Beispiele dafür, was das Modell abdeckt:

• Dokumentebene: Rechnungsnummer, Rechnungsdatum, Rechnungstypcode, Währung, Käuferreferenz, Fälligkeitsdatum, Verweis auf die Vorgängerrechnung bei Gutschriften und Korrekturen.
• Parteien: Verkäufer und Käufer mit Name, Adresse, USt-IdNr., Handelsregisterkennung und elektronischer Adresse; optional Zahlungsempfänger und Steuervertreter.
• Lieferung und Zahlung: Lieferdatum und -adresse, Zahlungsmittel (Überweisung, Lastschrift, Karte), Zahlungsbedingungen, Bankverbindung.
• Nachlässe und Zuschläge auf Dokument- und Positionsebene, jeweils mit Umsatzsteuerkategorie.
• Umsatzsteueraufschlüsselung: eine Gruppe je Umsatzsteuerkategorie und -satz, mit Bemessungsgrundlage, Steuerbetrag und, wo der Satz null ist oder fehlt, einem Befreiungsgrund.
• Summen: Summe der Positionsnettobeträge, Nachlässe, Zuschläge, Gesamtbetrag ohne Umsatzsteuer, Gesamtumsatzsteuer, Gesamtbetrag mit Umsatzsteuer, Vorauszahlung, Zahlbetrag.
• Positionen: Menge, Einheit, Nettopreis, Positionsnettobetrag, Umsatzsteuerkategorie, Artikelkennungen und -klassifikation.

Das Modell ist bewusst ein „Kern": Es enthält, was die Mehrheit europäischer Rechnungen für Umsatzsteuer- und Zahlungszwecke braucht, nicht jedes Feld, das eine Branche sich wünschen könnte. Weitergehende Bedürfnisse werden über Erweiterungen abgedeckt, wie unten beschrieben. Eine Entwicklerdarstellung der Elemente mit Anfragebeispielen enthält der EN-16931-Entwicklerleitfaden.

Syntaxen: UBL 2.1 und UN/CEFACT CII

Das semantische Modell wird von zwei XML-Syntaxen getragen, die in CEN/TS 16931-2 gelistet und im Amtsblatt veröffentlicht sind: OASIS UBL 2.1 (ISO/IEC 19845:2015) und UN/CEFACT Cross Industry Invoice (CII) D16B. Eine UN/EDIFACT-Bindung existiert als Teil 3-4, steht aber nicht in der veröffentlichten Liste.

Beide Syntaxen drücken dieselben Geschäftsbegriffe aus, sodass eine EN-16931-Rechnung in beiden ohne Verlust des Kerninhalts dargestellt werden kann. Welche Ihnen begegnet, hängt vom Ökosystem ab:

Ein empfangendes System, das EN-16931-Unterstützung für sich beansprucht, sollte beide Syntaxen annehmen; in der Praxis engen viele nationale Kanäle die Wahl ein. Peppol verlangt UBL. ZUGFeRD und Factur-X betten CII ein. Der Formatleitfaden listet auf, was jedes Land erwartet.

CIUS und Erweiterungen: Wie Länder den Kern anpassen

Eine CIUS (Core Invoice Usage Specification) engt EN 16931 ein — sie kann optionale Elemente verpflichtend machen, Codelisten einschränken oder Regeln hinzufügen —, fügt aber nie Elemente hinzu, sodass jede CIUS-Rechnung weiterhin eine gültige EN-16931-Rechnung ist. Eine Erweiterung fügt Elemente hinzu und ist daher für einen Empfänger, der nur den Kern kennt, nicht automatisch gültig.

XRechnung (Deutschland)

Eine von der KoSIT gepflegte CIUS für öffentliche Auftraggeber, in UBL oder CII, mit Käuferreferenz (Leitweg-ID) und nationalen Codelistenregeln. Version 3.0.2 ist seit dem 1. Februar 2024 in Kraft und wird durch Bugfix-Bundles aktuell gehalten, zuletzt die Ausgabe „Winter 2025/26" mit Wirkung zum 31. Januar 2026. XRechnung definiert außerdem einen Erweiterungsmechanismus. Siehe XRechnung.

Peppol BIS Billing 3.0

Die CIUS von OpenPeppol, UBL verpflichtend, identifiziert durch die Customization-ID urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, mit Regeln mit dem Präfix PEPPOL-EN16931-R und zusätzlichen länderspezifischen Regeln. Aktuelles Release 3.0.21 (Mai 2026). Siehe Peppol.

ZUGFeRD / Factur-X

Das deutsch-französische Hybridformat definiert Profile: MINIMUM und BASIC WL tragen weniger als den Kern und sind für sich genommen nicht EN-16931-konform; BASIC ist eine Teilmenge; EN 16931 ist der vollständige Kern; EXTENDED geht darüber hinaus. Version 2.5.2 (Factur-X 1.09.2) wurde am 4. August 2026 veröffentlicht und gilt ab 1. September 2026, basierend auf CII D22B mit Abwärtskompatibilität zu D16B. Siehe ZUGFeRD und Factur-X.

Jede CIUS und jede Erweiterung kündigt sich in der Rechnung selbst an: Die Customization-ID (BT-24) sagt, welcher Spezifikation die Datei folgt, und die Profil-ID (BT-23) benennt den Geschäftsprozess. Ein Empfänger liest diese beiden Werte, bevor er ein Regelwerk wählt.

Geschäftsregeln und Validierung

Eine EN-16931-Rechnung ist gültig, wenn sie das Schema ihrer Syntax und die als Schematron ausgedrückten Geschäftsregeln des semantischen Modells besteht. Die Regeln sind der Teil, der Fehler aus der Praxis auffängt: Summen, die nicht aufgehen, eine Umsatzsteueraufschlüsselung, der eine Kategorie fehlt, eine fehlende USt-IdNr. des Verkäufers, wo eine erforderlich ist.

Das eInvoicing-Team der Kommission veröffentlicht die Validierungsartefakte für UBL und CII auf GitHub (ConnectingEurope/eInvoicing-EN16931); das neueste Release ist 1.3.16 vom 10. April 2026, mit einem etwa halbjährlichen Rhythmus. Regelkennungen folgen einem Muster:

• BR-xx — allgemeine Regeln zu Vorhandensein und Struktur (eine Rechnung muss eine Nummer, ein Rechnungsdatum, einen Verkäufernamen haben, …).
• BR-CO-xx — Berechnungs- und Konsistenzregeln, zum Beispiel dass der Rechnungsgesamtbetrag der Summe der Positionsnettobeträge plus Zuschläge minus Nachlässe entspricht.
• BR-S-, BR-Z-, BR-E-, BR-AE-, BR-IC-, BR-G-, BR-O-, BR-IG-, BR-IP- — Regeln je Umsatzsteuerkategorie: Regelsatz, Nullsatz, steuerfrei, Reverse Charge, innergemeinschaftlich, Ausfuhr, nicht steuerbar sowie die Steuern der Kanarischen Inseln und von Ceuta/Melilla.
• BR-CL-xx — Codelistenregeln (Währungscodes, Einheitencodes, Umsatzsteuerkategoriecodes, Ländercodes).

Nationale Spezifikationen legen eigene Regelwerke darüber: Die KoSIT veröffentlicht ein XRechnung-Schematron und einen konfigurierbaren Validator, OpenPeppol veröffentlicht die Peppol-Regeln. Eine Datei muss daher bis zu drei Ebenen bestehen — Schema, EN-16931-Kern, nationale CIUS —, und jede Ebene meldet ihre eigenen Kennungen. Der kostenlose E-Rechnungsprüfer lässt eine Datei durch die Regeln des gewählten Landes laufen, ohne sie zu speichern.

Versionen: 2017, A1:2019 und die Ausgabe 2026

Die für den größten Teil des letzten Jahrzehnts geltende Ausgabe ist EN 16931-1:2017 mit ihrer Änderung A1:2019. Laut Kommission wurde im Mai 2026 eine neue Ausgabe, EN 16931-1:2026, veröffentlicht; die Ausgabe 2017 wurde formal zurückgezogen, bleibt aber während einer Übergangsfrist konform, und Migrationspläne werden von den zuständigen Organisationen und Behörden der Mitgliedstaaten erarbeitet.

Was das heute für Implementierer bedeutet: Die im Umlauf befindlichen Customization-IDs verweisen weiterhin auf urn:cen.eu:en16931:2017, und die Validierungsartefakte, XRechnung und Peppol BIS arbeiten alle weiterhin gegen das Modell von 2017. FeRD weist darauf hin, dass das EXTENDED-Profil von ZUGFeRD 2.5.2 bereits zusätzliche Elemente „für die französische B2B-E-Rechnungsreform und das überarbeitete EN-16931-Datenmodell" trägt. Rechnen Sie damit, dass die nationalen Spezifikationen eigene Migrationstermine veröffentlichen; bis dahin ist das Modell von 2017 das, wogegen Empfänger validieren.

Wie KRONENWERK damit umgeht

KRONENWERK erzeugt EN-16931-Rechnungen in der Syntax und CIUS, die das Land des Käufers erwartet, und validiert sie gegen die anwendbaren Regelebenen, bevor die Rechnung ausgestellt wird.

• Deutschland — XRechnung (UBL oder CII) und ZUGFeRD, validiert mit den KoSIT-Schematron-Regeln und gegengeprüft mit der Mustang-Bibliothek: Unterstützt.
• Frankreich — Factur-X als PDF/A-3 mit eingebettetem CII: Erzeugung Unterstützt; Übermittlung über eine zugelassene Plattform Noch nicht bereit.
• Belgien — Peppol BIS Billing 3.0 UBL: Mit Einschränkungen unterstützt, gesendet und empfangen über einen akkreditierten Access-Point-Anbieter (Storecove), sobald das Unternehmen unter Einstellungen → Zustellung angebunden ist.
• Empfang — eingehende XRechnung-, ZUGFeRD-/Factur-X- und UBL-Dateien werden als Eingangsrechnungen eingelesen: Unterstützt.

Die Umsatzsteuerkategorie auf jeder Position und in der Umsatzsteueraufschlüsselung stammt aus dem Steuerbefund der Rechnung (Regelsatz, Nullsatz, steuerfrei, Reverse Charge, nicht steuerbar), der aus den Fakten des Geschäftsvorfalls abgeleitet und nie geraten wird; wo ein Fachmann entscheiden müsste, wird die Rechnung mit „erfordert fachliche Bestätigung" zurückgehalten. Das polnische FA(3) ist ein nationales Schema außerhalb von EN 16931 und wird auf der FA(3)-Seite behandelt. Entwickler können Entwürfe über die E-Rechnungs-API anlegen; die Produktübersicht steht auf der E-Rechnungsseite. Zurück zur Europa-Übersicht.

Häufige Fragen

Ist EN 16931 ein Dateiformat?

Nein. Es ist ein semantisches Modell — eine Liste von Geschäftsbegriffen und Regeln. Die Dateiformate sind die Syntaxen, die es tragen, UBL 2.1 und UN/CEFACT CII, sowie die darauf aufbauenden Spezifikationen wie XRechnung, ZUGFeRD, Factur-X und Peppol BIS.

Ist eine ZUGFeRD-Rechnung EN-16931-konform?

Die Profile EN 16931 und EXTENDED tragen den vollständigen Kern; BASIC ist eine Teilmenge, die gegen die Kernregeln validiert; MINIMUM und BASIC WL tragen weniger als den Kern und sind für sich genommen keine konformen EN-16931-Rechnungen.

Was ist der Unterschied zwischen einer CIUS und einer Erweiterung?

Eine CIUS schränkt den Kern ein (mehr Pflichtelemente, engere Codelisten) und bleibt für jeden EN-16931-Empfänger gültig. Eine Erweiterung fügt Elemente hinzu und braucht einen Empfänger, der sie versteht.

Wo bekomme ich die Validierungsregeln?

Die Schematron-Artefakte der Kommission für UBL und CII sind öffentlich auf GitHub (ConnectingEurope/eInvoicing-EN16931). Die KoSIT veröffentlicht die XRechnung-Regeln und den Validator; OpenPeppol veröffentlicht die Peppol-BIS-Regeln.

Muss ich jetzt auf EN 16931-1:2026 migrieren?

Nicht am 3. September 2026. Die Kommission erklärt, dass die Ausgabe 2017 während einer Übergangsfrist konform bleibt und die Pläne noch erarbeitet werden. Verfolgen Sie die Ankündigungen von KoSIT, OpenPeppol, FeRD/FNFE und Ihrer nationalen Behörde.