Ratgeber für Entwickler
EN 16931 einfach erklärt für Entwickler
EN 16931 ist der europäische Standard für elektronische Rechnungen. Er definiert ein semantisches Datenmodell, aus dem XRechnung und ZUGFeRD abgeleitet sind. Wer die Norm versteht, versteht beide Formate.
Nur eine Rechnung prüfen?
Nutze den Web-Validator für schnelle Browser-Tests mit XML oder ZUGFeRD-PDF.
Zum ValidatorE-Rechnungen automatisieren?
Nutze die API für wiederkehrende Validierung, Erzeugung und Abruf in deiner Software.
Zur EntwicklerseiteWas ist EN 16931?
EN 16931 ist eine Norm des Europäischen Komitees für Normung (CEN) aus dem Jahr 2017, vollständiger Name: EN 16931-1:2017 „Electronic invoicing – Part 1: Semantic data model of the core elements of an electronic invoice". Sie legt fest, welche Datenfelder eine standardkonforme E-Rechnung enthalten muss oder kann – unabhängig vom technischen Format.
Die Norm ist der Kern der EU-Richtlinie 2014/55/EU zur elektronischen Rechnungsstellung im öffentlichen Auftragswesen. Alle Mitgliedsstaaten müssen E-Rechnungen akzeptieren, die EN 16931 erfüllen.
Business Terms (BT) und Business Groups (BG)
EN 16931 beschreibt Datenfelder als Business Terms (BT) und gruppiert sie in Business Groups (BG). Jedes Feld hat eine eindeutige Nummer, z. B.:
- → BT-1 – Invoice number (Rechnungsnummer, Pflichtfeld)
- → BT-2 – Invoice issue date (Rechnungsdatum, Pflichtfeld)
- → BT-9 – Payment due date (Fälligkeitsdatum)
- → BT-23 – Business process type (Prozesstyp, z. B. A1 für Standard)
- → BT-31 – Seller VAT identifier (USt-IdNr. des Verkäufers)
- → BG-25 – Invoice line (Rechnungsposition, wiederholbares Element)
Diese Nummerierung ist formatübergreifend gültig. Wenn eine Validierungsregel auf BR-31 verweist, meint sie immer dasselbe Business Rule, egal ob du XRechnung UBL oder ZUGFeRD CII verwendest.
EN 16931 vs. die konkreten Formate
EN 16931 definiert nur das Datenmodell, nicht das technische Encoding. Die Umsetzung erfolgt in separaten Syntaxbindungen (CIUS – Core Invoice Usage Specifications):
- → XRechnung (CIUS DE) – Deutsche CIUS, die EN 16931 in UBL 2.1 (XML) oder CII D16B (XML) abbildet. Für Rechnungen an deutsche Bundesbehörden vorgeschrieben.
- → ZUGFeRD / Factur-X – Hybridformat mit PDF/A-3 und eingebettetem CII-XML. Profile von MINIMUM bis XRECHNUNG spiegeln unterschiedliche EN-16931-Konformitätsstufen.
- → Peppol BIS Billing 3.0 – Internationale CIUS auf UBL-Basis, genutzt im Peppol-Netzwerk (hauptsächlich Nordeuropa und B2G EU-weit).
Was Entwickler konkret wissen müssen
Für die Implementierung sind folgende Punkte praxisrelevant:
- → Pflichtfelder vs. optionale Felder – EN 16931 unterscheidet zwischen Mandatory (M), Optional (O) und Conditional (C). Conditional-Felder sind Pflicht, wenn eine übergeordnete Bedingung erfüllt ist (z. B. BT-120 ist Pflicht, wenn Skonti vorhanden sind).
- → Business Rules (BR) – Die Norm definiert über 100 Validierungsregeln. BR-1 bis BR-57 sind allgemeine Regeln, BR-AE, BR-E, BR-Z usw. betreffen spezifische Steuerszenarien.
- → Cardinality – Manche Felder dürfen maximal einmal vorkommen (0..1 oder 1), andere können wiederholt werden (0..n oder 1..n).
- → Codelisten – Viele Felder erwarten Werte aus ISO-Codelisten (Währung: ISO 4217, Land: ISO 3166-1 alpha-2, Steuer-Code: UN/ECE 5305).
Validierung gegen EN 16931
Die offizielle Validierung gegen EN 16931 erfolgt über XSL-Schematron-Regeln, die vom KOSIT (Koordinierungsstelle für IT-Standards) bereitgestellt werden. Die XInvoice API nutzt diese offiziellen Artefakte und gibt bei Verstößen die BR-Nummer, den XPath im Dokument und eine Fehlerbeschreibung zurück.
So kannst du EN-16931-Validierung direkt in deine Integrations- oder Produktionspipeline einbauen, ohne eigene Schematron-Umgebung aufzubauen.