E‑Rechnung-Glossar 2026: 60 Begriffe einfach erklärt – von XRechnung bis Peppol

XRechnung, ZUGFeRD, EN 16931, Peppol, Leitweg-ID: Rund um die E-Rechnung begegnen Unternehmen vielen Begriffen, die ähnliche Dinge zu beschreiben scheinen. Tatsächlich geht es mal um ein Dateiformat, mal um eine Vorschrift, ein einzelnes Datenfeld oder den Versand. Dieses E-Rechnung-Glossar erklärt 60 wichtige Begriffe, zeigt ihre Zusammenhänge und übersetzt technische Meldungen in konkrete Arbeitsschritte.

Fachlicher Stand: 17. September 2026. Allgemeine Orientierung für Deutschland; Sonderfälle und die steuerliche Behandlung einzelner Umsätze benötigen eine gesonderte Prüfung.

Vier Ebenen, die man auseinanderhalten sollte

Merksatz: Eine Rechnung kann gleichzeitig eine XRechnung sein, UBL verwenden, auf EN 16931 beruhen und über Peppol verschickt werden. Die Wörter konkurrieren nicht miteinander: Sie beschreiben verschiedene Eigenschaften desselben Vorgangs.

Alle 60 Begriffe alphabetisch nachschlagen

• Access Point
• API – Programmierschnittstelle
• Archivierung und Aufbewahrungsfrist
• B2B – Business to Business
• B2C – Business to Consumer
• B2G – Business to Government
• Bestellreferenz (BT-13)
• BG – Business Group
• BT – Business Term
• Buyer Reference – Käuferreferenz (BT-10)
• CII – Cross Industry Invoice
• CIUS – Core Invoice Usage Specification
• Digitale Signatur
• E-Rechnung
• E-Rechnungspflicht und Übergangsfristen
• EDI – Electronic Data Interchange
• Einheitencode
• EN 16931
• Endpoint-ID und elektronische Adresse
• Factur-X
• Geschäftsregel
• GoBD
• Gutschrift und Credit Note
• Hybridrechnung
• Kardinalität und Pflichtfeld
• Kleinunternehmer
• Leistungsdatum und Leistungszeitraum
• Leitweg-ID
• Mapping
• OCR – optische Zeichenerkennung
• Originaldatei
• OZG-RE
• PDF/A-3
• Peppol
• Peppol BIS Billing
• Profil
• Rechnungskorrektur
• Rechnungsnummer (BT-1)
• Reverse Charge
• Rundung und Rundungsbetrag
• Schematron
• Sonstige Rechnung
• Steuerbefreiungsgrund
• Syntax
• UBL – Universal Business Language
• Umsatzsteuer-Identifikationsnummer
• Umsatzsteuerkategorie
• Umsatzsteuersatz
• Validierung
• Validierungsbericht
• Verfahrensdokumentation
• Version und Release-Bundle
• ViDA – VAT in the Digital Age
• Viewer und Visualisierung
• XML – Extensible Markup Language
• XRechnung
• XSD – XML Schema Definition
• Zahlbetrag (BT-115)
• Zahlungsmittelcode (BT-81)
• ZUGFeRD

XRechnung, ZUGFeRD, PDF und Peppol: der Schnellvergleich

Grundlagen, Pflichten und Geschäftspartner

E-Rechnung

Eine E-Rechnung enthält Rechnungsangaben in einer festgelegten Datenstruktur, die Software verarbeiten kann. Entscheidend ist nicht der Versand per E-Mail, sondern der Aufbau des Inhalts. Im deutschen Umsatzsteuerrecht kommen insbesondere EN-16931-konforme Formate infrage; auch vereinbarte interoperable Formate können die gesetzlichen Voraussetzungen erfüllen. Ein Foto einer Rechnung ist deshalb noch keine E-Rechnung. Rechtsgrundlage: § 14 Absatz 1 UStG.

Sonstige Rechnung

Als sonstige Rechnung bezeichnet das Umsatzsteuergesetz Rechnungen auf Papier oder in elektronischen Formaten außerhalb der gesetzlichen E-Rechnungsdefinition. Dazu zählt typischerweise ein normales PDF ohne strukturierte Rechnungsdaten. „Sonstige“ bedeutet nicht automatisch unzulässig: Ob eine solche Rechnung ausgestellt werden darf, hängt vom Geschäft, von Ausnahmen und vom Übergangszeitraum ab. Dateiformat und rechtliche Zulässigkeit sind deshalb getrennt zu prüfen. Einordnung des BMF.

B2B – Business to Business

B2B bezeichnet Geschäfte zwischen Unternehmen. Ein selbstständiger Übersetzer, der für eine Agentur arbeitet, bewegt sich beispielsweise im B2B-Bereich. Für die deutsche E-Rechnungspflicht reicht das Kürzel allein aber nicht: Es kommt unter anderem auf die Ansässigkeit der Beteiligten, den konkreten Umsatz und gesetzliche Ausnahmen an. Beim Anlegen eines Kunden sollte deshalb nicht nur „Firma“, sondern auch dessen Land und die Art der Geschäftsbeziehung feststehen. Voraussetzungen in § 14 UStG.

B2G – Business to Government

B2G beschreibt Geschäfte mit öffentlichen Auftraggebern, etwa einem Ministerium oder einer Kommune. Hier gelten zusätzlich die Vorgaben des jeweiligen Auftraggebers und die einschlägigen Regeln von Bund oder Land. Für Rechnungen an Bundesstellen können beispielsweise Leitweg-ID, Zahlungsangaben und eine Kontaktadresse verlangt werden. Praktisch hilft ein eigenes Kundenmerkblatt: Empfänger, Rechnungsformat, Kennungen und Einreichungsweg aus dem Auftrag übernehmen, bevor die erste Rechnung erstellt wird. Informationen des Bundes.

B2C – Business to Consumer

