Wenn Ihnen schon einmal gesagt wurde, dass Ihre Rechnung im gültigen XML-Format vorliegt, sie aber trotzdem abgelehnt wurde: Wir kennen das. Standards für die E-Rechnung bestehen aus mehreren Ebenen. Um Prozesse und Transaktionen im Griff zu behalten, ist es entscheidend, Semantik und Syntax von E-Rechnungen zu unterscheiden.
Wir erklären jede Ebene Schritt für Schritt. So erkennen Sie an jeder E-Rechnungsformatbezeichnung genau, was sie aussagt (und was nicht).
Kurz erklärt
- Die Semantik legt fest, was eine E-Rechnung enthalten muss und was jedes Datenfeld bedeutet
- Die Syntax legt fest, wie diese Inhalte in einer maschinenlesbaren Datei dargestellt werden
- EN 16931 ist die europäische Norm für die Semantik der E-Rechnung und nutzt zwei Syntaxen: UBL und CII
- Eine CIUS wie XRechnung oder Peppol BIS Billing 3.0 verschärft die Kernregeln für ein Land oder Netzwerk
- Die Validierung prüft beide Ebenen. Deshalb kann auch eine wohlgeformte XML-Datei abgelehnt werden
- Ein betreuter Ansatz kann die Unterstützung mehrerer Standards für die E-Rechnung in Ihrer ERP-Landschaft vereinfachen
Warum Standards für die E-Rechnung verwirrend wirken können
Fragen Sie fünf Personen, welches Format für elektronische Rechnungen ihr Unternehmen nutzt, erhalten Sie vielleicht fünf Antworten: XML, UBL, Peppol, XRechnung oder EN 16931. Überraschenderweise könnten alle recht haben. Denn diese Begriffe stehen nicht für fünf konkurrierende Optionen. Sie beschreiben verschiedene Ebenen derselben Rechnung.
Das ist ein bisschen so, als würden Sie jemanden fragen, was er gerade liest, und die Antwort wäre: „Englisch“, „ein Taschenbuch“ und „ein Krimi“. Jede Antwort stimmt, beantwortet aber eine andere Frage.
Da E-Rechnungspflichten weltweit zunehmend zur Norm werden, ist es unerlässlich, das Zusammenspiel dieser Ebenen zu verstehen. Jede dieser gesetzlichen Vorgaben verweist auf Standards für die E-Rechnung, aber selten auf dieselbe Weise.
Semantik und Syntax: der Unterschied einfach erklärt
Diese beiden Begriffe bilden den Kern jedes Standards für die E-Rechnung:
- Die Semantik beschreibt, was die Rechnung aussagt: Welche Angaben erforderlich sind, was jedes Feld bedeutet, wie oft es vorkommen darf und wie Beträge zusammenpassen müssen
- Die Syntax beschreibt, wie die Angaben dargestellt werden: Elementnamen, Struktur und Reihenfolge in der Datei
Denken Sie an ein deutsches Rezept und seine französische Übersetzung. Zutaten, Mengen und Arbeitsschritte (die Semantik) bleiben gleich. Nur Sprache und Gestaltung (die Syntax) ändern sich. Stimmt die Übersetzung, entsteht dasselbe Gericht. E-Rechnungen funktionieren genauso.
Nehmen wir das Rechnungsdatum. EN 16931 bezeichnet es als Geschäftsbegriff BT-2, „Rechnungsdatum“. So sieht es in den beiden wichtigsten Syntaxen aus:
Ein Geschäftsterm · Zwei Syntaxen
Gleiche Bedeutung. Andere Syntax.
Geschäftsbegriff BT-2 in EN 16931: Rechnungsdatum
UBL
Datum im Format YYYY-MM-DD
<cbc:IssueDate>2026-10-29</cbc:IssueDate>CII
Datum im Format YYYYMMDD
<ram:IssueDateTime>
<udt:DateTimeString format="102">
20261029
</udt:DateTimeString>
</ram:IssueDateTime>Fazit: Beide Beispiele stellen dasselbe Rechnungsdatum – den 29. Oktober 2026 – in unterschiedlichen XML-Strukturen dar.
Gleiche Bedeutung, andere Syntax. Daraus ergeben sich zwei praktische Faustregeln:
- Zwei Dateien können völlig unterschiedlich aussehen und dennoch exakt dieselbe Rechnung enthalten
- Zwei Dateien können dieselbe Syntax nutzen und dennoch völlig unterschiedlichen Regeln folgen
Mit diesen Faustregeln lassen sich die meisten Formatdiskussionen leichter nachvollziehen.
EN 16931: die europäische Norm für die Bedeutung der E-Rechnungsdaten
EN 16931 ist die europäische Norm für die elektronische Rechnungsstellung. Das Europäische Komitee für Normung (CEN) veröffentlichte sie 2017 im Zuge der Richtlinie 2014/55/EU. Diese verpflichtete Behörden EU-weit zur Annahme elektronischer Rechnungen. Spätestens seit 2020 müssen alle öffentlichen Auftraggeber in der EU E-Rechnungen empfangen, die dieser Norm entsprechen.
Im Mittelpunkt steht ein semantisches Datenmodell für eine „Kernrechnung“. Es besteht aus:
- Geschäftstermen (BT): einzelne Angaben, etwa BT-1 Rechnungsnummer oder BT-31 Umsatzsteuer-Identifikationsnummer des Verkäufers
- Geschäftsbegriffsgruppen (BG): zusammengefasste, verwandte Begriffe, etwa BG-4 Verkäufer oder BG-25 Rechnungsposition
- Geschäftsregeln (BR): Prüfungen zur Datenkonsistenz, etwa BR-CO-10: Die Summe aller Nettobeträge der Rechnungspositionen muss der Gesamtsumme auf Dokumentebene entsprechen
Jeder Geschäftsbegriff hat zudem eine Definition, einen Datentyp und eine Kardinalität (wie oft er vorkommen darf oder muss).
EN 16931 besteht wiederum aus mehreren Teilen. EN 16931-1 definiert das semantische Modell, CEN/TS 16931-2 nennt die zugelassenen Syntaxen. CEN/TS 16931-3 ordnet jedem Geschäftsterm die jeweiligen Syntaxelemente zu.
Wichtig ist auch: Die Norm entwickelt sich weiter. Da ViDA bei der E-Rechnung innerhalb der EU auf EN 16931 aufbaut, erweitert CEN die Norm um weitere B2B-Szenarien.
Drei zentrale Erkenntnisse sollten Sie aus diesem Artikel mitnehmen:
- EN 16931 ist syntaxneutral: Die Norm definiert die Bedeutung, UBL oder CII übernehmen die Darstellung
- Sie beschreibt eine Kernrechnung und deckt ab, was die meisten Rechnungen benötigen, nicht jede nationale Besonderheit
- Sie regelt nicht den Transport: Normkonformität sagt nichts darüber aus, wie die Rechnung zum Kunden gelangt
UBL und CII: die zwei wichtigsten XML-Formate für E-Rechnungen
Vor den Syntaxen noch kurz zu XML. Extensible Markup Language (XML) ist eine allgemeine Schreibweise für strukturierte Daten. XML kennt weder Rechnungen noch Steuern oder Umsatzsteuer. „Wir versenden XML-Rechnungen“ ist daher ähnlich vage wie „Wir schreiben mit Buchstaben“. Die naheliegende Rückfrage lautet: Welches XML?
Für EN 16931 gibt es zwei Antworten:
- UBL (Universal Business Language): entwickelt vom internationalen Standardisierungskonsortium OASIS; für Rechnungen und Gutschriften nach EN 16931 in Version 2.1 verwendet
- Branchenübergreifende Rechnung (CII): entwickelt von UN/CEFACT, dem UN-Gremium für Handelserleichterung; für EN 16931 in Version D16B verwendet
| UBL | CII | |
| Gepflegt von | OASIS | UN/CEFACT |
| Version für EN 16931 | UBL 2.1 | D16B |
| Rechnungen und Gutschriften | Getrennte Dokumenttypen | Ein Dokumenttyp mit Typcode |
| Anwendungsfälle | Peppol BIS Billing 3.0, XRechnung (UBL-Variante), Peppol-basierte Spezifikationen usw. | Factur-X, ZUGFeRD, XRechnung (CII-Variante) usw. |
Welche Syntax ist besser? Keine von beiden. Beide bilden dieselbe EN-16931-Semantik ab. Entscheidend ist, welche Syntax Kunden, Netzwerk oder gesetzliche Vorgabe akzeptieren. Deutschland akzeptiert XRechnung beispielsweise in UBL und CII.
Im Programmcode sind beide jedoch nicht einfach austauschbar. Elementnamen, Verschachtelung und Steuerstrukturen unterscheiden sich. Ein UBL-Parser kann daher CII nicht lesen. Da die Bedeutung gleich bleibt, kann ein durchdachtes Mapping Kernrechnungsinhalte jedoch ohne Informationsverlust von einer Syntax in die andere umwandeln.
CIUS und Erweiterungen: Anpassungen für Länder und Netzwerke
EN 16931 bietet allen dieselbe Grundlage. Länder, Netzwerke und Branchen benötigen jedoch oft mehr. Dafür gibt es CIUS und Erweiterungen.
Eine Kernrechnungsanwendungsspezifikation (CIUS) verschärft die Regeln der Kernrechnung. EN 16931 ist wie eine Kleiderordnung mit „gehobener Freizeitkleidung“. Eine CIUS ergänzt für eine Veranstaltung: „Sakko erforderlich“. Eine CIUS kann …
- optionale Geschäftsterme verpflichtend machen
- zulässige Werte aus Codelisten einschränken
- zusätzliche Validierungsregeln hinzufügen
Neue Informationen hinzufügen kann eine CIUS nicht. Jede CIUS-konforme Rechnung entspricht automatisch auch EN 16931. Empfänger, die nur den Kern unterstützen, können sie daher verarbeiten.
Gängige Beispiele sind:
– Peppol BIS Billing 3.0: die UBL-basierte CIUS im Peppol-Netzwerk
– XRechnung: Deutschlands CIUS mit verpflichtender Käuferreferenz (BT-10), verfügbar in UBL und CII
– NLCIUS: die niederländische CIUS für Rechnungen an den öffentlichen Sektor der Niederlande
Hybridformate wie Factur-X und ZUGFeRD nutzen dieselbe Grundlage. Sie betten CII-XML in eine PDF/A-3-Datei ein. So können Menschen und Software die Rechnung lesen. Ihr EN-16931-Profil folgt dem Kern, das Profil EXTENDED geht darüber hinaus. Damit kommen wir zu Erweiterungen.
Eine Erweiterung bewirkt das Gegenteil einer CIUS. Sie ergänzt Informationen außerhalb des Kerns, meist für nationale Anforderungen oder Branchenprozesse. Erweiterungen lösen lokale Probleme. Beide Seiten müssen sie jedoch unterstützen, was die Interoperabilität einschränkt. Deshalb setzen Spezifikationen sie sparsam ein.
Jede Rechnung gibt dem Empfänger schließlich an, welchen Regeln sie folgt. Die Spezifikationskennung (BT-24, CustomizationID in UBL) benennt die CIUS oder Erweiterung, der Geschäftsprozesstyp (BT-23, ProfileID in UBL) den Prozess. Sind diese Werte falsch, kann eine einwandfreie Rechnung anhand falscher Regeln geprüft werden und die Prüfung nicht bestehen.
Wie die Ebenen zusammenwirken
Alle Ebenen im Überblick, von allgemein bis spezifisch:
| Ebene | Beantwortete Frage | Beispiele |
| Notation | Wie werden Daten grundsätzlich dargestellt? | XML |
| Syntax | Welche Elementnamen und Struktur werden verwendet? | UBL 2.1, CII D16B |
| Semantik | Was muss die Rechnung enthalten und bedeuten? | EN 16931 |
| CIUS oder Erweiterung | Was verschärft oder ergänzt das Land oder Netzwerk? | Peppol BIS Billing 3.0, XRechnung, NLCIUS usw. |
| Transport | Wie gelangt die Rechnung zum Empfänger? | Peppol-Netzwerk, staatliche Plattformen usw. |
Peppol zeigt gut, warum die Ebenen wichtig sind. Es wird oft als Format bezeichnet, ist aber ein Netzwerk mit eigenen Spezifikationen. Wie diese auf EN 16931 aufbauen, zeigt die offizielle Dokumentation zu Peppol BIS Billing 3.0.
Eine neue Formatbezeichnung für E-Rechnungen lässt sich in vier Schritten einordnen:
- Syntax bestimmen (UBL, CII oder eine andere)
- Semantisches Modell prüfen (EN 16931 oder ein nationales Modell)
- CIUS oder Erweiterung samt aktueller Version ermitteln
- Klären, wie die Rechnung übermittelt werden muss
Warum der Unterschied für Ihr Projekt zur E-Rechnung wichtig ist
Bei der Validierung einer Rechnung werden beide Ebenen geprüft:
- Die Schemavalidierung (XSD) prüft die Syntax und bestätigt, dass das XML wohlgeformt ist und die richtigen Elemente verwendet
- Die Schematron-Validierung prüft die Semantik anhand der EN-16931-Geschäftsregeln und zusätzlicher CIUS-Regeln
Eine bestandene Schemaprüfung belegt nur die Lesbarkeit der Datei. Die Annahme hängt von den Geschäftsregeln ab.
Angenommen, Sie beliefern Kunden in zwei Ländern und senden beiden dieselben ERP-Ausgabedaten. Im ersten Land genügt Peppol BIS Billing 3.0 ohne Anpassungen. Ihre Rechnungen werden direkt angenommen. Ihr öffentlicher Auftraggeber in Deutschland erwartet XRechnung mit verpflichtender Käuferreferenz. Ihre Rechnung entspricht EN 16931, wird aber wegen der fehlenden Käuferreferenz abgelehnt. Gleiche Daten, andere Regeln.
Mehr zur Validierung von E-Rechnungen erfahren Sie in unserem Artikel „Wie validiert man eine XRechnung?“.
Übertragen Sie das auf 15 Länder, die Spezifikationen und Codelisten jeweils nach eigenem Zeitplan aktualisieren. Die eigentliche Arbeit hinter der Compliance bei der E-Rechnung: mit immer zahlreicheren, stetig veränderten internationalen Standards für die E-Rechnung Schritt halten.
Wie ecosio mehrere Standards für die E-Rechnung handhabbar macht
Die länderübergreifende Verwaltung der E-Rechnung wird komplexer, wenn verschiedene Gesellschaften unterschiedliche ERP-Systeme nutzen. Jedes System muss die richtigen Rechnungsdaten liefern, während Formate, Validierungsregeln und Übermittlungsvorgaben je nach Markt variieren.
Die Lösung Global E-Invoicing Compliance von ecosio hilft, die Integration in Ihrer bestehenden ERP-Landschaft zu vereinfachen. ecosio konvertiert Rechnungsdaten in die erforderlichen Formate, validiert sie anhand geltender Regeln und übermittelt Rechnungen über das jeweilige Netzwerk, die staatliche Plattform oder den vereinbarten Kanal.
Für Ihr Team bedeutet das:
- Unterstützung mehrerer Formate für die E-Rechnung, darunter Peppol BIS Billing 3.0, XRechnung und Factur-X
- Weniger interner Aufwand für länderspezifische Mappings und Anpassungen an neue Anforderungen
- Einblick in die Rechnungsverarbeitung und Validierungsergebnisse
- Unterstützung durch das Fachteam von ecosio bei regulatorischen und technischen Änderungen in unterstützten Ländern
Wächst Ihr Unternehmen oder ändern sich Anforderungen, hilft dieser betreute Ansatz Ihren Teams, Prozesse für die E-Rechnung marktübergreifend aufrechtzuerhalten – ohne einen Flickenteppich lokaler Lösungen aufzubauen. Mehr zu anstehenden Änderungen und zur Vorbereitung erfahren Sie in unserem Artikel über Mehrwertsteuer im digitalen Zeitalter (ViDA).
Standards für die E-Rechnung verstehen
Wenn Sie Semantik und Syntax trennen, wirken Standards für die E-Rechnung weit weniger abschreckend. EN 16931 legt fest, was eine Rechnung enthalten muss, UBL und CII bestimmen die Darstellung. Eine CIUS ergänzt lokale Regeln. Der Transport ist eine separate Frage.
Trennen Sie diese Ebenen in Ihren Systemen klar, müssen Sie bei neuen gesetzlichen Vorgaben nur die passenden Regeln anwenden – statt neu anzufangen.
Wie schneiden Ihre Rechnungen ab? Prüfen Sie eine Datei mit unserem kostenlosen Validator für Peppol, E-Rechnungen und XML. Oder besprechen Sie mit unserem Fachteam, wie Global E-Invoicing Compliance Ihre Einführung unterstützen kann.
FAQs
Was ist der Unterschied zwischen Semantik und Syntax bei E-Rechnungen?
Die Semantik legt fest, welche Angaben eine Rechnung enthält und was diese bedeuten. Die Syntax bestimmt, wie die Angaben in einer maschinenlesbaren Datei dargestellt werden.
Was ist EN 16931?
EN 16931 ist die europäische Norm für die elektronische Rechnungsstellung. Sie definiert ein semantisches Datenmodell für die Kernbestandteile einer E-Rechnung, beispielsweise Rechnungsnummer, Rechnungsdatum und Beträge.
Was ist der Unterschied zwischen UBL und CII?
UBL und CII sind zwei XML-Syntaxen, mit denen sich E-Rechnungsdaten darstellen lassen. Sie verwenden unterschiedliche Strukturen und Elementnamen, können aber beide das semantische Modell von EN 16931 abbilden.
Warum wird eine E-Rechnung trotz gültigem XML abgelehnt?
Eine Rechnung kann syntaktisch gültig sein und dennoch gegen fachliche Regeln verstoßen. Beispielsweise kann eine verpflichtende Käuferreferenz fehlen oder ein Betrag nicht den geltenden Prüfregeln entsprechen. Welche Regeln geprüft werden, hängt unter anderem vom verwendeten Standard und den Anforderungen des Empfängers ab.
