E-Rechnung Glossar: Die wichtigsten Begriffe verständlich erklärt

Wer sich mit der E-Rechnung beschäftigt, stolpert über eine Reihe von Abkürzungen und Fachbegriffen, die selten an einer Stelle erklärt werden. EN 16931, ZUGFeRD, XRechnung, BT-31, Schematron, Peppol, KoSIT – diese Begriffe tauchen in Artikeln, Beratungs-Materialien und Software-Dokumentationen auf, ohne dass jemand sie kurz und verständlich definiert.

Dieses Glossar holt das nach. Jeder Begriff wird in 2-4 Sätzen erklärt, mit einem Praxisbeispiel wo nützlich. Die Reihenfolge ist alphabetisch. Wer einen Begriff in den anderen Artikeln gelesen hat und nicht ganz weiß, was er bedeutet, findet hier die Antwort.

BR-Codes (Business Rules)

Die EN 16931 definiert Geschäftsregeln, die jede E-Rechnung erfüllen muss. Diese Regeln tragen Codes mit dem Präfix BR-. Beispiele: BR-01 (jede Rechnung muss eine Rechnungsnummer haben), BR-CO-17 (Nettosumme plus Umsatzsteuersumme muss exakt dem Bruttobetrag entsprechen).

Es gibt drei Klassen von BR-Codes:

• BR-XX für allgemeine Regeln aus der EN 16931
• BR-CO-XX für Konsistenz-Regeln (Constraints), die Zusammenhänge zwischen Feldern prüfen
• BR-DE-XX für nationale deutsche Sonderregeln (CIUS)

Wenn ein Validator einen BR-Code zurückgibt, weiß man genau, an welcher Stelle die Rechnung nicht konform ist. Die häufigsten Fehler haben wir im Fallstricke-Artikel zusammengefasst; eine Seite je Regel mit Ursache und Lösung steht im Fehler-Lexikon.

BT-Codes (Business Terms)

BT-Codes sind die einzelnen Datenfelder einer E-Rechnung nach EN 16931. Jedes Feld hat einen eindeutigen Code mit dem Präfix BT-. Beispiele: BT-1 ist die Rechnungsnummer, BT-2 das Ausstellungsdatum, BT-31 die Umsatzsteuer-IdNr. des Verkäufers, BT-48 die USt-IdNr. des Käufers.

Felder können auch in Gruppen organisiert sein. Diese Gruppen tragen das Präfix BG- (Business Group). Beispiel: BG-14 ist die Gruppe "Invoicing period" mit den Feldern BT-73 (Start) und BT-74 (Ende).

Wer eigene Software anbindet oder XML-Dateien direkt bearbeitet, wird häufig auf BT- und BG-Codes treffen. Die offizielle Liste umfasst rund 160 BT-Codes und etwa 25 BG-Gruppen.

CIUS (Core Invoice Usage Specification)

Eine CIUS ist eine nationale Spezialisierung der EN 16931. Sie schränkt die Norm ein oder ergänzt sie um Pflichtfelder, die in einem bestimmten Land notwendig sind. In Deutschland heißen die beiden offiziellen CIUS XRechnung (für Behörden-Rechnungen) und ZUGFeRD/Factur-X (auf dem EN-16931-Profil identisch zu XRechnung).

Eine CIUS darf die EN 16931 nicht verletzen, sondern nur einschränken. Was nach EN 16931 optional ist, kann eine CIUS als Pflicht definieren. Das deutsche Beispiel: Skonto wird über die nationale Regel BR-DE-18 in einem festen Format vorgeschrieben – diese Regel existiert in der EN 16931 selbst nicht, ist also eine CIUS-Erweiterung.

EDI (Electronic Data Interchange)

EDI bezeichnet den elektronischen Austausch strukturierter Geschäftsdokumente zwischen Unternehmen, basierend auf älteren Standards wie EDIFACT. EDI gibt es seit den 1970er Jahren und ist in großen Unternehmen für Bestellungen, Lieferscheine und Rechnungen etabliert.