B2C bedeutet, dass ein Unternehmen an eine Privatperson verkauft. Die deutsche Pflicht zur strukturierten Rechnung für bestimmte inländische Unternehmensgeschäfte wird nicht allein durch einen solchen Privatkundenverkauf ausgelöst. Ein Handwerksbetrieb kann also zugleich B2B-, B2G- und B2C-Kunden haben. Für die Organisation ist diese Unterscheidung hilfreicher als eine pauschale Einstellung „Alle Kunden erhalten dasselbe Format“. Andere Rechnungspflichten bleiben unabhängig davon zu beachten. BMF: Anwendungsbereich und Ausnahmen.

E-Rechnungspflicht und Übergangsfristen

Empfangen und Ausstellen sind zwei verschiedene Pflichten. Inländische Unternehmen müssen seit 2025 grundsätzlich E-Rechnungen empfangen können; für die Ausstellung bestehen Übergangsregeln. Bis Ende 2026 gelten allgemeine Erleichterungen, 2027 unter anderem bei höchstens 800.000 Euro Vorjahresumsatz des Ausstellers sowie für bestimmte EDI-Verfahren. Ab 2028 laufen diese Übergänge aus; gesetzliche Ausnahmen bleiben bestehen. Die Planung sollte daher mit dem eigenen Anwendungsfall beginnen, nicht mit einem pauschalen Stichtag für alle Rechnungen. Übergangsrecht: § 27 Absatz 38 UStG; Fristen ausführlich erklärt.

Kleinunternehmer

Kleinunternehmer ist eine umsatzsteuerliche Einordnung, kein Dateiformat und keine Aussage über die Qualität einer Rechnung. Für die Ausstellung von Rechnungen über entsprechende steuerfreie Umsätze enthält § 34a UStDV eine Ausnahme von der verpflichtenden E-Rechnung. Das bedeutet jedoch nicht, dass eingehende E-Rechnungen ignoriert werden können. Wer freiwillig strukturiert abrechnet, muss außerdem den zutreffenden Steuerbefreiungsgrund abbilden und darf nicht einfach einen normalen Umsatzsteuerbetrag ergänzen. § 34a UStDV; Praxisartikel für Kleinunternehmer.

ViDA – VAT in the Digital Age

ViDA ist ein EU-Paket zur Modernisierung der Mehrwertsteuer im digitalen Geschäftsverkehr. Es umfasst unter anderem elektronische Rechnungen und digitale Meldungen für bestimmte grenzüberschreitende Geschäfte. Der Rat nahm das Paket am 11. März 2025 an; wesentliche grenzüberschreitende Meldeanforderungen sind für 2030 vorgesehen. ViDA ist weder ein Rechnungsformat noch die Aussage, dass heute bereits jede deutsche Rechnung automatisch beim Finanzamt eingeht. EU-Rat: Beschluss und Zeitplan.

Normen, Datenstrukturen und Rechnungsformate

EN 16931

EN 16931 ist die europäische Normenreihe für elektronische Rechnungen. Ihr semantisches Kernmodell beschreibt die Bedeutung der Rechnungsangaben und ihre Beziehungen: beispielsweise Verkäufer, Käufer, Rechnungsposition und Steuerbetrag. Semantik meint hier also, was eine Angabe bedeutet. Die Norm ist weder eine Software noch eine bestimmte Dateiendung. Für den Austausch braucht es zusätzlich eine konkrete technische Darstellung der vereinbarten Inhalte. Europäische Kommission zur E-Rechnungsnorm.

Syntax

Syntax bezeichnet den technischen Aufbau einer Nachricht. Zwei Rechnungen können dieselben fachlichen Angaben enthalten, diese aber in unterschiedlich benannten und verschachtelten XML-Elementen ablegen. Das ist vergleichbar mit zwei Formularen, die beide „Rechnungsnummer“ abfragen, das Feld jedoch an verschiedenen Stellen führen. Eine Software muss die verwendete Syntax verstehen; bloß nach einem sichtbaren Wort wie „Total“ zu suchen, ist keine verlässliche Zuordnung. Beispiel einer Syntax: UBL 2.1.

XML – Extensible Markup Language

XML ist eine Auszeichnungssprache für gegliederte Daten. Bezeichnungen in spitzen Klammern markieren Elemente; darin stehen Werte oder weitere Elemente. Das macht Zusammenhänge für Programme auswertbar. Die Endung .xml beweist jedoch weder, dass es sich um eine Rechnung handelt, noch dass diese richtig ist. Auch eine Produktliste kann XML sein. Wer eine XML-Rechnung öffnet, braucht daher eine zum Rechnungsformat passende Anzeige oder Prüfung. W3C: XML.

UBL – Universal Business Language

UBL ist ein von OASIS entwickelter Standard für elektronische Geschäftsdokumente. Er enthält unter anderem XML-Strukturen für Rechnungen und Gutschriften. UBL 2.1 ist eine der für XRechnung verwendeten Syntaxen. Wichtig ist die Unterscheidung: Nicht jedes UBL-Dokument erfüllt automatisch XRechnung. Erst die zusätzlich eingehaltenen Regeln, Kennungen und Inhalte machen eine Datei zum passenden Dokument für einen konkreten Rechnungsaustausch. OASIS: UBL-Spezifikation.

CII – Cross Industry Invoice

CII ist eine branchenübergreifende Rechnungsstruktur aus dem Umfeld von UN/CEFACT. Sie ist die zweite Syntax, in der XRechnung umgesetzt werden kann, und bildet die XML-Grundlage von ZUGFeRD beziehungsweise Factur-X. UBL und CII sind deshalb keine zwei unterschiedlichen Steuerarten. Sie beschreiben unterschiedliche technische Wege, Rechnungsinhalte abzubilden. Bei einer Umwandlung muss die Bedeutung der Angaben erhalten bleiben, auch wenn die XML-Elemente anschließend anders heißen. FeRD zur XML-Grundlage.

XRechnung

