EN 16931: Die europäische Norm für elektronische Rechnungen

Die Norm EN 16931 definiert das semantische Datenmodell für E-Rechnungen in Europa. Wir erklären, was die Norm bedeutet und warum sie wichtig ist.

28.09.2026

Wer einmal mit E-Rechnungen zu tun hatte, hört diese Nummer immer wieder: EN 16931. Sie ist nicht irgendeine technische Spezifikation, sondern der gemeinsame Nenner aller E-Rechnungs-Formate in Europa. XRechnung, ZUGFeRD, Factur-X, Peppol BIS – alle bauen auf ihr auf.

Was ist die EN 16931?

Die EN 16931 ist eine Norm des Europäischen Komitees für Normung (CEN). Sie definiert ein semantisches Datenmodell für elektronische Rechnungen. Das heißt: Sie listet, welche Informationen eine Rechnung enthalten muss und wie sie zueinander stehen – unabhängig davon, in welcher XML-Syntax sie am Ende geschrieben werden.

Hintergrund:

  • Auftraggeber: EU-Kommission, im Rahmen der Richtlinie 2014/55/EU.
  • Veröffentlichung: Oktober 2017 (Teil 1), Folgeteile später.
  • Pflege: regelmäßig durch CEN/TC 434.
  • Status in Deutschland: in § 14 UStG als verbindliche Bezugsgröße verankert.

Ohne EN 16931 keine deutsche E-Rechnungspflicht.

Aufbau der Norm

Die Norm besteht aus mehreren Teilen:

TeilInhalt
EN 16931-1Semantisches Datenmodell
CEN/TS 16931-2Liste der Syntax-Bindings
CEN/TS 16931-3-2Mapping auf UBL 2.1
CEN/TS 16931-3-3Mapping auf UN/CEFACT CII
CEN/TS 16931-5Leitfaden für CIUS und Extensions
CEN/TR 16931-6Geschäftsregeln

Der Kern ist Teil 1: das semantische Modell. Alles andere setzt es in konkrete Technik um.

Das semantische Modell

Die EN 16931 unterscheidet Geschäftsdatentypen (BT) und Geschäftsgruppen (BG):

  • BT (Business Term) – ein Einzelfeld, z. B. BT-1 Rechnungsnummer, BT-5 Währung.
  • BG (Business Group) – ein Bündel zusammengehöriger Felder, z. B. BG-4 Verkäufer, BG-25 Rechnungsposition.

Insgesamt rund 165 Felder und 30 Gruppen. Eine Rechnung ist die Summe aus Pflicht- und optionalen Feldern. Die Norm legt fest, welche zwingend sind und in welcher Kombination.

Beispiele:

  • BT-1 Rechnungsnummer → Pflicht
  • BT-2 Ausstellungsdatum → Pflicht
  • BT-9 Fälligkeitsdatum → bedingt Pflicht (bei Zahlungsziel)
  • BT-46 Identifikator des Käufers → optional
  • BG-25 Rechnungspositionen → Pflicht (mindestens eine)

Eine Übersicht der wichtigsten Pflichtfelder in XRechnung Pflichtfelder.

Zwei erlaubte Syntaxen

Damit Software das Modell austauschen kann, definiert die Norm zwei zulässige XML-Syntaxen:

  1. UBL 2.1 – OASIS-Standard, breit verbreitet, vor allem in Skandinavien und im PEPPOL-Netzwerk. Mehr in UBL.
  2. UN/CEFACT CII – Cross Industry Invoice der UN, Basis von ZUGFeRD und Factur-X. Mehr in CII.

Die XRechnung erlaubt beide, ZUGFeRD ausschließlich CII. Hintergrund in E-Rechnung XML-Format.

Geschäftsregeln (Business Rules)

Neben dem Modell schreibt die Norm Geschäftsregeln vor, die jeder Validator prüft. Beispiele:

  • BR-CO-15: Die Summe aller Positionsbeträge muss zur angegebenen Nettosumme passen.
  • BR-CO-10: Bei Reverse Charge muss BT-118 = AE und BT-119 = 0 stehen.
  • BR-S-08: Steuerkategorie und Steuersatz müssen konsistent sein.
  • BR-DE-15: Deutsche Spezifik: USt-IdNr. oder Steuernummer ist Pflicht.

