Wer sich mit E-Rechnungen beschäftigt, stolpert früher oder später über die Bezeichnung EN 16931. Klingt sperrig, ist aber der Kern des europäischen E-Rechnungssystems. Ohne diese Norm würde jedes Land sein eigenes Format kochen — die Folge wäre Chaos im grenzüberschreitenden Rechnungsverkehr.
Dieser Artikel erklärt tech-präzise, was die Norm definiert, wie sie aufgebaut ist und warum sie für jedes Tool relevant ist, das in Europa Rechnungen elektronisch versendet. Wir gehen das semantische Datenmodell durch, die Syntax-Bindings (UBL 2.1 und UN/CEFACT CII), klären CIUS und Extensions und ordnen die deutsche Umsetzung (XRechnung, ZUGFeRD, KoSIT) ein.
Historie: Von der Richtlinie 2014/55/EU zur EN 16931:2017
Alles begann mit der Richtlinie 2014/55/EU über die elektronische Rechnungsstellung bei öffentlichen Aufträgen. Darin legte das Europäische Parlament fest, dass öffentliche Auftraggeber in der EU elektronische Rechnungen entgegennehmen und verarbeiten müssen. Damit das interoperabel funktioniert, brauchte man ein gemeinsames semantisches Modell. Oder zumindest gemeinsame Regeln dafür, wie eine E-Rechnung inhaltlich aufgebaut sein muss.
Das Europäische Komitee für Normung (CEN) bekam vom Mandat M/528 den Auftrag, einen solchen Standard zu entwickeln. Zuständig war das technische Komitee CEN/TC 434. Das Ergebnis: EN 16931-1:2017 für das semantische Datenmodell und CEN/TS 16931-2:2017 für die Liste der zulässigen Syntaxen. Seitdem bildet diese Norm das Fundament für E-Rechnungen in der gesamten EU.
Versionsverlauf der Norm
- 2014: Richtlinie 2014/55/EU tritt in Kraft
- 2017: Erstveröffentlichung von EN 16931-1 und CEN/TS 16931-2
- 2018: Pflicht für oberste EU-Behörden, E-Rechnungen anzunehmen
- 2020: Pflicht für alle öffentlichen Auftraggeber in der EU
- 2024–2025: Revision der Norm (EN 16931-1:2024 ersetzt die Fassung von 2017)
- 2025: Start der deutschen B2B-E-Rechnungspflicht (Wachstumschancengesetz)
- 2027/2028: Vollumfänglicher B2B-Versandzwang in Deutschland
Deutschland hat die Richtlinie zunächst für den öffentlichen Sektor umgesetzt — siehe dazu den Leitfaden E-Rechnung an Behörden senden. Mit dem Wachstumschancengesetz wurde die Pflicht ab 2025 auf den B2B-Bereich ausgeweitet. Details dazu findest du in E-Rechnungspflicht 2025–2027 und B2B-E-Rechnungspflicht: Anleitung. Das gemeinsame Referenzformat ist und bleibt: EN 16931.
Was definiert EN 16931 technisch?
Die Norm besteht im Kern aus zwei Teilen. Der erste Teil beschreibt ein semantisches Datenmodell. Der zweite Teil legt die Syntax-Bindings fest. Dazu kommen Schematron-Regeln, Codelisten und ein methodischer Rahmen für CIUS und Extensions. Klingt technisch, ist aber nachvollziehbar, wenn man es aufschlüsselt.
Das semantische Datenmodell (EN 16931-1)
Teil 1 der Norm definiert, welche Informationen eine E-Rechnung enthalten muss. Nicht mehr, nicht weniger. Es geht um die Bedeutung der Daten, nicht um das technische Format. Das Modell ist syntax-agnostisch — es lebt unabhängig davon, ob die Rechnung später als UBL oder als CII serialisiert wird.
Das Datenmodell umfasst rund 160 einzelne Geschäftsbegriffe (Business Terms, BT-1 bis BT-XXX) und ca. 30 Geschäftsgruppen (Business Groups, BG-XX). Jeder Begriff hat eine eindeutige ID, einen Namen, eine Datentyp-Definition und eine Kardinalität (Pflicht / optional, einmalig / wiederholbar).
EN 16931 Pflichtfelder: Die wichtigsten Business Terms
Eine konforme EN-16931-Rechnung enthält mindestens diese Pflichtelemente (Auswahl):
- BT-1: Rechnungsnummer (Invoice number)
- BT-2: Rechnungsdatum (Invoice issue date)
- BT-3: Rechnungstyp-Code (z. B. 380 für Handelsrechnung, 381 für Gutschrift)
- BT-5: Rechnungswährungscode (ISO 4217, z. B. EUR)
- BT-6: Steuerwährungscode (falls abweichend)
- BT-9: Fälligkeitsdatum
- BT-10: Käufer-Referenz / Leitweg-ID (in XRechnung Pflicht)
- BT-22: Freitext-Bemerkungen
- BT-27 / BT-29: Name und USt-ID des Verkäufers
- BT-44 / BT-48: Name und USt-ID des Käufers
- BT-106: Summe der Nettobeträge
- BT-109: Rechnungsbetrag ohne Umsatzsteuer
- BT-110: Umsatzsteuerbetrag gesamt
- BT-112: Bruttogesamtbetrag
- BT-115: Zahlbetrag (nach Skonto / Anzahlung)
Dazu kommen Pflichtangaben pro Position (BG-25 mit BT-126 bis BT-149) wie Artikelname, Menge, Einzelpreis, Steuersatz. Die komplette Liste deutscher Pflichtangaben findest du in unserer Pflichtangaben-Checkliste. Manche dieser Felder sind in der Norm Pflicht, andere optional. Die jeweilige CIUS (z. B. XRechnung) kann optionale Felder zur Pflicht aufwerten.
Die Norm legt außerdem fest, welche Datentypen erlaubt sind und welche Codelisten verwendet werden müssen. Zum Beispiel gibt es feste Codes für Steuerkategorien (UNCL5305), Mengeneinheiten (UN/ECE Rec. 20), Währungen (ISO 4217) und Länder (ISO 3166). Diese Codelisten sind versioniert und werden mit jedem Norm-Update aktualisiert.
Die Syntax-Bindings (CEN/TS 16931-2)
Teil 2 der Norm definiert zwei zulässige XML-Syntaxen, in denen das semantische Modell serialisiert werden darf:
- UBL 2.1 (Universal Business Language) nach OASIS / ISO/IEC 19845
- UN/CEFACT CII (Cross Industry Invoice) nach UN/CEFACT XML-Schema, Version 16B / D16B
Beide Syntaxen können das semantische Datenmodell aus Teil 1 vollständig abbilden. Sie sind gleichwertig. Die Wahl hängt davon ab, welches Format in deinem Kontext gefordert wird und welche Tools deine Empfänger nutzen.
In Deutschland sieht das so aus: XRechnung basiert auf UBL 2.1, ZUGFeRD nutzt UN/CEFACT CII. Beides ist EN-16931-konform. Den direkten Vergleich findest du in XRechnung vs. ZUGFeRD.
CIUS: Core Invoice Usage Specification
CIUS steht für Core Invoice Usage Specification. Auf Deutsch: eine länderspezifische oder branchenspezifische Anpassung des EN-16931-Datenmodells. Die Norm erlaubt es Mitgliedstaaten und Branchen, zusätzliche Regeln über Schematron-Constraints zu definieren. Wichtig: Diese Regeln dürfen das Datenmodell einschränken, aber nicht erweitern.
Das bedeutet konkret: Eine CIUS kann Felder, die in EN 16931 optional sind, zur Pflicht machen. Sie kann zusätzliche Geschäftsregeln vorgeben (z. B. "Wenn BT-X gesetzt ist, muss BT-Y vorhanden sein"). Sie kann keine neuen Datenfelder hinzufügen, die es im Core-Modell nicht gibt.
XRechnung als deutsche CIUS
XRechnung ist die deutsche CIUS, entwickelt und gepflegt von der KoSIT (Koordinierungsstelle für IT-Standards) im Auftrag des IT-Planungsrats. Sie nimmt das EN-16931-Datenmodell und fügt spezifische Anforderungen hinzu — etwa die Pflicht zur Leitweg-ID (BT-10) bei Rechnungen an öffentliche Auftraggeber, oder die Pflicht zur Angabe von Bankverbindung und E-Mail-Adresse des Verkäufers. In der reinen EN 16931 wäre die Leitweg-ID nur eine optionale Käuferreferenz.
Andere nationale CIUS-Varianten
- Italien: FatturaPA (auf CII-Basis, durchläuft das SdI-System)
- Frankreich: Factur-X (entspricht technisch ZUGFeRD)
- Niederlande: NLCIUS (UBL-basiert, eng an PEPPOL angelehnt)
- Schweden / Dänemark / Norwegen: PEPPOL BIS Billing 3.0 als de-facto-CIUS
Alle bauen auf EN 16931 auf, alle sind untereinander grundsätzlich kompatibel. Das CIUS-Konzept ist clever, weil es nationale Besonderheiten erlaubt, ohne den gemeinsamen Kern aufzubrechen. Eine französische Factur-X und eine deutsche XRechnung teilen sich dasselbe Fundament. Die Unterschiede liegen in zusätzlichen Pflichtfeldern und Geschäftsregeln, nicht in der Grundstruktur.
Extensions: Wenn der Core nicht ausreicht
Manche Branchen oder Anwendungsfälle brauchen Datenfelder, die im EN-16931-Core schlicht nicht vorgesehen sind — etwa detaillierte Logistikinformationen, branchenspezifische Konditionen oder Zusatzdaten für Forwarding-Szenarien. Hier kommen Extensions ins Spiel.
Eine Extension erweitert das Datenmodell um zusätzliche Elemente, die nicht im Core enthalten sind. Im Gegensatz zur CIUS, die nur einschränken darf, fügt eine Extension neue Strukturen hinzu. Eine Extension-Rechnung ist nicht mehr "puristisch" EN-16931-konform im engsten Sinne — Empfänger müssen die Erweiterung kennen, um die Zusatzdaten zu verarbeiten.
Bekanntestes Beispiel im deutschen Raum: das ZUGFeRD-Profil EXTENDED. Es geht über den EN-16931-Core hinaus und enthält z. B. tiefere Strukturen für Logistik, Lieferketten und Mahnwesen. Wer mit dem EXTENDED-Profil arbeitet, sollte sicher sein, dass sein Gegenüber diese Felder auswerten kann — sonst landen sie als Beiwerk im PDF/A-3-Anhang, ohne maschinell verarbeitet zu werden.
XRechnung und EN 16931 im Detail
XRechnung ist die offizielle deutsche Umsetzung der Norm. Entwickelt und gepflegt von der KoSIT, technisch federführend in Bremen. Das Format wird regelmäßig aktualisiert; die aktuelle Version ist 3.0.x mit jährlichen Minor-Releases.
Technisch ist XRechnung eine UBL-2.1-basierte XML-Datei. Kein PDF, keine visuelle Darstellung. Reine strukturierte Daten. Das macht die Verarbeitung durch Software extrem effizient — für Menschen ohne Viewer aber unlesbar. XRechnung ist Pflicht bei Rechnungen an Bundesbehörden und die meisten Landesbehörden. Im B2B-Bereich ist es eines von zwei gängigen Formaten neben ZUGFeRD.
Die wichtigsten Pflichtfelder, die XRechnung-CIUS gegenüber dem EN-16931-Core verschärft:
- Leitweg-ID (BT-10) bei öffentlichen Auftraggebern
- Bankverbindung des Rechnungsstellers (BG-17)
- E-Mail-Adresse des Verkäufers (BT-34)
- Mehrere zusätzliche Schematron-Regeln für deutsche Steuerlogik
SimplyBills implementiert XRechnung exakt nach KoSIT-Spezifikation. Eine ausführliche Schritt-für-Schritt-Anleitung findest du unter XRechnung erstellen — Anleitung. Mit unserem Tool kannst du direkt unter Rechnung erstellen loslegen.
ZUGFeRD und EN 16931 im Detail
ZUGFeRD verfolgt einen anderen Ansatz. Statt reinem XML kombiniert es ein PDF/A-3-Dokument mit eingebetteter XML-Datei. Du bekommst also beides: eine visuell lesbare Rechnung und die maschinenlesbaren Daten. Ab Version 2.0 basiert das XML auf der CII-Syntax von UN/CEFACT und ist damit grundsätzlich EN-16931-konform — abhängig vom gewählten Profil.
Wichtig: Nicht alle ZUGFeRD-Profile sind EN-16931-konform. Die niedrigeren Profile (Minimum, Basic WL, Basic) erfüllen die Norm nicht vollständig und reichen ab 2028 für die deutsche B2B-Pflicht nicht aus.
| ZUGFeRD-Profil | EN-16931-konform? | Geeignet für B2B-Pflicht? |
|---|---|---|
| Minimum | Nein | Nein |
| Basic WL | Nein | Nein |
| Basic | Nein | Nein |
| EN 16931 (Comfort) | Ja | Ja |
| XRechnung | Ja | Ja |
| Extended | Ja (Superset / Extension) | Ja |
Für die meisten Unternehmen ist ZUGFeRD im Profil "EN 16931" oder "XRechnung" die beste Wahl. Du hast eine PDF-Ansicht für den Menschen und strukturierte Daten für die Maschine. Eine vollständige Anleitung findest du unter ZUGFeRD-Rechnung erstellen. Wenn du noch klassische PDFs hast, hilft dir der KI-Scan beim Umwandeln von PDF in E-Rechnung.
EN 16931 europaweit: PEPPOL BIS Billing 3.0
PEPPOL (Pan-European Public Procurement OnLine) ist ein offenes Netzwerk für den Austausch von Geschäftsdokumenten. Es nutzt EN 16931 als inhaltlichen Standard und definiert zusätzlich, wie E-Rechnungen technisch übermittelt werden. Während EN 16931 sagt, was in einer Rechnung stehen muss, regelt PEPPOL den sicheren Transport von Absender zu Empfänger über sogenannte Access Points (AS4-Protokoll).
Die wichtigste PEPPOL-Spezifikation für Rechnungen heißt PEPPOL BIS Billing 3.0. Sie ist im Kern eine internationale CIUS auf Basis von UBL 2.1 und EN 16931 und gilt in den nordischen Ländern, Benelux, UK und zunehmend auch in Mittel- und Südeuropa als Quasi-Standard.
In Deutschland gewinnt PEPPOL zunehmend an Bedeutung. Viele Behörden akzeptieren E-Rechnungen über das PEPPOL-Netzwerk, einige stellen es sogar als bevorzugten Kanal heraus. Im B2B-Bereich wird es ebenfalls populärer, weil der Versand automatisiert und nachvollziehbar abläuft. Wer EN-16931-konforme Rechnungen erstellt, kann diese ohne inhaltliche Anpassungen über PEPPOL versenden — nur das Transport-Envelope (SBDH / ASIC-E) kommt drumherum.
Die Kombination aus EN 16931 (Inhalt) + PEPPOL (Transport) bildet das Rückgrat des europäischen E-Rechnungsverkehrs. Andere Übertragungswege (E-Mail, Portale, EDIFACT-Konverter) sind möglich, aber PEPPOL hat sich als europäischer De-facto-Standard etabliert.
Validierung und Konformität
Ein großer Vorteil der Norm: Es gibt klare, automatisiert prüfbare Regeln, ob eine E-Rechnung konform ist oder nicht. Die KoSIT stellt einen Open-Source-Validator bereit, der genau das prüft. Du lädst eine XML-Datei hoch, und das Tool sagt dir auf drei Ebenen, ob alles passt.
Die drei Validierungsebenen
- XML-Schema-Konformität: Stimmt die XML-Struktur formal? Sind alle Elemente an der richtigen Stelle, sind die Datentypen korrekt?
- Schematron-Regeln: Sind die Geschäftsregeln der EN 16931 (und ggf. der CIUS) eingehalten? Beispiel: "Wenn ein Steuersatz von 0% angegeben ist, muss ein Befreiungsgrund vorhanden sein."
- Codelisten: Sind alle verwendeten Codes gültig (Steuerkategorie, Währung, Mengeneinheit, Land)?
Wer alle drei Ebenen besteht, kann die Rechnung bedenkenlos versenden. Das klingt nach Bürokratie, ist aber in Wirklichkeit eine massive Erleichterung. Vor der Normierung konnte jeder Empfänger eigene Anforderungen stellen. Jetzt gibt es einen einheitlichen Maßstab. Wenn deine Rechnung den Validator besteht, wird sie vom Empfänger akzeptiert. Kein Rätselraten, kein Hin und Her.
EN 16931 in der Tool-Praxis: SimplyBills
Für den Alltag musst du die Norm nicht im Detail kennen. Wichtig ist, dass dein E-Rechnungstool die Arbeit übernimmt. SimplyBills implementiert das EN-16931-Datenmodell vollständig — XML-Output erfolgt wahlweise als XRechnung-CIUS (UBL 2.1) oder als ZUGFeRD-PDF/A-3 (CII) im Profil "EN 16931" bzw. "XRechnung". Beide Outputs durchlaufen intern eine Schematron-Validierung gegen die aktuellen KoSIT-Regeln, bevor sie ausgeliefert werden.
Du wählst das gewünschte Format, trägst deine Rechnungsdaten ein, und die Software kümmert sich um die korrekte XML-Struktur, die richtigen Codelisten, die Pflichtfelder und die Geschäftsregeln. Wenn etwas fehlt — etwa die Leitweg-ID bei einer Behördenrechnung — bekommst du im UI eine sofortige Warnung, lange bevor die Datei den Empfänger erreicht. Alle Details zu Formaten, Validierung und Workflows findest du unter Funktionen.
Was du wissen solltest: Achte bei der Wahl deines Tools darauf, dass es regelmäßig aktualisiert wird. Die Norm und die nationalen CIUS werden weiterentwickelt — XRechnung bekommt mindestens einmal jährlich ein Update, EN 16931 selbst alle paar Jahre eine Revision. Dein Tool muss diese Änderungen zeitnah umsetzen, sonst sind deine Rechnungen formell veraltet.
Warum sollte dich das interessieren?
EN 16931 hat direkte Auswirkungen auf deinen Geschäftsalltag:
Formatwahl: Wenn du eine E-Rechnungslösung auswählst, muss sie EN 16931 unterstützen. Alles andere ist ab 2028 nicht mehr rechtskonform für B2B — siehe B2B-E-Rechnungspflicht.
Interoperabilität: Weil ganz Europa auf denselben Standard setzt, kannst du mit dem gleichen Format an Kunden in Deutschland, Frankreich oder den Niederlanden fakturieren.
Validierung: Eine E-Rechnung ist entweder EN-16931-konform oder nicht. Fehler fallen vor dem Versand auf, nicht erst beim Empfänger.
Zukunftssicherheit: Welche nationalen Regelungen auch kommen — sie bauen auf EN 16931 auf. Wer heute konform arbeitet, ist für die nächsten Jahre gut aufgestellt.
Häufige Missverständnisse
"EN 16931 ist ein Dateiformat." Nicht ganz. Die Norm beschreibt ein semantisches Datenmodell und erlaubt zwei Syntaxen (UBL 2.1 und UN/CEFACT CII). Das konkrete Dateiformat ergibt sich aus der Syntax plus der jeweiligen CIUS.
"Meine E-Rechnung ist automatisch konform, wenn sie XML ist." Nein. Es muss eine der beiden erlaubten Syntaxen sein, die Pflichtfelder müssen korrekt befüllt und die Schematron-Regeln eingehalten sein. Ein beliebiges XML reicht nicht.
"ZUGFeRD und XRechnung sind Konkurrenten." Eher Geschwister. Beide implementieren EN 16931, nur mit unterschiedlicher Syntax und unterschiedlichem Ansatz (PDF+XML vs. reines XML). Seit ZUGFeRD 2.0 gibt es sogar ein XRechnung-Profil innerhalb von ZUGFeRD. Vergleich: XRechnung vs. ZUGFeRD.
FAQ — Häufige Fragen zu EN 16931
Was ist EN 16931?
EN 16931 ist die europäische Norm für elektronische Rechnungen. Sie wurde 2017 vom Europäischen Komitee für Normung (CEN) auf Basis der Richtlinie 2014/55/EU veröffentlicht und definiert ein syntaxunabhängiges semantisches Datenmodell für E-Rechnungen sowie zwei zulässige XML-Bindings (UBL 2.1 und UN/CEFACT CII). XRechnung und ZUGFeRD bauen auf EN 16931 auf.
Welche Pflichtfelder schreibt EN 16931 vor?
Pflicht sind unter anderem Rechnungsnummer (BT-1), Rechnungsdatum (BT-2), Rechnungstyp (BT-3), Währung (BT-5), Name und USt-ID von Verkäufer (BT-27/BT-29) und Käufer (BT-44/BT-48), Nettosumme (BT-106), Steuerbetrag (BT-110), Bruttosumme (BT-112) und Zahlbetrag (BT-115). Pro Position kommen Artikelname, Menge, Einzelpreis und Steuersatz dazu. CIUS wie XRechnung können weitere Felder zur Pflicht aufwerten — etwa die Leitweg-ID (BT-10) bei Behördenrechnungen.
EN 16931 vs. XRechnung vs. ZUGFeRD — was ist der Unterschied?
EN 16931 ist die übergeordnete europäische Norm. XRechnung ist die deutsche CIUS auf Basis von UBL 2.1 und reines XML. ZUGFeRD ist ein hybrides Format aus PDF/A-3 + eingebettetem CII-XML. Sowohl XRechnung als auch ZUGFeRD (ab Profil "EN 16931") sind EN-16931-konform — sie unterscheiden sich nur in Syntax und Trägerformat.
Welche Syntaxen erlaubt EN 16931 — UBL vs. CII?
Teil 2 der Norm (CEN/TS 16931-2) erlaubt zwei XML-Syntaxen: UBL 2.1 nach ISO/IEC 19845 (OASIS) und UN/CEFACT Cross Industry Invoice (CII). Beide sind semantisch gleichwertig und können dasselbe Datenmodell vollständig abbilden. UBL ist im PEPPOL-Netzwerk und in XRechnung dominant; CII steckt in ZUGFeRD und Factur-X.
Was sind CIUS und Extensions in EN 16931?
Eine CIUS (Core Invoice Usage Specification) ist eine länderspezifische oder branchenspezifische Anpassung, die das Datenmodell einschränkt — z. B. optionale Felder zur Pflicht macht. Eine Extension erweitert das Modell um neue Felder, die im Core nicht enthalten sind. XRechnung ist eine CIUS, ZUGFeRD-Profil EXTENDED nutzt Extensions.
Gilt EN 16931 EU-weit?
Ja. Seit April 2020 müssen alle öffentlichen Auftraggeber in der EU E-Rechnungen nach EN 16931 entgegennehmen. Im B2B-Sektor wird die Norm zunehmend zur Pflicht — in Deutschland mit dem Wachstumschancengesetz ab 2025, mit voller Versandpflicht bis 2027/2028. Auch ViDA (VAT in the Digital Age) baut auf EN 16931 auf.
Wo finde ich die offizielle Spezifikation?
Die offizielle Norm gibt es kostenpflichtig über CEN bzw. die nationalen Normungsinstitute (in Deutschland DIN, Beuth-Verlag). Frei verfügbar sind die XRechnung-Spezifikationen der KoSIT (xeinkauf.de), die ZUGFeRD-Spezifikation des FeRD und die PEPPOL-BIS-Billing-3.0-Dokumente (docs.peppol.eu). Eine praxisnahe Einführung findest du in unseren Blog-Anleitungen XRechnung erstellen und ZUGFeRD erstellen.
Zusammenfassung
EN 16931 ist die gemeinsame Sprache der E-Rechnung in Europa. Die Norm definiert ein semantisches Datenmodell mit ca. 160 Business Terms und erlaubt zwei XML-Syntaxen (UBL 2.1 und UN/CEFACT CII) für die technische Umsetzung. XRechnung ist die deutsche CIUS, ZUGFeRD die deutsche hybride PDF/XML-Variante. Beide sind EN-16931-konform und werden über die KoSIT bzw. FeRD weiterentwickelt.
Für dich als Unternehmer oder Selbstständiger bedeutet das: Stelle sicher, dass deine E-Rechnungslösung EN-16931-konform arbeitet. Dann bist du sowohl für die deutsche B2B-Pflicht als auch für den europäischen Rechnungsverkehr gerüstet. SimplyBills übernimmt genau das — du wählst das Format, klickst auf "Erstellen", und der Rest passiert im Hintergrund nach Norm. Probier es direkt unter Rechnung erstellen oder schau dir den Funktionsumfang unter Funktionen an.
