EN 16931 ist die europäische Norm, die ein semantisches Kernmodell für die elektronische Rechnung definiert: benannte Geschäftsobjekte (Business Groups, BG-…) und Geschäftsfelder (Business Terms, BT-…) samt Geschäftsregeln (BR-…). Sie ist syntaxneutral und wird in zwei XML-Syntaxen abgebildet — UN/CEFACT CII und OASIS UBL. XRechnung und ZUGFeRD/Factur-X sind nationale Ausprägungen (CIUS) dieser einen Norm.

Wer E-Rechnungen erzeugt, stößt überall auf EN 16931 — als Bezugspunkt von XRechnung, ZUGFeRD, Factur-X, KoSIT-Validierung und der Ausstellungspflicht. Dieser Beitrag erklärt die Norm so, wie sie für die Umsetzung relevant ist: als Datenmodell, nicht als Dateiformat.

EN 16931 ist ein semantisches Modell, kein Format

EN 16931 legt fest, welche Informationen eine Rechnung trägt und wie sie zusammenhängen — nicht, in welchem XML sie stehen. Der Kern ist ein benanntes, hierarchisches Feldmodell aus drei Bausteinen:

  • Business Term (BT-…) — ein einzelnes Feld, z. B. BT-1 (Rechnungsnummer), BT-5 (Rechnungswährung), BT-10 (Käuferreferenz), BT-49 (elektronische Adresse des Käufers).
  • Business Group (BG-…) — eine Gruppe zusammengehöriger BTs, z. B. BG-4 (Verkäufer), BG-7 (Käufer), BG-25 (Rechnungsposition), BG-23 (USt-Aufschlüsselung).
  • Geschäftsregel (BR-…) — eine inhaltliche Bedingung, z. B. BR-16 (eine Rechnung braucht mindestens eine Position) oder die BR-CO-…-Regeln, die die rechnerische Konsistenz der Summen erzwingen.

Weil das Modell syntaxneutral ist, lässt es sich in mehr als einer XML-Sprache ausdrücken — ohne dass sich die Bedeutung ändert.

Zwei Syntaxen: CII und UBL

Die Norm benennt zwei zulässige XML-Syntaxen für das Kernmodell:

SyntaxHerausgeberKurz
CII (Cross Industry Invoice)UN/CEFACTin Deutschland verbreitet; die Syntax, die im ZUGFeRD-Hybrid eingebettet ist
UBL (Universal Business Language)OASISalternative Syntax, europaweit verbreitet, z. B. über Peppol

Beide erfüllen dieselbe Norm. Ein und dieselbe Rechnung — dieselben BT-Werte — kann als CII oder als UBL serialisiert werden. Der Unterschied liegt in den Element-Namen und der Verschachtelung, nicht in der Semantik.

CIUS und Extension: nationale Ausprägungen

Die Norm ist bewusst breit. Damit sie in einem Land eindeutig anwendbar wird, gibt es zwei Anpassungsmechanismen:

  • CIUS (Core Invoice Usage Specification) — schränkt ein, ohne zu widersprechen: macht optionale Felder verpflichtend, verbietet andere, präzisiert Codelisten. XRechnung ist der CIUS für Deutschland.
  • Extension — erweitert über das Kernmodell hinaus. Das ZUGFeRD-Profil EXTENDED ist ein Beispiel.

Die Regel für die Praxis: Ein Empfänger, der das reine Kernmodell versteht, verarbeitet jeden CIUS zuverlässig; eine Extension kann er, muss er aber nicht auswerten. Für maximale Anschlussfähigkeit hält man sich am Kernmodell bzw. am Profil EN 16931 (COMFORT).

So setzen XRechnung, ZUGFeRD und Factur-X auf

Die Formate, die im deutschen Alltag verlangt werden, sind allesamt Ausprägungen dieser einen Norm:

  • XRechnung — reines XML nach dem deutschen CIUS (CII oder UBL), typisch für B2G und große Abnehmer.
  • ZUGFeRD / Factur-X — hybrides PDF/A-3 mit eingebettetem CII-XML nach EN 16931; ZUGFeRD (deutsch) und Factur-X (französisch) sind technisch äquivalent.

Weil alle dasselbe BG/BT-Modell abbilden, lässt sich aus einer Datenquelle sowohl XRechnung als auch ZUGFeRD erzeugen — der Vergleich der Formate steht unter XRechnung, ZUGFeRD und Factur-X im Vergleich.