Im Kontext der E-Rechnung relevant: Bis zum 31. Dezember 2027 dürfen Betriebe ihre eingespielten EDI-Verfahren weiter nutzen, auch wenn das EDI-Format technisch nicht der EN 16931 entspricht. Ab 2028 müssen aber auch EDI-Übermittlungen EN-16931-konform sein, sonst gelten sie nicht mehr als E-Rechnung im Sinne des UStG. Diese und die beiden anderen Fristen nebeneinander: Welche Übergangsregelungen 2026 und 2027 gelten.

EN 16931

Die europäische Norm EN 16931 definiert das semantische Datenmodell für elektronische Rechnungen in der EU. Sie ist die Grundlage aller in Deutschland zugelassenen E-Rechnungs-Formate (XRechnung, ZUGFeRD, Factur-X). Verabschiedet 2017, verpflichtende Grundlage für öffentliche Auftraggeber seit 2020, ab 2028 für jeden B2B-Umsatz in Deutschland Pflicht.

Wichtig zu wissen: EN 16931 schreibt nicht das exakte XML-Format vor, sondern definiert die Datenelemente (BT-Codes), Gruppen (BG-Codes) und Geschäftsregeln (BR-Codes). Konkret implementiert wird die Norm über zwei Syntax-Bindungen: UBL (Universal Business Language) und CII (Cross Industry Invoice). XRechnung kann beide Syntaxen nutzen, ZUGFeRD basiert auf CII.

Factur-X

Factur-X ist das französisch-deutsche Geschwister-Format zu ZUGFeRD. Technisch sind ZUGFeRD und Factur-X auf dem EN-16931-Profil identisch. Der Unterschied liegt nur im Namen – die deutsche Bezeichnung ist ZUGFeRD, die französische Factur-X.

Wer Rechnungen an französische B2B-Kunden schickt, wird oft hören, dass Factur-X gefordert ist. In der Praxis ist eine ZUGFeRD-Datei nach EN 16931 für solche Kunden vollständig nutzbar – die Datei kann auf beide Namen lauten.

GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff)

Die GoBD sind ein BMF-Schreiben, das die Anforderungen an die elektronische Buchführung in Deutschland definiert. Für E-Rechnungen relevant sind vor allem die Anforderungen an die revisionssichere Archivierung: unveränderbar gespeichert, jederzeit verfügbar, im Originalformat, mit Audit-Trail.

Die aktuelle Fassung der GoBD stammt vom 14. Juli 2025 und enthält erstmals explizite Hinweise zur Aufbewahrung von E-Rechnungen. Konkret: Die strukturierte XML muss im Originalzustand erhalten bleiben. Eine ausgedruckte Version oder als PDF gespeicherte Darstellung reicht nicht.

Mehr zur GoBD-konformen Archivierung haben wir im Empfangs-Artikel beschrieben. Ob eine aus einer PDF erzeugte Rechnung die GoBD erfüllt und was dabei zusätzlich zu dokumentieren ist, steht unter Erfüllt eine umgewandelte E-Rechnung die GoBD.

KoSIT (Koordinierungsstelle für IT-Standards)

Die KoSIT ist eine deutsche Einrichtung der öffentlichen Hand, die IT-Standards für Verwaltung und Wirtschaft koordiniert. Sie ist verantwortlich für die XRechnung und entwickelt das offizielle Schematron-Regelwerk, das alle deutschen Validatoren intern nutzen.

Der KoSIT-Validator ist die Referenz-Implementierung zur Prüfung von E-Rechnungen. Er steht kostenlos zur Verfügung, läuft als Java-Anwendung lokal und gilt als der offizielle Maßstab – wer dem KoSIT-Validator besteht, hat eine technisch korrekte E-Rechnung. Viele kommerzielle Tools (auch unser eigener E-Rechnungs-Validator) basieren intern auf dem KoSIT-Regelwerk.

Leitweg-ID

Die Leitweg-ID ist eine Adressierungs-Kennung für E-Rechnungen an öffentliche Auftraggeber in Deutschland. Sie identifiziert die zuständige Behörde oder den richtigen Eingang innerhalb der Verwaltung.

Format: Eine Leitweg-ID besteht aus mehreren Segmenten, getrennt durch Bindestriche, und beginnt mit dem Bundesland-Code. Beispiel: 04011000-12345-99 für eine Behörde in Bremen.

