Was ist die EN 16931?
Die EN 16931 ist die europäische Norm für die E-Rechnungsstellung. Das Europäische Komitee für Normung (CEN) hat die Norm 2017 im Auftrag der Europäischen Kommission veröffentlicht. Im März 2026 wurde das semantische Datenmodell überarbeitet (EN 16931-1:2026). Die Norm beschreibt ein semantisches Datenmodell: einen festen Satz von Informationselementen, die zusammen eine E-Rechnung bilden, mit ihrer Bedeutung, ihren Beziehungen untereinander und den Regeln, denen sie entsprechen müssen.
Unmittelbarer Anlass war die Richtlinie 2014/55/EU. Sie verpflichtet öffentliche Auftraggeber in der Europäischen Union, E-Rechnungen zu empfangen und zu verarbeiten, die der EN 16931 entsprechen. Für zentrale Behörden galt diese Pflicht ab April 2019. Dezentrale Behörden durften bis April 2020 warten.
Die EN 16931 schreibt kein Dateiformat vor. Die Norm legt fest, welche Daten eine Rechnung enthält und was sie bedeuten. Wie diese Daten technisch abgebildet werden, bestimmen die Syntaxbindungen, etwa UBL und UN/CEFACT CII. Mehr über die einzelnen Formate lesen Sie auf der Seite Rechnungsformate. Die Norm wird von CEN/TC 434 gepflegt; in den Niederlanden begleitet der NEN-Normenausschuss für E-Rechnungsstellung die Arbeit, in Belgien das NBN, in Luxemburg das ILNAS, in Frankreich die AFNOR und in Deutschland das DIN.
Kernkomponenten der EN 16931
Semantisches Datenmodell
- Mehr als 160 Informationselemente (Business Terms)
- Pflichtfelder und optionale Felder
- Business Rules für Konsistenz und Rechenregeln
- Unterstützung verschiedener Rechnungsarten
Syntaxbindungen
- UBL 2.1
- UN/CEFACT CII
- Raum für CIUS (Core Invoice Usage Specification)
- Nationale und branchenspezifische Erweiterungen
Codelisten
- Währungscodes (ISO 4217)
- Ländercodes (ISO 3166)
- Umsatzsteuerkategorien
- Zahlungsarten
Validierung und Compliance
- Schematron-Validierungsregeln
- Prüfung der Business Rules
- Syntaxvalidierung (XML-Schema)
- Konformitätstests
Interoperabilität
- Mapping zwischen UBL und CII
- Versionsverwaltung und Stabilität des Modells
- Anschluss an internationale Standards
- Grundlage für den grenzüberschreitenden Austausch
Sicherheit und Integrität
- Nachweisbare Herkunft durch gesicherten Transport
- Integrität des Inhalts
- Eindeutige, überprüfbare Daten
- Unterstützung eines Audit-Trails
Wie verhält sich die EN 16931 zu Peppol?
EN 16931 und Peppol ergänzen sich. Die EN 16931 bestimmt, was in einer E-Rechnung steht: das semantische Modell. Peppol bestimmt, wie diese Rechnung sicher und zuverlässig beim Empfänger ankommt: das Netzwerk, die Vereinbarungen und die Infrastruktur für den Transport.
Innerhalb des Peppol-Netzwerks ist Peppol BIS Billing 3.0 das vereinbarte Rechnungsformat. Peppol BIS Billing 3.0 ist eine CIUS der EN 16931. Es folgt der Norm also vollständig und legt darüber hinaus einige zusätzliche Vereinbarungen fest. Eine Rechnung, die die Peppol BIS-Validierung besteht, erfüllt damit auch die EN 16931.
Was das bringt:
- Ein Datenmodell für Rechnungen an Behörden und Unternehmen
- Ein Anschluss für Empfänger in mehreren Ländern
- Vorhersehbare Validierung nach öffentlichen Regeln
- Eine stabile Grundlage, wenn die Zahl der Handelspartner wächst
Wo wird die EN 16931 verwendet?
Nahezu jede europäische E-Rechnungspflicht baut auf der EN 16931 auf, häufig über eine eigene CIUS: eine Ausprägung, die der Norm folgt und nationale Vereinbarungen ergänzt. In den Niederlanden ist das die NLCIUS (die niederländische CIUS), in Belgien und Luxemburg Peppol BIS Billing 3.0, in Deutschland XRechnung und ZUGFeRD und in Frankreich die Formate, die die plateformes agréées unterstützen. Auch ViDA nutzt die EN 16931 als Grundlage für die grenzüberschreitende E-Rechnungsstellung ab 2030. Siehe ViDA erklärt.
Zeitstrahl EN 16931 und E-Rechnungsstellung
- 2014: Die Richtlinie 2014/55/EU fordert eine europäische Norm für die E-Rechnungsstellung bei öffentlichen Aufträgen.
- 2017: CEN veröffentlicht die EN 16931 mit dem semantischen Datenmodell und der Liste der Syntaxen.
- 2019–2020: Zentrale Behörden müssen ab April 2019 E-Rechnungen nach EN 16931 empfangen und verarbeiten können, dezentrale Behörden spätestens ab April 2020.
- 2020: Peppol BIS Billing 3.0, eine CIUS der EN 16931, wird zum 18. April im Peppol-Netzwerk verpflichtend.
- 2025: ViDA wird verabschiedet; die grenzüberschreitende E-Rechnungsstellung basiert auf der EN 16931.
- 2026: CEN genehmigt am 13. März die EN 16931-1:2026, die überarbeitete Fassung des semantischen Datenmodells, auch mit Blick auf ViDA. Sie ersetzt die EN 16931-1:2017+A1:2019.
- 2030: Digitale Meldepflichten für grenzüberschreitende B2B-Transaktionen innerhalb der EU.
Was sich nach 2020 in der europäischen Regulierung zur E-Rechnungsstellung getan hat, lesen Sie auf der Seite ViDA erklärt.
Technische Spezifikationen
| Merkmal | Spezifikation |
|---|---|
| Norm | EN 16931-1:2026 (semantisches Datenmodell; ersetzt EN 16931-1:2017+A1:2019), CEN/TS 16931-2:2017 (Liste der Syntaxen) |
| Unterstützte Syntaxen | UBL 2.1, UN/CEFACT CII D16B |
| Dokumenttypen | Rechnungsartcodes aus UNTDID 1001, darunter 380 (Rechnung), 381 (Gutschrift) und 384 (korrigierte Rechnung) |
| Business Rules | 100+ |
| Zeichenkodierung | UTF-8 |
| Identifikationsschemata | ISO 6523 ICD-Liste |
| Erweiterungen | CIUS und Erweiterungen zulässig |
Was das für Ihre Software bedeutet
Sie sind Anbieter von Buchhaltungs-, ERP-, Einkaufs- oder Fakturierungssoftware? Dann müssen die Rechnungen, die Ihre Software erstellt und verarbeitet, der EN 16931 entsprechen. Die Frage ist nicht, ob Sie die Norm unterstützen, sondern wie. In der Praxis gibt es zwei Wege.
Weg 1: Selbst entwickeln
Sie bauen die EN 16931-Validierung und -Konvertierung selbst in Ihre Software ein. Ihr Team implementiert die Syntaxbindungen (UBL und/oder CII), führt die Schematron-Validierung durch, überträgt das interne Datenmodell auf das semantische Modell der Norm und hält dies aktuell, wenn die Norm, die CIUS oder Peppol BIS aktualisiert wird.
Weg 2: Über einen Service Provider oder Konvertierungsdienst
Ihre Software liefert Rechnungsdaten über eine API an. Der Service Provider validiert, konvertiert in das richtige Format und übernimmt den Versand über das Peppol-Netzwerk. Ihr Team muss die Details der Norm nicht selbst pflegen.
Entscheidungskriterien
Entwicklungszeit
Die Eigenentwicklung erfordert einen erheblichen Aufwand für Mapping, Validierung und Tests. Eine API-Anbindung ist meist schneller umgesetzt, weil die Validierungslogik bereits vorhanden ist.
Wartungsaufwand
Business Rules, Codelisten und Spezifikationen werden regelmäßig aktualisiert. Bei der Eigenentwicklung liegt diese Wartung bei Ihrem Team. Über einen Service Provider wird sie Ihnen weitgehend abgenommen.
Erforderliches Fachwissen
Die Eigenentwicklung erfordert fundierte Kenntnisse des semantischen Modells, von Schematron, UBL und CII sowie der nationalen CIUS-Varianten. Für eine API-Anbindung genügt die Kenntnis Ihres eigenen Datenmodells und der API.
Schnelligkeit der Compliance
Mit einem Service Provider nutzen Sie eine Validierung, die bereits im Einsatz ist. Bei der Eigenentwicklung hängt das Tempo von Ihrer eigenen Roadmap und Ihrer Testkapazität ab.
Kontrolle und Flexibilität
Die Eigenentwicklung bietet maximale Kontrolle über die Verarbeitung. Über eine API sind Sie von den Möglichkeiten und der Dokumentation des Service Providers abhängig.
Für Integratoren gilt dieselbe Abwägung für jedes Kundenprojekt. Für Behörden ist dies vor allem bei der Auswahl von Anbietern relevant und bei der Beurteilung, ob ihre empfangenden Systeme konforme Rechnungen korrekt verarbeiten.
Wie Sie Peppol technisch in Ihr Produkt einbauen, lesen Sie auf der Seite Peppol in Ihre Software integrieren.
Fazit
Die EN 16931 ist die gemeinsame Sprache der E-Rechnungsstellung in Europa. Wer die Norm versteht, versteht auch, warum Peppol BIS, UBL und CII so gut zusammenpassen. Für Ihre Software besteht der nächste Schritt darin, festzulegen, wie Sie diese Sprache unterstützen: selbst oder über einen Service Provider, der Validierung und Konvertierung für Sie übernimmt. Im Vergleichsportal auf Peppol.now sehen Sie, welche Service Provider dazu passen.