XRechnung ist ein deutscher Standard für strukturierte Rechnungsdaten auf Grundlage der europäischen Norm. Er präzisiert Anforderungen für die deutsche Anwendung und ist besonders im öffentlichen Rechnungsaustausch verbreitet. Die Rechnung wird typischerweise als XML-Datei übermittelt; ein PDF-Rechnungsbild gehört nicht zwingend dazu. XRechnung lässt sich in UBL oder CII abbilden. Welche Version und welcher Übermittlungsweg angenommen werden, sollte vor dem Versand mit dem Empfänger geklärt sein. KoSIT: Standard XRechnung; XRechnung erstellen.

CIUS – Core Invoice Usage Specification

Eine CIUS beschreibt eine konkretisierte Anwendung des europäischen Rechnungskernmodells. Sie kann beispielsweise optionale Angaben verbindlich machen oder die zulässigen Werte enger fassen, ohne das Kernmodell beliebig umzudeuten. Für Anwender erklärt das einen häufigen Stolperstein: Eine Rechnung kann die allgemeinen Regeln erfüllen und trotzdem an zusätzlichen Anforderungen eines Einsatzbereichs scheitern. XRechnung ist ein Beispiel für eine solche nationale Konkretisierung. Europäische Kommission: Normkonformität und CIUS.

ZUGFeRD

ZUGFeRD verbindet im üblichen hybriden Einsatz ein lesbares PDF/A-3-Dokument mit eingebetteten XML-Rechnungsdaten. Menschen können die Rechnung ansehen, Programme können die Daten auslesen. Das Forum elektronische Rechnung Deutschland begleitet die Entwicklung des Formats. Nicht das Logo, der Dateiname oder irgendeine XML-Anlage sind entscheidend, sondern die tatsächliche Einhaltung der Format- und Profilregeln. Auch bei diesem Format sollte der strukturierte Inhalt geprüft werden. FeRD: Aufbau von ZUGFeRD.

Factur-X

Factur-X ist die französische Bezeichnung des gemeinsam mit ZUGFeRD weiterentwickelten deutsch-französischen Formats. Die abgestimmten Versionen teilen sich die technische Grundlage. Wer im Austausch „Factur-X“ liest, sollte deshalb zunächst Version und Profil vergleichen, statt automatisch eine vollständig andere Rechnungslösung zu vermuten. Die Bezeichnungen können auf dieselbe Formatfamilie verweisen; konkrete Empfängeranforderungen bleiben dennoch maßgeblich. FeRD: Zusammenhang von ZUGFeRD und Factur-X.

PDF, Profile und Versionsnummern

PDF/A-3

PDF/A-3 ist eine PDF-Variante für die langfristige Aufbewahrung, die auch eingebettete Dateien anderer Formate erlaubt. Diese Möglichkeit nutzt ZUGFeRD für die XML-Rechnungsdaten. Umgekehrt gilt aber nicht: „PDF/A-3 bedeutet automatisch E-Rechnung“. Der PDF-Container kann ganz andere Anlagen enthalten. Für die Beurteilung einer Rechnung müssen deshalb sowohl die eingebetteten Daten als auch die einschlägigen Rechnungsregeln betrachtet werden. PDF Association: eingebettete Dateien.

Hybridrechnung

Eine Hybridrechnung kombiniert eine menschenlesbare Darstellung und maschinenlesbare Rechnungsdaten in einer Datei. Bei ZUGFeRD sind das PDF und XML. Beide sollten inhaltlich zusammenpassen. Weichen sie voneinander ab, ist für die E-Rechnung grundsätzlich der strukturierte Teil maßgeblich. Deshalb ist ein stimmiges PDF allein kein ausreichender Qualitätsnachweis. Im Arbeitsablauf sollten insbesondere Empfänger, Positionen, Steuerbeträge und Endsumme zwischen Anzeige und XML übereinstimmen. BMF: hybride Rechnungsformate.

Profil

Ein Profil legt fest, welchen Umfang und welche Regeln ein Rechnungsformat in einer bestimmten Ausprägung verwendet. ZUGFeRD kennt unter anderem MINIMUM, BASIC WL, BASIC, EN 16931 und EXTENDED. Die ersten beiden liefern nicht die vollständige strukturierte Rechnung für die deutsche E-Rechnungsdefinition. „BASIC“ darf nicht mit „BASIC WL“ gleichgesetzt werden. Bei Softwareangeboten sollte deshalb ausdrücklich nach dem unterstützten Profil gefragt werden, nicht nur nach „ZUGFeRD-Unterstützung“. FeRD: Profile; BMF: geeignete ZUGFeRD-Profile.

Version und Release-Bundle

Eine Versionsnummer kennzeichnet einen Entwicklungsstand des Standards. Ein Release-Bundle bündelt dazugehörige Dateien wie Regeln, Beispiele und Prüfartefakte. Beides ist nicht automatisch identisch: Ein Fehlerkorrekturpaket kann erscheinen, ohne die Hauptversion des Standards zu ändern. Für eine nachvollziehbare Prüfung sollten Format, Spezifikationsstand und eingesetztes Regelpaket dokumentiert sein. Ein Entwurf einer kommenden Version ist außerdem noch keine Aufforderung, laufende Rechnungen sofort umzustellen. KoSIT: Versionen und Bundles.

Rechnungsfelder, Referenzen und Kennungen

BT – Business Term

Ein Business Term ist ein fachlich definiertes Rechnungsfeld mit einer Kennnummer. BT-1 bezeichnet beispielsweise die Rechnungsnummer, BT-10 die Käuferreferenz. Diese Nummern helfen dabei, Fehlermeldungen und Dokumentationen syntaxübergreifend zu verstehen. Im XML steht nicht zwingend wörtlich „BT-1“: In UBL wird der Wert an einer festgelegten Stelle als cbc:ID abgebildet. Deshalb sollte bei einer Fehlermeldung zuerst das fachliche Feld und dann seine technische Position gesucht werden. Beispiel: BT-1 in UBL.

BG – Business Group