Bei XRechnungen an Behörden ist die Leitweg-ID im Feld BT-10 (Buyer reference) Pflicht. Ohne sie kann die Rechnung nicht zugestellt werden. Woher man sie bekommt und wie die Segmente aufgebaut sind, steht im Artikel zur Leitweg-ID.

Mustang (Mustangproject)

Mustang ist die wichtigste Open-Source-Bibliothek für die Verarbeitung von ZUGFeRD- und XRechnung-Dateien. Sie ist in Java geschrieben und unter Apache-Lizenz frei verfügbar. Sie kann E-Rechnungen erzeugen, lesen, validieren und konvertieren.

Im Hintergrund vieler kommerzieller Tools läuft Mustang – sie ist das technische Rückgrat des deutschen E-Rechnungs-Ökosystems. Wir nutzen Mustang ebenfalls in unserem ZUGFeRD/XRechnung-Service, in der aktuellen Version 2.23 (die ZUGFeRD 2.4 und XRechnung 3.0.2 unterstützt).

Für Endnutzer ohne Programmier-Hintergrund ist Mustang direkt nicht nutzbar – es ist eine Bibliothek für Entwickler. Aber wer einen E-Rechnung-Service nutzt, der mit Mustang im Hintergrund arbeitet, profitiert indirekt von der ausgereiften Validierung.

OCR (Optical Character Recognition)

OCR ist Texterkennung: Aus einem Bild werden Zeichen, aus Zeichen wird Text. Für E-Rechnungen ist das nur der halbe Weg, denn eine E-Rechnung besteht nicht aus Text, sondern aus benannten Feldern (BT-Codes). Wer aus einer PDF eine ZUGFeRD-Datei macht, braucht deshalb eine Zuordnung von Angaben zu Feldern, und die leistet klassische OCR nicht.

In der Praxis wird der Begriff trotzdem für den ganzen Vorgang verwendet. Was dabei tatsächlich passiert und wo echte OCR sinnvoll bleibt (nämlich bei alphanumerischen Codes wie IBAN und USt-IdNr. im Rechnungseingang), steht unter Ist die Umwandlung eine OCR-Erkennung.

OZG-RE (Online-Zugangsgesetz-Rechnungseingang)

OZG-RE ist die zentrale Plattform der Bundesverwaltung für den Eingang von E-Rechnungen. Wer an den Bund oder bestimmte Bundesbehörden Rechnungen stellt, kann diese über das OZG-RE-Portal einreichen.

Erreichbar ist OZG-RE über die Webseite xrechnung.bund.de. Lieferanten können sich dort kostenlos registrieren und Rechnungen per Web-Formular, per E-Mail oder per Peppol-Anbindung einreichen. Die Plattform leitet die Rechnung an den zuständigen Empfänger weiter.

Wichtig: OZG-RE ist nur für den Bund zuständig. Bundesländer und Kommunen betreiben oft eigene Portale (zum Beispiel ZRE Berlin oder das Bayern-Portal). Welches Portal wann greift und was der BDR damit zu tun hat, klärt der BDR-Leitfaden.

Peppol (Pan-European Public Procurement Online)

Peppol ist ein internationales Netzwerk für den Austausch von Geschäftsdokumenten zwischen Unternehmen und öffentlichen Auftraggebern. Es wurde ursprünglich für die EU-weite öffentliche Beschaffung entwickelt und wird zunehmend auch im B2B-Bereich genutzt.

Peppol funktioniert über sogenannte "Access Points" – Dienstleister, die zwischen den Endpunkten vermitteln. Wer sich an Peppol anbindet, kann an alle anderen Peppol-Teilnehmer in Europa Rechnungen senden, ohne für jeden Empfänger eine eigene Verbindung aufbauen zu müssen.

Im deutschen Mittelstand ist Peppol noch nicht weit verbreitet. Große Konzerne und der öffentliche Sektor nutzen es zunehmend. Wer regelmäßig ins EU-Ausland liefert, sollte Peppol mittelfristig auf dem Radar haben.

Schattenrechnungen

Schattenrechnungen sind Rechnungen, die das führende System eines Unternehmens nicht abbilden kann und die deshalb außerhalb davon entstehen, meist in Word oder Excel. Sie sind kein Organisationsversagen, sondern die Restmenge, die praktisch jedes ERP produziert.

