EN 16931: Der vollständige Leitfaden zur europäischen E-Rechnungsnorm
Alles über EN 16931: das vom CEN erstellte semantische Datenmodell gemäß EU-Richtlinie 2014/55/EU, die UBL- und CII-Syntaxen, nationale CIUS, Geschäftsregeln und die Beziehung zu Peppol BIS 3.0.
Was ist EN 16931 und warum ist die Norm wichtig?
EN 16931 ist die europäische Norm für das semantische Datenmodell elektronischer Rechnungen, veröffentlicht vom CEN (Europäisches Komitee für Normung). Sie wurde durch die EU-Richtlinie 2014/55/EU verpflichtend, die alle EU-Mitgliedstaaten verpflichtete, elektronische Rechnungen gemäß dieser Norm im öffentlichen Beschaffungswesen (B2G) bis 2019 zu akzeptieren. EN 16931 ist kein Dateiformat — es ist ein semantisches Modell, das die Bedeutung und Einschränkungen jedes Datenfells einer elektronischen Rechnung definiert, unabhängig von der Kodierungsmethode.
Die Norm legt fest, WAS eine elektronische Rechnung enthalten muss, aber nicht WIE diese Daten kodiert werden. Zwei XML-Syntaxen sind offiziell an EN 16931 gebunden: UBL 2.1 (OASIS Universal Business Language) und CII (Cross Industry Invoice) der UN/CEFACT. Jede Rechnung, die in einer dieser Syntaxen kodiert und dem semantischen Modell EN 16931 entspricht, gilt als europäische Standardrechnung. Da sich die E-Rechnungspflichten in Europa vom B2G- auf den B2B-Bereich ausweiten — Frankreich mandatiert B2B ab 2026, Deutschland ab 2027 und Belgien ab Januar 2026 — ist das Verständnis von EN 16931 für alle Finanz- und IT-Fachleute, die mit europäischen Unternehmen arbeiten, unerlässlich geworden.
Struktur von EN 16931: das semantische Modell
Das semantische Modell EN 16931 definiert rund 170 Business Terms (BT) und Business Term Groups (BTG), die gemeinsam eine vollständige elektronische Rechnung beschreiben. Diese Begriffe sind in logische Gruppen gegliedert, die den gesamten Rechnungslebenszyklus abdecken, von der Kopfzeilenidentifikation bis zu Zeilendetails und Steuerübersichten. Die Norm wird in mehreren Teilen veröffentlicht: EN 16931-1 definiert das semantische Modell selbst, während EN 16931-2 die Syntaxbindungen für UBL und CII festlegt.
Pflichtfelder, die jede EN 16931-konforme Rechnung enthalten muss, umfassen:
- Rechnungsnummer (BT-1) — Eine eindeutige Kennung für die Rechnung, die vom Verkäufer vergeben wird. Sie muss im Rechnungssystem des Verkäufers einmalig sein.
- Rechnungsdatum (BT-2) — Das Datum, an dem die Rechnung ausgestellt wurde, im Format ISO 8601 (JJJJ-MM-TT).
- Verkäuferinformationen (BT-27 bis BT-44) — Name, Postanschrift und mindestens eine Kennung (USt-Nummer, Handelsregisternummer) des Verkäufers.
- Käuferinformationen (BT-44 bis BT-59) — Name und Postanschrift des Käufers. Die USt-Nummer ist Pflicht, wenn der Käufer umsatzsteuerpflichtig ist.
- Steueraufschlüsselung (BT-118 bis BT-130) — Eine vollständige Aufschlüsselung der Steuerbeträge nach USt-Kategoriecode und Steuersatz. Jeder anwendbare USt-Satz muss eine eigene Aufschlüsselungszeile erhalten.
- Rechnungszeilen (BTG-25) — Mindestens eine Rechnungszeile mit Menge, Einzelpreis, Zeilenbetrag und Artikelbeschreibung. USt-Kategorieinformationen auf Zeilenebene sind Pflicht.
Optionale Informationsgruppen umfassen Lieferdetails (Lieferanschrift, tatsächliches Lieferdatum), Zahlungsanweisungen (IBAN, Zahlungsreferenz, Fälligkeitsdatum), Rabatte und Zuschläge auf Dokumentenebene sowie Anhänge wie PDF-Kopien oder Belege. Obwohl in der Basisnorm optional, erheben viele nationale CIUS (Core Invoice Usage Specifications) diese Felder in den Pflichtstatus — beispielsweise verlangt XRechnung ein tatsächliches Lieferdatum und einige Peppol-Profile eine Käuferreferenz. Das Verständnis, welche Felder auf EN 16931-Basisebene im Vergleich zur CIUS-Ebene Pflicht sind, ist für die grenzüberschreitende Interoperabilität entscheidend.
Die beiden Syntaxen: UBL 2.1 vs. CII
UBL 2.1, entwickelt von OASIS, ist die am häufigsten verwendete Syntax für EN 16931-konforme Rechnungen in Nord- und Westeuropa. Es ist die von Peppol BIS Billing 3.0 verwendete Syntax, dem europaweiten E-Rechnungsprofil, das über das Peppol-Netzwerk bereitgestellt wird. UBL verwendet ein stark strukturiertes XML-Format mit klar definierten Namespaces: Das Wurzelelement ist je nach Dokumenttyp entweder Invoice oder CreditNote. UBL-Rechnungen werden von ERP-Systemen, Buchhaltungssoftware und E-Rechnungsplattformen in Europa weitgehend unterstützt.
CII (UN/CEFACT Cross Industry Invoice) wird von XRechnung (dem deutschen Pflichtformat), Factur-X (dem deutsch-französischen hybriden PDF+XML-Format) und ZUGFeRD verwendet. Sein Wurzelelement ist rsm:CrossIndustryInvoice und es verwendet eine hierarchischere, handelszentrierte Struktur, die vom breiteren UN/CEFACT-Handelsdokumentmodell beeinflusst ist. Obwohl in rein elektronischen Kontexten weniger verbreitet als UBL, dominiert CII in hybriden PDF-Workflows, bei denen eine XML-Rechnung in ein PDF-Dokument eingebettet ist.
| Merkmal | UBL 2.1 | CII (UN/CEFACT) |
|---|---|---|
| Hauptanwendungsfall | Peppol-Netzwerk, B2G/B2B EDI | XRechnung, Factur-X, ZUGFeRD |
| Wurzelelement | Invoice / CreditNote | CrossIndustryInvoice |
| Dominierende Regionen | Nord-/Westeuropa, weltweit | Deutschland, Frankreich (hybrides PDF) |
| Hybrides PDF-Support | Nicht nativ (Peppol nutzt reines XML) | Ja (Factur-X, ZUGFeRD) |
Ein grundlegendes Designprinzip von EN 16931 ist, dass beide Syntaxen 1:1 dem gleichen semantischen Modell entsprechen. Das bedeutet, dass die Konvertierung zwischen UBL und CII verlustfrei ist — jeder Business Term in einer gültigen UBL-Rechnung hat ein genaues CII-Äquivalent und umgekehrt. Standard-Transformationswerkzeuge (XSLT-Stylesheets) sind verfügbar, um zwischen den beiden Formaten zu konvertieren, ohne Rechnungsdaten zu verlieren. Diese Interoperabilität ist ein Eckpfeiler der europäischen E-Rechnungsvision: Lieferanten und Käufer können unterschiedliche Formate verwenden und trotzdem Rechnungen ohne manuelle Neueingabe austauschen.
Nationale Implementierungen: CIUS und nationale Mandate
Frankreich hat die B2G-E-Rechnungsstellung über Chorus Pro seit 2017 verpflichtend gemacht und verwendet Factur-X (eine EN 16931-CIUS) als Referenzformat. Das künftige B2B-Mandat — ursprünglich für September 2026 geplant — verpflichtet alle französischen umsatzsteuerpflichtigen Unternehmen, strukturierte elektronische Rechnungen zu empfangen und schrittweise auch auszustellen. Große Unternehmen müssen zuerst elektronische Rechnungen ausstellen, kleinere folgen danach. Die von der Direction Générale des Finances Publiques (DGFiP) betriebene Chorus Pro-Plattform bleibt B2G-Hub, während der B2B-Markt von zertifizierten Partnerdemateriaisierungsplattformen (PDP) und der öffentlichen Plattform (PPF) bedient wird.
Deutschland hat XRechnung für die bundesweite B2G-Beschaffung seit November 2020 verpflichtend gemacht und verwendet die KoSIT-CIUS von EN 16931 in den UBL- und CII-Syntaxen. Das Wachstumschancengesetz weitet die Pflicht zur E-Rechnungsstellung auf B2B-Transaktionen aus: Alle deutschen umsatzsteuerpflichtigen Unternehmen müssen ab Januar 2025 EN 16931-konforme elektronische Rechnungen empfangen können. Ab Januar 2027 müssen große Unternehmen (Umsatz über 800.000 EUR) auch elektronische Rechnungen versenden; ab Januar 2028 müssen alle verbleibenden Unternehmen der Pflicht nachkommen. Im Gegensatz zu Frankreich schreibt Deutschland kein bestimmtes Format für B2B vor — XRechnung, ZUGFeRD 2.x, Peppol BIS 3.0 oder jedes andere EN 16931-konforme Format ist zulässig.
Belgien hat Peppol für die B2G-Beschaffung seit 2019 schrittweise verpflichtend gemacht und führt ab Januar 2026 die Pflicht zur B2B-E-Rechnungsstellung ein. Die belgische Implementierung verwendet Peppol BIS Billing 3.0 als Referenz-CIUS. Alle belgischen umsatzsteuerpflichtigen Unternehmen müssen strukturierte elektronische Rechnungen empfangen können, kurz darauf folgt die Sendepflicht. Der belgische Ansatz über Peppol ist für sein netzwerkorientiertes Design bemerkenswert: Anstelle einer zentralisierten Plattform werden Rechnungen über akkreditierte Peppol Access Points übertragen, was einen nahtlosen grenzüberschreitenden Austausch mit anderen Peppol-verbundenen Ländern ermöglicht.
Das italienische FatturaPA und die SDI-Plattform (Sistema di Interscambio) sind seit Januar 2019 für B2B verpflichtend und machen Italien zum ersten großen EU-Land mit einer obligatorischen B2B-E-Rechnungspflicht. Obwohl FatturaPA älter als EN 16931 ist und ein anderes Datenmodell verwendet, hat die Europäische Kommission es als im Wesentlichen gleichwertig anerkannt. Die Niederlande, die nordischen Länder (Dänemark, Finnland, Norwegen, Schweden) und die baltischen Staaten setzen stark auf Peppol BIS 3.0 für B2G- und B2B-E-Rechnungsstellung, was UBL zur dominierenden Syntax in diesen Regionen macht. Spanien implementiert eine CIUS namens Factura-e / VERI*FACTU für B2B von 2025 bis 2027.
Geschäftsregeln und Validierung: jenseits von XSD
EN 16931 definiert nicht nur ein Datenmodell, sondern auch einen umfassenden Satz von Geschäftsregeln (BR-xx), die weit über das hinausgehen, was eine XML-Schema-Definition (XSD) validieren kann. Diese Geschäftsregeln gewährleisten semantische Konsistenz — beispielsweise, dass die Summe der Rechnungszeilenbeträge dem Rechnungsgesamtbetrag entspricht oder dass USt-Kategorien konsistent verwendet werden. Die XSD-Validierung prüft nur, ob Elemente vorhanden sind und die richtigen Datentypen haben; die Validierung von Geschäftsregeln prüft, ob die Daten logisch und geschäftlich sinnvoll sind.
BR-CO-10: Prüfung des Rechnungsgesamtbetrags
Die Summe der Nettorechnungszeilenbeträge abzüglich Nachlässe zuzüglich Zuschläge muss dem Gesamtbetrag der Rechnung ohne Steuern entsprechen. Verstöße gegen diese Regel gehören zu den häufigsten Ablehnungsgründen in automatisierten B2G-Systemen.
BR-S-08: Konsistenz des Regelsteuersatzes
Für Artikel, die dem Regelsteuersatz unterliegen (Kategoriecode S), muss der USt-Satz größer als null sein. Eine Rechnung mit einem USt-Satz von null aber dem Kategoriecode S scheitert an dieser Regel. Der korrekte Kategoriecode für nullbesteuerte Lieferungen ist Z.
BR-AE-05: Vollständigkeit der Umkehrung der Steuerschuldnerschaft
Wenn die USt-Kategorie Reverse Charge (AE) verwendet wird, muss die USt-ID des Käufers vorhanden sein. Dies ist ein häufiger Fehler bei grenzüberschreitenden B2B-Rechnungen zwischen EU-Mitgliedstaaten.
BR-E-01: Dokumentation der USt-Befreiung
Wenn die USt-Befreiungskategorie (E) verwendet wird, muss die Rechnung einen Befreiungsgrund oder einen Verweis auf den anwendbaren USt-Befreiungsartikel enthalten. Dies fehlt häufig bei Rechnungen, die von älteren ERP-Systemen generiert werden.
BR-52: Anforderung einer Käuferreferenz
Obwohl in EN 16931 optional, ist die Käuferreferenz (BT-10) in Peppol BIS 3.0 und in XRechnung (als Leitweg-ID) Pflicht. CIUS-spezifische Regeln sind zusätzliche Einschränkungen, die auf die Basisnorm aufgelegt werden.
Nationale CIUS fügen weitere Validierungsebenen hinzu. XRechnung fügt etwa 50 zusätzliche Regeln (de-BR-xx) zu den EN 16931-Geschäftsregeln hinzu und deckt deutschlandspezifische Anforderungen wie die Pflicht-Leitweg-ID, eingeschränkte Zahlungsmittelcodes und das Pflicht-Lieferdatum ab. Peppol BIS 3.0 fügt seinen eigenen Regelsatz (PEPPOL-EN16931-xx) hinzu, der für die Interoperabilität im Peppol-Netzwerk sorgt, z. B. Pflicht-Käuferreferenz und codelistenspezifische Einschränkungen. Das Verständnis, welche Regeln gelten — EN 16931-Basis, CIUS-spezifisch oder beides — ist für den Aufbau konformer Rechnungssysteme entscheidend.
Die Validierung anhand von EN 16931-Geschäftsregeln erfordert eine Schematron-basierte Validierung, nicht nur eine XSD-Schema-Validierung. Schematron ist eine ISO-Norm für die regelbasierte Validierung von XML-Dokumenten und ermöglicht es Validatoren, komplexe feldübergreifende Regeln auszudrücken, die in XSD nicht kodiert werden können. Die offiziellen EN 16931-Validierungsartefakte (XSD-Schemata und Schematron-Regeln) werden vom CEN und der Europäischen Kommission veröffentlicht. Nationale Organisationen wie KoSIT (Deutschland) veröffentlichen zusätzliche Schematron-Regeln für ihre CIUS. ValidateFin implementiert eine Teilmenge dieser Regeln im Browser und prüft UBL-Rechnungen anhand der EN 16931- und Peppol BIS 3.0-Einschränkungen, ohne Daten an einen Server zu senden.
Peppol und EN 16931: Infrastruktur vs. Norm
Peppol (Pan-European Public Procurement Online) wird oft mit EN 16931 verwechselt, aber sie erfüllen unterschiedliche Funktionen. EN 16931 ist eine Datennorm — sie definiert den Inhalt einer elektronischen Rechnung. Peppol ist ein Transportnetzwerk und ein Governance-Rahmen — er definiert, wie Rechnungen sicher zwischen Geschäftspartnern in Europa und darüber hinaus zugestellt werden. Peppol BIS Billing 3.0 ist eine CIUS von EN 16931 unter Verwendung der UBL-Syntax, d. h. es handelt sich um eine Spezialisierung von EN 16931 mit zusätzlichen Einschränkungen und der speziell vorgeschriebenen UBL-Syntax. Jede Peppol BIS 3.0-Rechnung ist auch eine EN 16931-konforme Rechnung, aber nicht alle EN 16931-Rechnungen werden über Peppol übermittelt.
Das Peppol-Netzwerk funktioniert über ein Vier-Ecken-Modell. Ecke 1 ist das ERP- oder Rechnungssystem des Lieferanten. Ecke 2 ist der Peppol Access Point des Lieferanten — ein zertifizierter Dienstleister, der sich mit dem Peppol-Netzwerk verbindet. Ecke 3 ist der Peppol Access Point des Käufers. Ecke 4 ist das ERP- oder Buchhaltungssystem des Käufers. Access Points suchen die Peppol-Adresse des Käufers über SMP-Register (Service Metadata Publisher), die Verzeichnisse sind, die Peppol-Teilnehmer-IDs ihren Access Points und den Dokumenttypen, die sie empfangen können, zuordnen. Diese Infrastruktur ermöglicht es jedem Peppol-verbundenen Unternehmen, jeden anderen Peppol-verbundenen Teilnehmer zu finden und zu erreichen, ohne bilaterale Vereinbarungen.
ValidateFin validiert UBL-Rechnungen anhand der semantischen EN 16931-Regeln und der Peppol BIS 3.0-Geschäftsregeln. Diese doppelte Validierung erkennt Fehler, die von schema-basierten Validatoren übersehen würden: Ein Dokument kann wohlgeformtes XML und sogar schemakonform sein und dennoch EN 16931- oder Peppol-Geschäftsregeln verletzen und von einem Peppol Access Point oder einer nationalen B2G-Plattform abgelehnt werden. Der Validator läuft vollständig in Ihrem Browser — Ihre Rechnungsdatei verlässt niemals Ihr Gerät und gewährleistet die vollständige Vertraulichkeit sensibler Finanzdaten.
Ihre Rechnungen gegen EN 16931 validieren
ValidateFin prüft Ihre UBL-Rechnungen anhand der semantischen EN 16931-Regeln und der Peppol BIS 3.0-Geschäftsregeln und liefert detaillierte Fehlermeldungen, die genau angeben, welche Geschäftsregel fehlgeschlagen ist und warum. Ob Sie eine ERP-Integration aufbauen, sich auf ein nationales B2B-Mandat vorbereiten oder eine abgelehnte Rechnung debuggen — ValidateFin gibt Ihnen sofortiges, umsetzbares Feedback. 100% clientseitig, keine hochgeladenen Daten.
Rechnungen validierenHäufig gestellte Fragen
Was ist EN 16931?
EN 16931 ist die europäische Norm für das semantische Datenmodell elektronischer Rechnungen, veröffentlicht vom CEN (Europäisches Komitee für Normung). Sie definiert die Bedeutung und Einschränkungen jedes Datenelements in einer E-Rechnung. Sie wurde durch die EU-Richtlinie 2014/55/EU für B2G-Beschaffung verpflichtend und ist die Grundlage aller europäischen E-Rechnungsmandate.
Ist EN 16931 verpflichtend?
Für die B2G-Rechnungsstellung (Business-to-Government) ist die EN 16931-Konformität seit 2019 in allen EU-Mitgliedstaaten Pflicht. Für B2B hängt es vom Land ab: Deutschland verlangt EN 16931-konforme E-Rechnungen für den B2B-Empfang ab Januar 2025, Belgien ab Januar 2026 und Frankreich ab 2026. Weitere Länder folgen.
Was ist der Unterschied zwischen EN 16931 und UBL?
EN 16931 ist ein semantisches Datenmodell — es definiert, WAS eine Rechnung enthalten muss. UBL 2.1 ist eine Syntax — es definiert, WIE diese Daten in XML kodiert werden. EN 16931 hat zwei offizielle Syntaxbindungen: UBL 2.1 und UN/CEFACT CII. UBL ist nicht dasselbe wie EN 16931; es ist eine Möglichkeit, eine EN 16931-konforme Rechnung zu kodieren.
Was ist eine CIUS?
CIUS steht für Core Invoice Usage Specification (Kernanforderungsspezifikation für Rechnungen). Es ist eine Spezialisierung von EN 16931, die zusätzliche Einschränkungen für einen bestimmten Anwendungsfall oder ein bestimmtes Land hinzufügt. Beispiele: Peppol BIS 3.0 ist eine CIUS für das Peppol-Netzwerk, XRechnung ist die deutsche B2G-CIUS und Factur-X EN 16931 ist die CIUS für Frankreich. Eine gültige CIUS-Rechnung ist auch eine gültige EN 16931-Rechnung.
Gilt EN 16931 für B2B-Rechnungen?
Die EN 16931-Basisnorm wurde für B2G konzipiert, wird aber für B2B-Mandate in ganz Europa übernommen. Länder wie Deutschland, Frankreich, Belgien und Spanien machen EN 16931-konforme E-Rechnungen für B2B-Transaktionen gemäß unterschiedlichen Zeitplänen zwischen 2025 und 2028 obligatorisch.
Welche Felder sind in EN 16931 Pflicht?
Pflichtfelder umfassen: Rechnungsnummer, Rechnungsdatum, Name und Adresse des Verkäufers, Verkäuferkennung (USt-Nummer oder Handelsregisternummer), Name und Adresse des Käufers, Währungscode, USt-Aufschlüsselung nach Kategorie, Rechnungsgesamtbeträge und mindestens eine Rechnungszeile mit Artikelbeschreibung, Menge, Einzelpreis und Zeilenbetrag.
Wie validiert man eine Rechnung gegen EN 16931?
Die Validierung erfordert zwei Schritte: (1) XSD-Schema-Validierung zur Überprüfung der XML-Struktur und (2) Schematron-Validierung zur Überprüfung semantischer Geschäftsregeln (BR-xx). ValidateFin führt beide Schritte im Browser für UBL-Rechnungen durch und prüft gegen EN 16931- und Peppol BIS 3.0-Regeln, ohne Ihre Datei hochzuladen.
Wie ist die Beziehung zwischen Peppol und EN 16931?
Peppol BIS Billing 3.0 ist eine CIUS (Core Invoice Usage Specification) von EN 16931 unter Verwendung der UBL 2.1-Syntax. Peppol ist das Transportnetzwerk; EN 16931 definiert den Rechnungsinhalt. Jede Peppol BIS 3.0-Rechnung ist EN 16931-konform, aber Sie können EN 16931 nutzen, ohne das Peppol-Netzwerk zu verwenden.
Kann ich zwischen UBL und CII konvertieren?
Ja. Da UBL und CII 1:1 dem gleichen semantischen Modell EN 16931 entsprechen, ist die Konvertierung zwischen ihnen verlustfrei. Standard-XSLT-Stylesheets sind für diese Konvertierung verfügbar. Dies ermöglicht die Konvertierung einer CII-basierten XRechnung in UBL für die Peppol-Zustellung oder umgekehrt.
Was passiert, wenn meine Rechnung die EN 16931-Validierung nicht besteht?
In B2G-Kontexten werden nicht konforme Rechnungen automatisch von Plattformen wie Chorus Pro (Frankreich), ZRE (Deutschland) oder Peppol Access Points abgelehnt. In B2B-Kontexten können automatisierte Verarbeitungssysteme der Käufer die Rechnung ablehnen oder manuellen Eingriff erfordern. Das Beheben spezifischer Geschäftsregelverletzungen, die von einem Validator wie ValidateFin identifiziert werden, ist der schnellste Weg zur Konformität.