Eine Business Group fasst zusammengehörige Rechnungsangaben zusammen. BG-22 steht etwa für die Dokumentensummen, während andere Gruppen Beteiligte, Positionen oder Steueraufschlüsselungen bündeln. Eine Gruppe ist also kein einzelner Rechnungswert. Für die Fehlersuche ist das wichtig: Fehlt eine ganze Gruppe, kann es mehrere betroffene Angaben geben. In der Datenerfassung sollten solche Zusammenhänge ebenfalls sichtbar bleiben, statt alle Felder ungeordnet in eine lange Liste zu stellen. Beispiel: BG-22.

Kardinalität und Pflichtfeld

Kardinalität beschreibt, wie oft ein Feld oder eine Gruppe vorkommen darf. 1..1 bedeutet genau einmal, 0..1 höchstens einmal und optional, 0..n beliebig oft einschließlich gar nicht. Zusätzliche Geschäftsregeln können ein grundsätzlich optionales Feld in einem bestimmten Fall dennoch verlangen. Eine leere Zeichenfolge ist dabei nicht automatisch eine sinnvolle Erfüllung eines Pflichtfelds. Das Rechnungsnummernfeld zeigt den einfachen Fall „genau einmal“. UBL-Feldbeschreibung mit Kardinalität.

Buyer Reference – Käuferreferenz (BT-10)

Die Käuferreferenz unterstützt die interne Zuordnung beim Rechnungsempfänger. Das kann etwa eine Abteilungskennung oder eine andere vom Käufer vorgegebene Referenz sein. In deutschen Behördenprozessen wird hier regelmäßig die Leitweg-ID eingetragen. Im B2B-Bereich ist BT-10 jedoch nicht automatisch eine Leitweg-ID. Den Wert sollte der Empfänger nennen; eine selbst erfundene Kennung kann eine technisch lesbare Rechnung im falschen Arbeitskorb landen lassen. Definition von BT-10.

Leitweg-ID

Die Leitweg-ID ist eine Kennung zur Zuordnung elektronischer Rechnungen im öffentlichen Rechnungsaustausch. Sie hilft dabei, den zuständigen Rechnungsempfänger beziehungsweise dessen Bearbeitungsbereich zu erreichen. Sie ist weder die eigene Steuernummer noch die Rechnungsnummer. Ob sie benötigt wird und welcher Wert einzusetzen ist, ergibt sich aus den Vorgaben des öffentlichen Auftraggebers. Für normale Rechnungen zwischen privaten Unternehmen gibt es keine allgemeine Pflicht, sich eine Leitweg-ID zu beschaffen. BMF: Leitweg-ID und B2B.

Bestellreferenz (BT-13)

Die Bestellreferenz verbindet eine Rechnung mit einer Bestellung des Käufers. Sie kann beispielsweise BEST-2026-0042 lauten. Das unterscheidet sie von der eigenen Auftragsnummer des Verkäufers und von einer allgemeinen Käuferreferenz. Im Rechnungsprozess ermöglicht sie den Abgleich mit einem vorher freigegebenen Einkauf. Bittet der Kunde ausdrücklich um seine Bestellnummer, sollte sie im passenden strukturierten Feld stehen und nicht nur irgendwo im Rechnungstext. Peppol-Feldbeschreibung: Bestellreferenz.

Endpoint-ID und elektronische Adresse

Eine Endpoint-ID bezeichnet eine elektronische Adresse eines Beteiligten. Für den Käufer wird sie unter anderem in BT-49 abgebildet. Zur Kennung gehört eine Angabe über das verwendete Identifikationsschema; die Zeichenfolge allein genügt daher häufig nicht. Je nach Prozess kann dahinter beispielsweise eine registrierte Netzwerkteilnehmerkennung stehen. Elektronische Adresse, allgemeine Kontakt-E-Mail und Leitweg-ID erfüllen unterschiedliche Aufgaben und sollten nicht ungeprüft ineinander kopiert werden. BT-49 und Schema-Kennung.

Rechnungsnummer (BT-1)

Die Rechnungsnummer identifiziert die Rechnung innerhalb des Nummernsystems des Ausstellers. Sie ist nicht mit einer Kundennummer oder einer Bestellnummer zu verwechseln. Ein sinnvoller Arbeitsablauf vergibt die Nummer kontrolliert und verwendet sie anschließend in Datei, Buchhaltung und Korrespondenz konsistent. Wer eine bereits verschickte Rechnung berichtigt, sollte diesen Bezug nachvollziehbar erhalten, statt stillschweigend eine andere Datei unter demselben Namen auszutauschen. Fachliche Definition von BT-1.

Leistungsdatum und Leistungszeitraum

Das Leistungsdatum beschreibt, wann die Lieferung oder Leistung ausgeführt wurde. Ein Leistungszeitraum nennt stattdessen Anfang und Ende eines zusammenhängenden Zeitraums. Beides ist vom Ausstellungsdatum der Rechnung zu unterscheiden. Bei einer monatlichen Betreuung können Rechnung und Leistung beispielsweise in unterschiedlichen Monaten liegen. Die Umsatzsteuer-Durchführungsverordnung lässt für die Angabe des Leistungszeitpunkts auch den Kalendermonat zu. Welche strukturierte Abbildung passt, richtet sich nach dem tatsächlichen Geschäft. § 31 Absatz 4 UStDV.

Umsatzsteuer-Identifikationsnummer

Die Umsatzsteuer-Identifikationsnummer ist eine steuerliche Identifikationsangabe des Unternehmens. Sie ist weder IBAN noch Kundennummer, Rechnungsnummer oder Leitweg-ID. Für die Datenpflege empfiehlt es sich, diese Angaben in getrennten Feldern zu führen und nicht in einem Sammelfeld „Nummer“ abzulegen. So lässt sich beim Export klar unterscheiden, welche Kennung zu welchem Beteiligten und welchem Zweck gehört. Die allgemeinen Rechnungsanforderungen nennen die Steuernummer oder Umsatzsteuer-Identifikationsnummer des leistenden Unternehmers. § 14 Absatz 4 UStG.

Beträge, Steuern und Zahlungen

Umsatzsteuerkategorie