Geschäftsregeln: warum “wohlgeformt” nicht reicht

Ein XML kann syntaktisch korrekt und trotzdem ungültig sein — nämlich dann, wenn es eine Geschäftsregel verletzt. Die BR-…-Regeln der EN 16931 prüfen unter anderem:

  • Summenkonsistenz (BR-CO-…) — Positionssummen, Netto, Steuer und Brutto müssen exakt zusammenpassen.
  • USt-Logik (BR-S-…, BR-E-…, BR-AE-…) — je Steuerkategorie müssen Satz, Kategorie und aufgeschlüsselter Betrag konsistent sein.
  • Pflichtfelder — je nach CIUS z. B. Käuferreferenz/Leitweg-ID oder die elektronische Adresse des Empfängers.

Diese Regeln werden per Schematron geprüft. Wie das konkret abläuft und welche Fehlerklassen typisch sind, steht unter KoSIT-Validierung erklärt.

Warum das Modell die stabile Integrationsgrenze ist

Wer gegen das semantische Modell (BG/BT) integriert statt gegen ein konkretes XML, gewinnt Stabilität: Ändert sich eine Profilversion oder eine Syntaxbindung — etwa beim Übergang zur Norm EN 16931:2026 und XRechnung 4.0 — bleibt das Modell “Kunde, Positionen, Steuersätze” gleich; nur die Serialisierung wandert. Genau an dieser Grenze setzt eine E-Rechnung API an: Du lieferst die BT-Werte, der Dienst kümmert sich um CII/UBL, Codelisten und Geschäftsregeln.

Fortlauf baut XRechnung und ZUGFeRD/Factur-X aus einem EN-16931-Datenmodell — der konkrete Request-Flow steht unter XRechnung per API erzeugen und ZUGFeRD/Factur-X per API erzeugen. Der Produkt-Einstieg für Entwickler liegt im Entwickler-Bereich.

Selbst ausprobieren? Der Zugang ist kostenlos und ohne Karte — Produkt-Einstieg für Entwickler →

Oder den eigenen Abrechnungsfluss konkret durchsprechen: 30 Min, technisch, mit dem Gründer →

Häufige Fragen

Was ist EN 16931 einfach erklärt?
EN 16931 ist die europäische Norm für die elektronische Rechnung. Sie legt nicht ein Dateiformat fest, sondern ein semantisches Modell: welche Felder eine Rechnung enthält (Business Terms, BT-…), wie sie zu Gruppen gebündelt sind (Business Groups, BG-…) und welche inhaltlichen Regeln gelten (Geschäftsregeln, BR-…). Dieses Modell wird dann in konkreten XML-Syntaxen — CII oder UBL — ausgedrückt.
Was ist der Unterschied zwischen BG und BT?
Ein BT (Business Term) ist ein einzelnes benanntes Feld, etwa BT-1 (Rechnungsnummer) oder BT-10 (Käuferreferenz). Eine BG (Business Group) bündelt zusammengehörige BTs, etwa BG-4 (Verkäufer) oder BG-25 (Rechnungsposition). Das Modell ist damit eine benannte, hierarchische Feldstruktur, unabhängig von der späteren XML-Syntax.
Was sind CIUS und Extension bei EN 16931?
Ein CIUS (Core Invoice Usage Specification) schränkt die Norm ein, ohne ihr zu widersprechen — es macht optionale Felder verpflichtend oder verbietet sie. XRechnung ist ein solcher CIUS für Deutschland. Eine Extension erweitert das Kernmodell über die Norm hinaus (etwa das ZUGFeRD-Profil EXTENDED). Empfänger, die nur das Kernmodell verstehen, verarbeiten einen CIUS zuverlässig, eine Extension nicht zwingend.
Sind XRechnung und ZUGFeRD dasselbe wie EN 16931?
Sie basieren beide auf EN 16931, sind aber nicht die Norm selbst. XRechnung ist ein reines XML nach dem deutschen CIUS; ZUGFeRD/Factur-X ist ein hybrides PDF/A-3 mit eingebettetem CII-XML. Beide bilden dasselbe EN-16931-Kernmodell ab — deshalb entstehen sie aus einer gemeinsamen Datenquelle.