Diese Regeln sind in Schematron kodiert und werden bei jeder Validierung geprüft. Mehr in E-Rechnung validieren und Validator-Tools.

CIUS und Extensions

Damit Länder und Branchen eigene Anforderungen ergänzen können, kennt die Norm zwei Mechanismen:

  • CIUS (Core Invoice Usage Specification) – schränkt das Modell ein und macht zusätzliche Felder zur Pflicht. XRechnung ist die deutsche CIUS.
  • Extension – fügt Felder hinzu, ohne den Kern zu verändern. ZUGFeRD EXTENDED ist eine solche Extension.

Beide Mechanismen sichern: Eine Rechnung bleibt in Europa interoperabel, auch wenn nationale Sonderwünsche dazukommen. Mehr in CIUS und ZUGFeRD-Profile.

Was die Norm nicht regelt

Wichtig zu wissen, was die EN nicht vorgibt:

  • Den Übertragungsweg. E-Mail, Portal, PEPPOL – die Norm sagt nur, was drinsteht, nicht wie sie ankommt.
  • Die Visualisierung. Aussehen des PDFs, Logo, Schriftart – alles unbestimmt.
  • Die Aufbewahrung. Steuerliche Archivierung folgt nationalem Recht (in Deutschland GoBD).
  • Die Prozesse beim Empfänger. Workflow, Buchung, Zahlung – Sache des Empfängers.

Entwicklung und Versionen

Die Norm wird regelmäßig aktualisiert. Wichtige Marken:

  • 2017: Erstausgabe.
  • 2019: Anpassung der Geschäftsregeln (Erratum).
  • 2022: technische Korrigenda.
  • Aktuelle Pflege im Rahmen von ViDA und nationalen Erweiterungen.

Empfohlen: Bei jeder Tool-Aktualisierung die Versionshinweise prüfen, vor allem bei XRechnung und ZUGFeRD.

Warum die Norm der Mittelstands-Hebel ist

Drei direkte Konsequenzen:

  1. Format-Vielfalt sinkt. Wer EN-konform ist, kann XRechnung, ZUGFeRD, Factur-X und PEPPOL BIS bedienen.
  2. Validierung ist berechenbar. Die Geschäftsregeln sind veröffentlicht – kein Geheimwissen.
  3. Behörden akzeptieren EN-konforme Rechnungen. Das ist die Grundlage der deutschen B2G-Pflicht.

Häufige Fragen

Ist die EN 16931 frei verfügbar?

Die Norm selbst kostet beim Beuth-Verlag Geld. Die abgeleiteten Spezifikationen (XRechnung, ZUGFeRD, Factur-X) und die Schematron-Regeln sind öffentlich und kostenfrei.

Reicht es, EN-konform zu sein, um in ganz Europa Rechnungen zu schicken?

Im Kern ja, aber Länder haben eigene CIUS und Übertragungsprozesse (z. B. Italien SDI). Mehr in E-Rechnung Vergleich Länder.

Welche Version der Norm gilt aktuell?

Maßgeblich ist die jeweils zuletzt veröffentlichte deutsche Fassung der EN 16931-1 mit ihren Korrigenda. Validatoren halten den Stand intern aktuell.

Was passiert, wenn ein Feld fehlt, das die EN nicht als Pflicht markiert?

Dann ist die Rechnung formal weiter konform – aber der Empfänger oder die nationale CIUS kann das Feld trotzdem als Pflicht definieren. Beispiel: Leitweg-ID ist EN-optional, in Deutschland für Behörden Pflicht.

Bezieht sich die deutsche E-Rechnungspflicht direkt auf die EN 16931?

Ja. § 14 UStG verweist auf das durch die EN definierte Format. Damit ist sie der rechtliche Anker des gesamten Systems.