Eine Umsatzsteuerkategorie beschreibt die steuerliche Behandlung einer Position oder Steueraufschlüsselung. Die Codes S, Z, E, AE und O haben unterschiedliche Bedeutungen. Ein Steuerbetrag von null macht diese Kategorien nicht austauschbar: Steuerbefreiung, Nullsteuersatz, Reverse Charge und ein nicht umsatzsteuerbarer Vorgang sind verschiedene Sachverhalte. Die Auswahl muss zur tatsächlichen Leistung passen; ein Konverter kann diese fachliche Entscheidung nicht zuverlässig aus der Zahl „0“ ableiten. Offizielle Codeliste UNCL 5305.

Umsatzsteuersatz

Der Umsatzsteuersatz ist der prozentuale Wert, mit dem die betreffende Bemessungsgrundlage besteuert wird. Er ergänzt die Steuerkategorie, ersetzt sie aber nicht. Im einfachen Beispiel mit 300 Euro netto und 19 Prozent ergeben sich 57 Euro Umsatzsteuer. Enthält eine Rechnung mehrere steuerliche Behandlungen, müssen die jeweiligen Grundlagen und Steuerbeträge getrennt zugeordnet werden. Ob ein konkreter Satz richtig ist, lässt sich nicht allein an einer erfolgreich geprüften XML-Datei erkennen. Peppol BIS: Steueraufschlüsselung und Berechnungen.

Steuerbefreiungsgrund

Ein Steuerbefreiungsgrund erläutert, warum keine Umsatzsteuer berechnet wird. In strukturierten Rechnungen stehen dafür je nach Fall ein Text und/oder ein dafür vorgesehener Code zur Verfügung, etwa BT-120 beziehungsweise BT-121. Das ist etwas anderes als ein beliebiger Hinweis im PDF-Fußbereich. Der Grund muss zur gewählten Kategorie passen. Bei einer regulär besteuerten Position wäre ein zusätzlich eingetragener Befreiungsgrund beispielsweise widersprüchlich. Feldbeschreibung und zugehörige Regeln.

Reverse Charge

Reverse Charge bezeichnet Fälle, in denen der Leistungsempfänger die Umsatzsteuer schuldet. Das ist keine pauschale Steuerbefreiung und auch kein Synonym für jede Auslandsrechnung. Ob das Verfahren gilt, hängt vom konkreten Umsatz und den gesetzlichen Voraussetzungen ab. Bei der strukturierten Abbildung müssen Kategorie, Identifikationsangaben und vorgeschriebener Hinweis zusammenpassen. Wer unsicher ist, sollte die steuerliche Behandlung vor dem Export klären, statt versuchsweise einen anderen Code einzusetzen. § 13b UStG.

Rundung und Rundungsbetrag

Rundung begrenzt die Zahl der Nachkommastellen an festgelegten Rechenschritten. Ein Rundungsbetrag auf Dokumentebene ist eine eigene Angabe und kein Ersatz für korrekte Positions- und Steuerberechnungen. Bei einer Differenz von einem Cent sollte deshalb zuerst geprüft werden, welche Ausgangswerte und Rundungsschritte verwendet wurden. Allein die sichtbare Formatierung auf zwei Nachkommastellen in einer Tabelle garantiert noch nicht, dass intern mit den angezeigten Zahlen gerechnet wird. Dokumentensummen und BT-114.

Zahlbetrag (BT-115)

Der Zahlbetrag ist die Summe, die nach Berücksichtigung der relevanten Gesamtbeträge noch zu zahlen ist. Er kann vom Bruttorechnungsbetrag abweichen, beispielsweise wenn eine bereits gezahlte Summe berücksichtigt wird. Im einfachen Fall ohne Vorauszahlungen und ohne gesonderten Rundungsbetrag sind beide Werte gleich. Für die Zahlungserfassung sollte daher das fachlich richtige Feld verwendet werden, nicht automatisch irgendein im Dokument vorkommender Gesamtbetrag. Dokumentensummen einschließlich BT-115.

Zahlungsmittelcode (BT-81)

Der Zahlungsmittelcode beschreibt die Zahlungsart in einer standardisierten Kennung. So wird eine Überweisung anders abgebildet als eine Lastschrift. Der Code ist nicht die IBAN und enthält auch nicht automatisch sämtliche nötigen Bankangaben. Ein vollständiger Zahlungssatz kann deshalb aus mehreren zusammengehörigen Informationen bestehen. Für die Dateneingabe ist eine verständliche Auswahl wie „SEPA-Überweisung“ sinnvoller als ein unkommentiertes Freitextfeld für technische Zahlenwerte. Feldbeschreibung zu BT-81.

Einheitencode

Ein Einheitencode kennzeichnet die Mengeneinheit einer Rechnungsposition in standardisierter Form. Beispiele sind HUR für Stunden, C62 für eine Anzahl einzelner Einheiten und KGM für Kilogramm. Eine Anzeige darf daneben verständliche Bezeichnungen verwenden. Beim Export muss jedoch der passende Code ausgewählt werden. „4 Stunden“ und „4 Stück“ sind rechnerisch ähnliche Mengenangaben, beschreiben aber unterschiedliche Leistungen und dürfen nicht zufällig derselben Einheit zugeordnet werden. UNECE-Einheiten in der Peppol-Codeliste.

Versand, Netzwerke und Verarbeitung

Peppol

Peppol ist ein Netzwerk mit gemeinsamen Regeln für den elektronischen Austausch von Geschäftsdokumenten. Es ist weder ein einzelnes Rechnungsformat noch einfach eine E-Mail-Adresse. Vereinfacht verbindet sich der Absender über seinen Dienstleister mit dem Dienstleister des Empfängers. Für die Nutzung müssen unter anderem Empfängerkennung, unterstützter Dokumenttyp und Übermittlungsprozess zusammenpassen. Ob Peppol nötig oder verfügbar ist, ergibt sich aus dem jeweiligen Geschäftsprozess. OpenPeppol: Netzwerk und Funktionsweise.