Typische Fälle: Weiterberechnungen an Mieter, Partner oder Tochtergesellschaften, Mischkalkulationen, einmalige Sonderleistungen, Abrechnungen für einen Geschäftsvorfall, den das System nie kennengelernt hat. Im kleinen Betrieb ist es dieselbe Lücke in kleinerem Maßstab: Die Branchensoftware kann keine E-Rechnung, und der Hersteller rüstet sie nicht nach.

Der Begriff steht in keinem Gesetz und in keiner Norm, er benennt eine Kategorie. Praktisch relevant wird sie mit der Versandpflicht: Ab 1. Januar 2027 (Unternehmen über 800.000 Euro Gesamtumsatz im Vorjahr) beziehungsweise ab 1. Januar 2028 (alle übrigen) müssen auch diese Rechnungen der EN 16931 entsprechen, obwohl das Programm, mit dem sie geschrieben werden, das nicht leistet. Ausführlich mit den drei möglichen Wegen: Schattenrechnungen. Einzelne Fragen dazu: Gibt es E-Rechnungs-Software, die ohne ERP funktioniert und Was ist eine Standalone-Lösung.

Schematron

Schematron ist eine Sprache zur Formulierung von Validierungsregeln für XML-Dokumente. Sie ist ein offener Standard (ISO/IEC 19757-3) und wird im Kontext der E-Rechnung verwendet, um die EN-16931-Geschäftsregeln (BR-Codes) maschinell prüfbar zu machen.

Konkret: Die KoSIT veröffentlicht ein Schematron-Regelwerk, das alle EN-16931-Regeln plus die deutschen CIUS-Regeln enthält. Wenn ein Validator eine E-Rechnung prüft, wird die XML-Datei gegen dieses Schematron-Regelwerk laufen gelassen. Jede gefundene Verletzung wird mit dem entsprechenden BR-Code gemeldet.

Standalone-Lösung

Eine Software für E-Rechnungen, die für sich arbeitet, statt als Modul im führenden System zu stecken. Sie setzt kein ERP voraus, verlangt keinen Eingriff in vorhandene Programme und keinen Zugang zu einem Rechnungsnetzwerk. Der Begriff beschreibt die Bauart, nicht den Funktionsumfang.

Abgegrenzt wird er gegen drei andere Bauarten: das Modul des ERP- oder Branchensoftware-Herstellers, den Netzwerk- oder Clearing-Anbieter und die Erweiterung im Buchhaltungssystem. Ausführlich: Was ist eine Standalone-Lösung für E-Rechnungen.

ViDA (VAT in the Digital Age)

ViDA ist eine EU-Initiative zur Modernisierung des Mehrwertsteuersystems. Sie umfasst drei Säulen: digitale Berichtspflichten (ab 2030), Plattform-Wirtschaft (ab 2028) und Single VAT Registration (ab 2025).

Für die E-Rechnung relevant: Mit ViDA sollen ab 2030 für grenzüberschreitende EU-B2B-Umsätze elektronische Rechnungen verpflichtend werden, kombiniert mit einem digitalen Echtzeit-Meldesystem an die Finanzverwaltung. Deutschland hat mit der nationalen E-Rechnungs-Pflicht ab 2025/2027/2028 bereits einen Vorlauf zu ViDA.

Wer heute auf die deutsche Pflicht umstellt, ist gut auf ViDA vorbereitet. Wer noch nicht umgestellt hat, wird spätestens 2030 doppelten Anpassungsdruck haben.

Validierungsbericht

Ein Validierungsbericht ist die strukturierte Ausgabe eines Validators, der eine E-Rechnung gegen EN 16931 und die deutschen CIUS-Regeln geprüft hat. Er enthält:

• Ob die Rechnung das Schema (XML-Struktur) erfüllt
• Welche BR-Codes verletzt wurden (mit konkreter Feld-Referenz)
• Welche Warnungen ausgegeben wurden (formal okay, aber suboptimal)

Das BMF-Schreiben vom 15. Oktober 2025 empfiehlt ausdrücklich, eingehende E-Rechnungen technisch zu validieren und den Validierungsbericht als Nachweis zu archivieren. Bei einer Betriebsprüfung kann der Bericht zeigen, dass die Rechnung formal in Ordnung war, was den Vorsteuerabzug absichert. Wie ein Validator arbeitet und wie man seine Meldungen liest, erklärt der Validator-Artikel.

