Wenn heute von der E-Rechnung die Rede ist, steht im Hintergrund fast immer eine europäische Norm: EN 16931. Sie legt fest, wie eine elektronische Rechnung inhaltlich aufgebaut sein muss, damit sie maschinenlesbar und über Ländergrenzen hinweg verarbeitbar ist. Wer verstehen will, warum eine per E-Mail verschickte PDF keine echte E-Rechnung ist und was ZUGFeRD und XRechnung eigentlich gemeinsam haben, kommt an EN 16931 nicht vorbei.
In Deutschland ist die E-Rechnung über § 14 UStG verankert. Dort wird definiert, dass eine E-Rechnung ein strukturiertes elektronisches Format nach EN 16931 sein muss. Genau diese Norm schauen wir uns hier an.
Was die Norm regelt
EN 16931 ist eine europäische Norm, die ein semantisches Datenmodell für die elektronische Rechnung beschreibt. Der entscheidende Punkt: Die Norm sagt nicht, wie eine Rechnung optisch aussehen soll, sondern welche Informationen sie enthalten muss und was diese Informationen bedeuten. Sie definiert also die Bedeutung der Daten, nicht ihr Layout.
Das hat einen praktischen Grund. Solange alle Beteiligten dieselbe Bedeutung hinter einem Feld verstehen, kann Software eine Rechnung automatisch auslesen, prüfen und verbuchen, ganz ohne dass ein Mensch die PDF ansieht. Diese Interoperabilität ist der eigentliche Zweck der Norm.
Das semantische Datenmodell: BT und BG
Das Herzstück von EN 16931 ist ein Katalog klar benannter Datenfelder. Diese sind in zwei Kategorien organisiert:
- Business Terms (BT): einzelne Informationsbausteine, zum Beispiel die Rechnungsnummer, das Rechnungsdatum, der Nettobetrag einer Position oder der anzuwendende Steuersatz. Jeder BT hat eine eindeutige Kennung und eine festgelegte Bedeutung.
- Business Groups (BG): Gruppen, die zusammengehörige Business Terms bündeln. Eine Rechnungsposition ist zum Beispiel eine solche Gruppe, ebenso die Verkäuferangaben oder eine Steueraufschlüsselung.
Man kann sich das wie einen Baum vorstellen: Gruppen (BG) fassen Felder (BT) sinnvoll zusammen, und jedes Feld hat eine feste Rolle. Weil dieses Modell einheitlich ist, weiß eine empfangende Software genau, wo sie die Rechnungsnummer oder den Steuerbetrag findet, unabhängig davon, welches Programm die Rechnung erzeugt hat.
Zusätzlich definiert die Norm Geschäftsregeln, etwa dass sich Positionssummen und Gesamtbetrag rechnerisch entsprechen müssen. Erst diese Regeln machen eine Rechnung wirklich prüfbar.
Zwei zulässige Syntaxen: CII und UBL
Das semantische Modell beschreibt, was in der Rechnung steht. Die Syntax beschreibt, wie diese Daten technisch niedergeschrieben werden. EN 16931 lässt dafür zwei XML-Syntaxen zu:
| Syntax | Herausgeber | Kurzbeschreibung |
|---|---|---|
| CII (Cross Industry Invoice) | UN/CEFACT | XML-Format aus dem UN/CEFACT-Umfeld |
| UBL (Universal Business Language) | OASIS | weit verbreitetes XML-Format für Geschäftsdokumente |
Beide transportieren dieselben semantischen Inhalte, nur in unterschiedlicher XML-Struktur. Eine Rechnung nach EN 16931 kann also entweder als CII- oder als UBL-XML vorliegen und ist in beiden Fällen normkonform. Welche Unterschiede zwischen den beiden Syntaxen im Detail bestehen, beleuchten wir gesondert in CII oder UBL: Wo liegt der Unterschied?.
Wie ZUGFeRD und XRechnung darauf aufbauen
In Deutschland begegnen einem in der Praxis vor allem zwei Formate, und beide setzen auf EN 16931 auf:
- XRechnung ist ein reines XML-Format und die spezifische deutsche Ausprägung (ein sogenanntes CIUS, eine national eingeschränkte Anwendung) der EN 16931. Sie ist der Standard im Geschäftsverkehr mit öffentlichen Auftraggebern (B2G) und kann sowohl in CII- als auch in UBL-Syntax vorliegen.
- ZUGFeRD (technisch verwandt mit dem französischen Factur-X) ist ein hybrides Format: eine PDF/A-3, in die ein CII-XML nach EN 16931 eingebettet ist. Man erhält also ein menschenlesbares PDF und die maschinenlesbaren Daten in einer einzigen Datei.
Wichtig zu wissen: Nicht jede ZUGFeRD-Variante genügt der deutschen E-Rechnungspflicht. Erst ab ZUGFeRD 2.0.1 und ab dem Profil EN 16931 (COMFORT) aufwärts ist der eingebettete Datensatz vollständig genug. Die schlankeren Profile MINIMUM und BASIC-WL enthalten nicht alle geforderten Angaben und reichen daher nicht aus.
Weil beide Formate dasselbe semantische Modell nutzen, sind sie untereinander und mit Lösungen aus anderen EU-Ländern kompatibel. Genau darin liegt der Wert der Norm: Ein Empfänger muss nicht wissen, mit welcher Software eine Rechnung erstellt wurde, um sie automatisiert zu verarbeiten.
Warum das für die Praxis zählt
Für Unternehmen bedeutet EN 16931 vor allem eines: verlässliche Automatisierung. Rechnungseingang, Prüfung und Verbuchung können ohne manuelles Abtippen laufen, Fehlerquellen sinken, und die grenzüberschreitende Zusammenarbeit wird einfacher. Voraussetzung ist allerdings, dass die Rechnung die Norm auch wirklich einhält, inklusive der Geschäftsregeln. Genau hier lohnt sich eine Prüfung vor dem Versand. Welche Pflichtangaben eine normkonforme Rechnung mitbringen muss, fassen wir in E-Rechnung: Diese Pflichtangaben müssen rein zusammen.
Fazit
EN 16931 ist das Fundament der E-Rechnung: ein semantisches Datenmodell aus Business Terms und Business Groups, zwei zulässige Syntaxen (CII und UBL) und darauf aufbauend die konkreten Formate XRechnung und ZUGFeRD. Wer dieses Fundament kennt, versteht schnell, warum strukturierte Daten so viel mächtiger sind als eine reine Bilddatei.
Ob Ihre ZUGFeRD-, Factur-X- oder XRechnung-Datei die EN-16931-Regeln tatsächlich erfüllt, können Sie mit dem kostenlosen Timelane E-Rechnungs-Validator prüfen: ohne Anmeldung, direkt im Browser, die Datei wird nur im Arbeitsspeicher geprüft und nicht gespeichert. Vertiefen können Sie das Thema anschließend in unserem Beitrag zu den Pflichtangaben einer E-Rechnung.
Dieser Beitrag ersetzt keine Rechts- oder Steuerberatung. Stand: 2026, Angaben ohne Gewähr.