Peppol BIS Billing

BIS steht für Business Interoperability Specification. Peppol BIS Billing beschreibt Regeln für den interoperablen Austausch von Rechnungen und Gutschriften im Peppol-Umfeld. Dazu gehören Datenanforderungen, Kennungen und Prüfregeln. Die Bezeichnung ist nicht gleichbedeutend mit jeder beliebigen XRechnung. Außerdem sollte man Peppol nicht pauschal auf „nur UBL“ reduzieren: Die aktuelle Dokumentation berücksichtigt auch CII als zusätzliche Möglichkeit. Maßgeblich sind die vom beteiligten Dienst unterstützten Dokumente. Aktuelle BIS-Billing-Dokumentation.

Access Point

Ein Access Point ist ein Zugang zum Peppol-Netzwerk. Im üblichen Vier-Ecken-Modell stehen zwischen Rechnungssteller und Empfänger zwei solcher Zugangsdienste. Man kann sie sich als vereinbarte Übergabestellen vorstellen: Sie transportieren unterstützte Geschäftsdokumente anhand der Netzwerkregeln. Eine erfolgreiche technische Zustellung bedeutet dennoch nicht, dass der Kunde die Rechnung sachlich freigegeben oder bezahlt hat. Für den eigenen Ablauf sollten Versandbestätigung, fachliche Rückmeldung und Zahlung getrennt erfasst werden. OpenPeppol: Vier-Ecken-Modell.

OZG-RE

OZG-RE ist eine Rechnungseingangsplattform für die öffentliche Verwaltung. Sie ist ein Zugang zum Einreichen von Rechnungen, nicht selbst die Rechnungssyntax. Welche Stelle darüber erreichbar ist und welche Angaben benötigt werden, muss anhand der Empfängerinformationen geprüft werden. Die frühere Bundesplattform ZRE wurde Ende 2025 abgeschaltet; ältere Anleitungen mit einem pauschalen Verweis auf ZRE sind deshalb zu hinterfragen. Die richtige Plattformadresse gehört in die aktuelle Kundendokumentation. Bund: Plattformen und Umstellung.

EDI – Electronic Data Interchange

EDI bezeichnet den strukturierten elektronischen Datenaustausch zwischen Geschäftspartnern. Der Begriff ist breiter als E-Rechnung und kann auch Bestellungen oder Lieferinformationen betreffen. Ein gewachsenes EDI-Verfahren erfüllt nicht schon wegen seiner langen Nutzung jede neue Rechnungsanforderung. Zu klären ist, ob es die gesetzlichen Voraussetzungen erfüllt oder noch eine Übergangsregel greift. Für bestimmte bisherige EDI-Verfahren sieht das Umsatzsteuergesetz eine Übergangsmöglichkeit bis Ende 2027 vor. § 27 Absatz 38 UStG.

Mapping

Mapping ist die Zuordnung von Ausgangsdaten zu Zielfeldern. Bei einer Excel-Rechnung muss beispielsweise feststehen, welche Zelle die Rechnungsnummer liefert, wo eine Position beginnt und welche Zahl den Nettopreis bezeichnet. Eine Zuordnung sollte nicht allein auf der Bildschirmposition beruhen, wenn sich die Vorlage später verschieben kann. Ein guter Praxistest verändert Mengen, ergänzt eine Position und prüft danach, ob die exportierten Werte weiterhin an den richtigen Stellen erscheinen.

API – Programmierschnittstelle

Eine API ist eine definierte Schnittstelle, über die Programme Daten oder Funktionen austauschen. Im Rechnungsablauf kann eine Software beispielsweise Stammdaten abrufen oder fertige Belege an ein anderes System übergeben. „Mit API“ sagt aber noch nichts darüber aus, welche Felder übertragen werden, wie Fehler gemeldet werden oder wer Zugriff hat. Vor der Einführung sollte eine konkrete Beispielrechnung vollständig durchgespielt werden, einschließlich einer absichtlich fehlerhaften Eingabe.

Prüfung, Fehlermeldungen und Anzeige

Validierung

Validierung ist die technische Prüfung einer Rechnung gegen ein ausgewähltes Regelwerk. Dabei werden beispielsweise die XML-Struktur und fachlich formulierte Datenregeln kontrolliert. Das Ergebnis hängt auch davon ab, welches Format und welcher Regelstand geprüft wurden. Ein erfolgreicher Lauf bestätigt nicht, dass die Leistung tatsächlich erbracht wurde oder jede steuerliche Entscheidung stimmt. Für eine belastbare Rechnungskontrolle gehören deshalb technische Prüfung, Belegabgleich und fachliche Freigabe zusammen. KoSIT-Validator: Prüfverfahren.

XSD – XML Schema Definition

XSD ist eine Sprache zur Beschreibung zulässiger XML-Strukturen und Datentypen. Ein Schema kann beispielsweise festlegen, welche Elemente vorkommen dürfen, in welcher Reihenfolge sie stehen und ob ein Wert ein Datum sein muss. Damit lässt sich ein Teil technischer Fehler erkennen. Ob eine Summe rechnerisch zu anderen Werten passt oder eine steuerliche Sonderregel erfüllt ist, wird dadurch aber nicht automatisch vollständig geklärt. W3C: XML Schema.

Schematron

Schematron ist eine regelbasierte Prüftechnik für XML. Sie kann Beziehungen zwischen Angaben kontrollieren, die über den reinen Strukturaufbau hinausgehen. Eine Regel kann etwa verlangen, dass bei einer bestimmten Steuerkategorie eine zusätzliche Begründung vorhanden ist. Solche Prüfungen ergänzen die Schemaprüfung. Für Anwender ist die praktische Frage nicht, wie die Regelsprache aussieht, sondern welche konkrete Angabe eine Meldung betrifft und wie sie sachlich richtig korrigiert wird. KoSIT: Schema- und Schematron-Prüfung.

Geschäftsregel