XRechnung

XRechnung ist die deutsche CIUS-Implementierung der EN 16931 als reines XML-Format – ausführlich erklärt unter Was ist eine XRechnung, mit einem kommentierten Beispiel im Artikel zum Aufbau einer XRechnung. Aktuelle Version ist 3.0.2 (letzter Bugfix-Release am 31. Januar 2026). XRechnung wird seit 2020 für Rechnungen an Behörden auf Bundesebene gefordert und ist seit 2025 eines der beiden zugelassenen E-Rechnungs-Formate für den B2B-Bereich.

Für Mitte bis Ende 2026 ist XRechnung 4.0 angekündigt – eine Major-Version, die die aktualisierte EU-Norm EN 16931-1:2026 (im Februar 2026 von CEN beschlossen) umsetzt. XRechnung 4.0 erlaubt unter anderem Sammelrechnungen mit mehreren Bestellungen und Lieferungen in einer einzigen Rechnung. Ein konkretes Release-Datum gibt es noch nicht. Bis dahin bleibt 3.0.2 gültig.

Charakteristisch ist die fehlende visuelle Darstellung: Eine XRechnung ist nur eine XML-Datei. Wer sie lesen will, braucht einen Viewer oder Buchhaltungssoftware. Unser kostenloser XRechnungs-Viewer macht XRechnungen menschenlesbar; die Wege dorthin sammelt der Artikel XRechnung öffnen.

XRechnung kann in zwei Syntaxen vorliegen: UBL (Universal Business Language) und CII (Cross Industry Invoice). Beide sind gleichwertig, UBL wird in der öffentlichen Verwaltung etwas häufiger genutzt.

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland)

ZUGFeRD ist das deutsche Hybrid-Format für E-Rechnungen: eine PDF/A-3-Datei mit eingebetteter XML, die der EN 16931 entspricht. Profile, Aufbau und rechtlicher Rahmen stehen im ZUGFeRD-Leitfaden. Aktuelle Version ist 2.4, veröffentlicht am 4. Dezember 2025 und in Kraft seit 15. Januar 2026. ZUGFeRD ist neben XRechnung das zweite in Deutschland zugelassene E-Rechnungs-Format für den B2B-Bereich.

Die nachfolgende Version ZUGFeRD 2.5 (mit Unterstützung für Brutto-Rechnungen, relevant für Buchhandel, Verlagswesen und Mineralölbranche) wird in zwei Schritten veröffentlicht: der erste Teil am 10. Juni 2026 (aktualisierte Codelisten, FR-B2B-Anforderungen), der zweite Teil mit den Brutto-Rechnungen folgt später im Jahr.

Der Vorteil von ZUGFeRD: Die PDF-Schicht zeigt die Rechnung wie eine normale PDF, die XML-Schicht enthält die strukturierten Daten für automatische Verarbeitung. Das macht den Übergang von PDF-Rechnungen zur strukturierten E-Rechnung deutlich entspannter.

Eine wichtige Falle: Bei Abweichungen zwischen PDF-Inhalt und eingebetteter XML gilt steuerlich nur die XML. Wer eine ZUGFeRD-Datei akzeptiert, sollte deshalb prüfen, ob beide Schichten konsistent sind. Mehr zum Format-Vergleich gibt es im Artikel über ZUGFeRD und XRechnung im Vergleich.

Welche Begriffe fehlen?

Dieses Glossar deckt die Begriffe ab, die im Kontext der ab 2025/2027/2028 geltenden deutschen E-Rechnungs-Pflicht regelmäßig auftauchen. Wenn dir ein wichtiger Begriff fehlt, sag uns gerne Bescheid – wir ergänzen das Glossar laufend.

Für eine konkrete Orientierung, wie die einzelnen Begriffe in der Praxis zusammenspielen, helfen unsere anderen Artikel:

• E-Rechnung-Pflicht 2027 oder 2028 – Zeitachse und Grenzfälle
• Welche Lösung passt zu welchem Betrieb – Vergleich der drei Wege
• Die 5 häufigsten EN-16931-Fallstricke – typische Fehler in der Praxis
• E-Rechnungen empfangen – was eine gute Empfangslösung leistet