Eine Geschäftsregel beschreibt eine einzuhaltende Bedingung für die Rechnungsdaten. Sie kann zum Beispiel eine notwendige Referenz oder das Zusammenspiel einer Steuerkategorie mit einem Befreiungsgrund festlegen. Viele Regeln tragen eine Kennung, die im Prüfbericht wieder auftaucht. Diese Kennung ist nützlich für die Recherche: Statt nur „Rechnung ungültig“ weiterzugeben, sollten Regelnummer, betroffene Angabe und verständliche Fehlermeldung gemeinsam dokumentiert werden. Beispiele für bedingte Geschäftsregeln.

Validierungsbericht

Ein Validierungsbericht hält das Ergebnis einer technischen Prüfung fest. Er kann Fehler, Warnungen und zusätzliche Informationen enthalten. Für die Bearbeitung empfiehlt sich eine klare Reihenfolge: zuerst blockierende Strukturfehler, danach fachliche Datenregeln, anschließend Hinweise prüfen. Eine Warnung sollte nicht automatisch ignoriert werden, ist aber auch nicht mit jeder Fehlermeldung gleichzusetzen. Der verwendete Prüfstand gehört zum Bericht, damit das Ergebnis später nachvollzogen werden kann. KoSIT: Prüfergebnisse und Berichte.

Viewer und Visualisierung

Ein Viewer stellt strukturierte Rechnungsdaten in lesbarer Form dar. Aus XML entstehen dabei beispielsweise beschriftete Bereiche für Absender, Empfänger, Positionen und Summen. Diese Anzeige erleichtert die Kontrolle, ersetzt aber nicht automatisch eine Validierung. Sie ist außerdem eine Darstellung des Originals und nicht ohne Weiteres ein neues Originaldokument. Bei einem Werkzeugwechsel sollte geprüft werden, ob auch weniger auffällige Angaben wie Referenzen oder Steuerhinweise sichtbar bleiben. KoSIT: Visualisierung; XML-Rechnungen öffnen und prüfen.

OCR – optische Zeichenerkennung

OCR versucht, Text und Zahlen aus einem Bild oder Scan zu erkennen. Das ist etwas anderes als das direkte Lesen strukturierter Rechnungsfelder. Ein Scan kann beispielsweise „8“ und „B“ ähnlich darstellen; außerdem muss eine nachgelagerte Verarbeitung verstehen, welche Zahl zu welchem Feld gehört. OCR kann die Erfassung erleichtern, macht aus einem Bild aber nicht automatisch eine korrekte E-Rechnung. Erkannte Werte benötigen weiterhin eine verlässliche Zuordnung und Kontrolle.

Aufbewahrung, Korrekturen und Signaturen

GoBD

GoBD steht für Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff. Gemeint sind Anforderungen an den Umgang mit steuerlich relevanten Informationen, nicht ein bestimmtes Rechnungsformat. Die Verwaltungsvorgaben wurden 2025 auch im Hinblick auf E-Rechnungen angepasst. Ein Werbehinweis „GoBD-konform“ ersetzt deshalb nicht die Prüfung, wie Erfassung, Aufbewahrung und Änderungen im eigenen Betrieb tatsächlich organisiert sind. BMF: GoBD-Änderung vom 14. Juli 2025.

Originaldatei

Die Originaldatei ist die tatsächlich empfangene oder ausgestellte elektronische Rechnung, nicht bloß ein Bildschirmfoto davon. Bei einer XML-Rechnung sollte daher die strukturierte Datei erhalten bleiben. Als einfacher betrieblicher Standard empfiehlt es sich, auch hybride Rechnungen vollständig aufzubewahren und zusätzliche Lesefassungen klar zu kennzeichnen. So lässt sich später prüfen, welche Daten übermittelt wurden. Eine ausgedruckte Ansicht kann den Zugang zum Inhalt erleichtern, bildet aber die maschinenlesbare Struktur nicht ab. Aufbewahrung nach § 14b UStG.

Archivierung und Aufbewahrungsfrist

Archivierung bedeutet, Rechnungen während der erforderlichen Dauer geordnet und verfügbar zu halten. Für die umsatzsteuerliche Rechnungsaufbewahrung gelten grundsätzlich acht Jahre; der Fristbeginn und mögliche Verlängerungen sind gesondert zu beachten. Ein zufällig gefüllter Downloadordner ist noch kein durchdachtes Aufbewahrungsverfahren. Zuständigkeiten, Wiederauffindbarkeit, Schutz vor unbemerkten Änderungen und ein getesteter Zugriff sollten geklärt sein. Eine Datensicherung ist zusätzlich sinnvoll, aber nicht mit allen Anforderungen an die Aufbewahrung identisch. § 14b UStG.

Verfahrensdokumentation

Eine Verfahrensdokumentation beschreibt nachvollziehbar, wie steuerlich relevante Unterlagen im Betrieb verarbeitet werden. Für E-Rechnungen kann sie beispielsweise Eingang, Prüfung, Freigabe, Ablage, Zugriffsrechte und Korrekturen erklären. Hilfreich ist eine konkrete Arbeitsbeschreibung statt einer abstrakten Sammlung von Produktnamen: Wer kontrolliert das Postfach? Wo liegt das Original? Was passiert bei einer ungültigen Datei? Die dokumentierte Vorgehensweise sollte mit der tatsächlichen Arbeit übereinstimmen und bei Änderungen angepasst werden. BMF: aktuelle Änderungen der GoBD.

Rechnungskorrektur

Eine Rechnungskorrektur berichtigt fehlende oder unzutreffende Angaben einer bestehenden Rechnung. Der Bezug zum ursprünglichen Dokument muss eindeutig sein. Das unterscheidet eine nachvollziehbare Berichtigung von einem stillen Überschreiben der bereits versandten Datei. Je nach Fall können unterschiedliche Korrekturabläufe erforderlich sein. Praktisch sollten ursprüngliche Rechnung, Korrektur und Korrespondenz gemeinsam auffindbar bleiben; die rechtlich passende Vorgehensweise ist bei Zweifeln mit der steuerlichen Beratung abzustimmen. § 31 Absatz 5 UStDV.

Gutschrift und Credit Note

„Gutschrift“ ist mehrdeutig. Umsatzsteuerrechtlich kann damit eine vorher vereinbarte Abrechnung durch den Leistungsempfänger gemeint sein. Im kaufmännischen Alltag wird das Wort auch für eine Rechnungsminderung verwendet; im Datenaustausch begegnet dafür „Credit Note“. Diese Bedeutungen sollten nicht ungeprüft vermischt werden. Entscheidend sind der tatsächliche Vorgang, der passende Dokumenttyp und die korrekte Verknüpfung mit anderen Belegen. Gutschrift im Umsatzsteuerrecht; UBL-Dokumenttypen Invoice und CreditNote.

Digitale Signatur

Eine digitale Signatur kann Herkunft und Unverändertheit elektronischer Daten absichern. Eine qualifizierte elektronische Signatur ist aber nicht pauschal für jede E-Rechnung vorgeschrieben; das Umsatzsteuerrecht sieht auch andere Wege zur Sicherstellung von Herkunft und Integrität vor. Davon zu unterscheiden ist die Signierung einer Software: Sie betrifft das ausgelieferte Programm und seinen Herausgeber, nicht automatisch jede damit erstellte Rechnung. § 14 Absatz 3 UStG; Digitale Signierung von TabellenFaktura.

Praxisbeispiel: Wie die Begriffe in einer Rechnung zusammenkommen

Ein fiktives Büro berechnet einem deutschen Geschäftskunden vier Stunden Dokumentenbearbeitung zu je 75 Euro netto. Für dieses vereinfachte Beispiel wird eine regulär mit 19 Prozent besteuerte Leistung angenommen. Es gibt keine Rabatte, Zuschläge, Vorauszahlungen oder gesonderten Rundungsbeträge. Der Kunde nennt eine Bestellreferenz und wünscht XRechnung.

Die gleichen Daten erhalten unterschiedliche Aufgaben: RE-2026-0042 identifiziert die Rechnung, die Bestellreferenz ordnet sie einem Einkauf zu, und die elektronische Adresse unterstützt den vorgesehenen Austausch. Keine dieser Angaben ersetzt die andere. Das Beispiel zeigt die Rechenlogik, ist aber keine vollständige versandfertige Rechnung.

1. Anforderungen abfragen. Welche Rechnungsart, welches Format, welche Referenz und welchen Eingangsweg verlangt der Kunde? Diese Angaben werden beim Kunden hinterlegt.
2. Daten zuordnen. Das Mapping verbindet die Werte der Vorlage mit den richtigen Rechnungsfeldern. Dabei bleiben Nummern, Preise, Steuern und Adressen getrennt.
3. Datei erzeugen und prüfen. Der Export erstellt die strukturierte Rechnung. Der Validator prüft sie gegen den passenden Regelstand; im Viewer werden die erkannten Angaben kontrolliert.
4. Übermitteln und aufbewahren. Die Rechnung geht über den abgestimmten Weg an den Kunden. Das versandte Original und die zugehörigen Nachweise bleiben nachvollziehbar auffindbar.

Für einen ersten Test reichen einfache Zahlen. Anschließend sollte dieselbe Vorlage mit zwei Positionen, einer längeren Beschreibung und einer abweichenden Menge geprüft werden. So fällt eher auf, ob nur ein Einzelbeispiel funktioniert oder die Zuordnung im Alltag belastbar ist. Hinweise zum Ausgangspunkt Excel enthält der Beitrag E-Rechnung aus Excel erstellen.

Typische Meldungen: Was ist jetzt zu tun?

Die Tabelle ist eine Orientierung, keine automatische Fehlerdiagnose. Eine Meldung kann mehrere Ursachen haben. Für eine Rückfrage an den Softwareanbieter sind die Regelkennung, der verwendete Prüfstand und ein anonymisiertes Beispiel wesentlich hilfreicher als ein einzelnes Bildschirmfoto mit „ungültig“. Personenbezogene oder vertrauliche Rechnungsdaten sollten nicht ungeprüft in öffentliche Prüfangebote hochgeladen werden.

Fünf Verwechslungen, die sich leicht vermeiden lassen

Welche Versionen sind am 17. September 2026 aktuell?

Versionsangaben verdienen einen eigenen Blick: „neu veröffentlicht“ bedeutet nicht automatisch „bereits verbindlich“. Besonders bei XRechnung ist diese Unterscheidung im September 2026 wichtig.

Quellen für die Versionsangaben: KoSIT: XRechnung-Versionen und Bundles und FeRD: ZUGFeRD 2.5.2 / Factur-X 1.09.2. Die dort veröffentlichte Verfügbarkeit sagt nicht automatisch, welche Version eine einzelne Software oder ein bestimmtes Portal bereits verarbeitet.

Was bedeutet das für Rechnungen aus Excel?

Eine vertraute Excel-Vorlage und eine strukturierte E-Rechnung erfüllen unterschiedliche Aufgaben. In Excel lassen sich Inhalte erfassen und gestalten. Für die strukturierte Ausgabe müssen die einzelnen Angaben anschließend eindeutig zugeordnet werden. Eine hübsche Druckansicht allein löst diese Aufgabe nicht.

Für den Einstieg mit TabellenFaktura sollten deshalb drei Dinge bereitliegen: eine anonymisierte Musterrechnung, die Anforderungen des tatsächlichen Empfängers und ein einfacher Testfall mit gut nachrechenbaren Beträgen. Danach wird kontrolliert, ob Positionen, Steuern, Referenzen und Summen im erzeugten Dokument richtig ankommen. Welche Formate und Funktionen die konkret eingesetzte Version unterstützt, ist unabhängig vom allgemeinen Stand eines Standards zu prüfen.

Zur Vertiefung: ZUGFeRD oder XRechnung?, ZUGFeRD-Rechnung erstellen und Rechnungen mit Excel zukunftssicher aufstellen.