Standardisierte Rechnungsinformationen nach EN 16931 bilden die fachliche Grundlage vieler moderner E-Rechnungsprozesse. Die sogenannten Business Terms (BT) definieren einzelne Informationen einer elektronischen Rechnung einheitlich und ermöglichen dadurch eine strukturierte, maschinenlesbare Verarbeitung.
Seit dem 1. Januar 2025 müssen inländische Unternehmen grundsätzlich in der Lage sein, E-Rechnungen zu empfangen. Für die verpflichtende Ausstellung gelten dagegen Übergangsregelungen und Ausnahmen. Ein präzises Verständnis der Feldstruktur sowie der Unterscheidung zwischen verpflichtenden, bedingten und optionalen Informationen hilft Unternehmen dabei, technisch saubere Rechnungen zu erzeugen, Validierungsfehler zu reduzieren und automatisierte Prozesse aufzubauen.
Die europäische Norm EN 16931 beschreibt ein semantisches Datenmodell für elektronische Rechnungen. Einzelne Informationselemente werden darin als Business Terms bezeichnet. Beispiele sind BT-1 für die Rechnungsnummer, BT-2 für das Rechnungsdatum oder BT-10 für die Käuferreferenz.
Diese Business Terms beschreiben fachlich, welche Informationen eine Rechnung enthält. Die technische Abbildung erfolgt anschließend beispielsweise über eine Syntax wie UBL oder CII.
Für eine konkrete E-Rechnung muss unterschieden werden zwischen Informationen, die grundsätzlich erforderlich sind, Informationen, die nur unter bestimmten Bedingungen benötigt werden, und optionalen Angaben. Zusätzlich können konkrete Standards wie XRechnung oder die Anforderungen eines Rechnungsempfängers weitere Geschäftsregeln vorgeben.
Business Terms strukturieren unter anderem Rechnungsnummern, Datumsangaben, Käufer- und Verkäuferdaten, Steuerinformationen, Zahlungsinformationen, Referenzen und Positionsdaten.
Für automatisierte Purchase-to-Pay-Prozesse ist eine konsistente Verwendung dieser Informationen besonders wichtig. Beispielsweise können Bestellreferenzen dazu genutzt werden, eingehende Rechnungen automatisiert einem Auftrag oder einer Bestellung zuzuordnen.
Ob eine Information zwingend erforderlich ist, hängt vom jeweiligen Rechnungsstandard, den umsatzsteuerlichen Anforderungen und gegebenenfalls vom konkreten Geschäftsvorgang ab.
Ein fehlendes oder falsch belegtes Feld kann bei einer technischen Validierung zu Fehlern oder Warnungen führen. Ob eine Rechnung anschließend zurückgewiesen wird, hängt jedoch vom jeweiligen Fehler, dem verwendeten Standard und den Regeln beziehungsweise Prozessen des Empfängers ab.
Unternehmen sollten deshalb ihre eigenen Feldzuordnungen dokumentieren und insbesondere bei automatisierten Prozessen eindeutig festlegen, aus welchem Quellsystem eine Information stammt und in welchem Business Term sie abgebildet wird.
Seit dem 1. Januar 2025 müssen inländische Unternehmen grundsätzlich E-Rechnungen empfangen können. Die Pflicht zur Ausstellung wird dagegen schrittweise eingeführt und unterliegt Übergangsregelungen und Ausnahmen.
Unabhängig von den gesetzlichen Fristen ist eine saubere Feldstruktur für automatisierte Rechnungsprozesse wichtig. Fehlende oder unplausible Informationen können zu Rückfragen, manueller Nachbearbeitung oder – abhängig vom Empfängersystem und den dort geltenden Validierungsregeln – zu einer Zurückweisung führen.
Bei E-Rechnungen müssen die umsatzsteuerlich erforderlichen Rechnungsangaben grundsätzlich im strukturierten Teil enthalten sein. Dadurch wird sichergestellt, dass die relevanten Rechnungsinformationen elektronisch verarbeitet werden können.
Für die Aufbewahrung gilt: Bei einer E-Rechnung ist zumindest der strukturierte Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form vorliegt. Rechnungen sind grundsätzlich acht Jahre aufzubewahren.
Technische Funktionen wie Änderungsprotokolle, Validierungsreports oder Integritätskontrollen können die Nachvollziehbarkeit des eigenen Prozesses unterstützen. Sie sind jedoch nicht pauschal in jeder Ausgestaltung gesetzlich vorgeschrieben.
Business Terms lassen sich nach ihrer fachlichen Funktion gruppieren. Die folgende Einordnung hilft dabei, typische Datenflüsse und Fehlerquellen zu verstehen.
Referenzfelder verbinden eine Rechnung mit dem zugrunde liegenden Geschäftsprozess. Dazu gehören beispielsweise:
Im öffentlichen Auftragswesen kann die Käuferreferenz beispielsweise eine Leitweg-ID enthalten. Ob und welcher Wert benötigt wird, richtet sich nach den Vorgaben des konkreten Rechnungsempfängers.
Referenzen sind insbesondere für automatisierte Zuordnungs- und Matching-Prozesse relevant. Fehlen erforderliche Referenzen, kann eine automatische Zuordnung scheitern und eine manuelle Bearbeitung notwendig werden.
Die EN 16931 enthält verschiedene Business Terms für die Identifikation und Anschrift des Käufers. Dazu gehören beispielsweise Käufername, Anschrift und – sofern für den konkreten Sachverhalt erforderlich – steuerliche Identifikationsangaben.
Eine konsistente Stammdatenpflege erleichtert die automatisierte Verarbeitung. Dabei sollte jedoch nicht pauschal angenommen werden, dass jede denkbare Käuferinformation in jedem Geschäftsfall zwingend vorhanden sein muss.
Für Rechnungspositionen und Steueraufschlüsselungen werden standardisierte Steuerkategorien und weitere steuerliche Informationen verwendet.
Hierbei ist besonders wichtig, gültige Codes zu verwenden und den zugrunde liegenden steuerlichen Sachverhalt korrekt abzubilden. Beispielsweise unterscheiden die verwendeten Codelisten zwischen Standardbesteuerung, Steuerbefreiung, Reverse Charge und weiteren Fällen.
Eine technische Validierung kann unzulässige Codes oder bestimmte logische Widersprüche erkennen. Sie ersetzt jedoch nicht die steuerliche Beurteilung des konkreten Geschäftsvorgangs.
Business Terms können unter anderem Zahlungsweg, Zahlungskonto, Zahlungsbedingungen und fälligen Betrag beschreiben.
Welche Zahlungsinformationen erforderlich sind, hängt vom verwendeten Zahlungsweg und dem konkreten Rechnungsfall ab. Fehlerhafte Kontodaten können die Zahlungsabwicklung beeinträchtigen und sollten deshalb durch geeignete Prüfmechanismen kontrolliert werden.
Rechnungspositionen enthalten strukturierte Informationen zu Mengen, Einheiten, Preisen und Leistungsbeschreibungen. Für Einheiten werden standardisierte Codes verwendet.
Eine konsistente Abbildung unterstützt den automatisierten Abgleich zwischen Bestellung, Lieferung und Rechnung.
| Feldgruppe | Beispiele | Funktion im Prozess | Typische Fehlerquellen |
|---|---|---|---|
| Referenzen | BT-10, BT-11, BT-13 | Verknüpfung mit Bestellung, Projekt oder internem Geschäftsfall | fehlende oder falsche Referenz, uneinheitliche Stammdaten |
| Käuferdaten | Name, Adresse und gegebenenfalls Identifikatoren | Identifikation des Rechnungsempfängers | unvollständige oder inkonsistente Stammdaten |
| Steuern | Steuerkategorie, Steuersatz und Steuerbetrag | Abbildung der steuerlichen Behandlung | ungültige Codes, falscher Steuersatz oder falsche Zuordnung |
| Zahlungen | Zahlungsweg, Konto, Zahlungsbedingungen, fälliger Betrag | Unterstützung der Zahlungsabwicklung | fehlerhafte Kontodaten, falsche Beträge oder unpassende Zahlungsinformationen |
| Mengen und Einheiten | Menge, Einheit, Preis | Positionsbezogene Rechnungsprüfung | falsche Unit Codes oder Abweichungen zwischen Menge und Preis |
Welche dieser Informationen im konkreten Fall zwingend benötigt werden, sollte anhand der jeweils eingesetzten Spezifikation und des tatsächlichen Rechnungssachverhalts geprüft werden.
In einem strukturierten E-Rechnungsprozess entstehen Rechnungsinformationen zunächst in ERP-, Faktura- oder anderen Quellsystemen. Anschließend werden sie auf die relevanten Business Terms und die technische Syntax des gewählten Rechnungsformats abgebildet.
Ein möglicher Prozess sieht folgendermaßen aus:
Eine Validierung vor dem Versand ist sinnvoll und wird auch vom BMF empfohlen. Sie ist jedoch keine unmittelbare Voraussetzung für die steuerliche Anerkennung einer Rechnung.
Häufige Ursachen technischer Probleme sind:
Unternehmen sollten deshalb ihre relevanten Feldzuordnungen und Geschäftsregeln nachvollziehbar dokumentieren und insbesondere nach System- oder Standardänderungen überprüfen.
Automatisierung kann strukturierte Rechnungsinformationen direkt aus ERP- und Stammdatensystemen übernehmen. Bei unstrukturierten Eingangsformaten können zusätzlich OCR- oder KI-Verfahren eingesetzt werden.
Automatische Erkennung und Zuordnung ist jedoch nicht fehlerfrei. Insbesondere bei mehrdeutigen Referenzen oder fehlendem Kontext sollten Ergebnisse überprüfbar bleiben.
Welche Prüf- und Freigabemechanismen sinnvoll sind, hängt vom Geschäftsprozess und dem jeweiligen Risiko ab. Eine allgemeine Pflicht zu einem bestimmten KI-Kontrollverfahren besteht nicht.
Eine strukturierte Rechnung kann unterschiedliche Fehler enthalten. Beispielsweise kann die XML-Struktur selbst fehlerhaft sein oder gegen technische Geschäftsregeln des verwendeten Standards verstoßen.
Ein solcher Fehler kann dazu führen, dass ein Empfängersystem die Rechnung nicht automatisiert verarbeitet oder – abhängig von dessen Validierungsregeln – zurückweist. Eine pauschale Aussage, dass jede technisch fehlerhafte Rechnung automatisch und sofort abgelehnt wird, ist jedoch nicht möglich.
Davon zu unterscheiden sind inhaltliche Fehler. Eine Rechnung kann technisch valide sein und trotzdem beispielsweise einen sachlich falschen Betrag, falsche Steuerinformationen oder eine unzutreffende Referenz enthalten.
Technische Validierung und fachliche Rechnungsprüfung sind deshalb zwei unterschiedliche Kontrollbereiche.
In der Praxis können unter anderem folgende Probleme auftreten:
Solche Fehler können Rückfragen und zusätzliche Bearbeitung verursachen. Wie häufig sie auftreten und welche Kosten daraus entstehen, hängt jedoch stark von Unternehmen, Systemlandschaft und Rechnungsvolumen ab. Allgemeingültige Rückfragequoten oder Verzögerungszeiten lassen sich daraus nicht ableiten.
Bei hybriden Formaten wie ZUGFeRD enthält das Dokument strukturierte Rechnungsdaten und eine visuelle Darstellung.
Für die steuerliche Einordnung einer E-Rechnung ist grundsätzlich der strukturierte Teil maßgeblich. Stimmen strukturierter und bildhafter Teil voneinander ab, sind deshalb die strukturierten Daten besonders relevant.
Bei der Erzeugung hybrider Rechnungen sollte daher sichergestellt werden, dass strukturierte und visuelle Darstellung inhaltlich konsistent erzeugt werden.
Nicht jedes Unternehmen benötigt dieselbe Feldlogik. Die Anforderungen richten sich nach Geschäftsmodell, Rechnungsempfängern, Systemlandschaft und Automatisierungsgrad.
Eine robuste Feldstrategie zeichnet sich insbesondere dadurch aus, dass Datenquellen und Zuordnungen nachvollziehbar sind, Validierungsfehler analysiert werden können und Änderungen an Standards kontrolliert übernommen werden.
| Bewertungskriterium | Verbesserungsbedarf | Robuste Ausprägung |
|---|---|---|
| Dokumentation der Feldregeln | Zuordnungen sind nur einzelnen Mitarbeitenden bekannt | Wichtige Zuordnungen und Regeln sind nachvollziehbar dokumentiert |
| Stammdatenqualität | Häufige Inkonsistenzen und fehlende Daten | Relevante Stammdaten werden kontrolliert und gepflegt |
| Automatisierung | Viele vermeidbare manuelle Übertragungen | Geeignete Felder werden aus zuverlässigen Quellsystemen übernommen |
| Validierung | Technische Fehler werden erst spät erkannt | Technische Validierung unterstützt die frühzeitige Fehlererkennung |
| Partnerkommunikation | Empfängeranforderungen sind unklar | Relevante Referenzen und Anforderungen sind abgestimmt |
| Fehlerbehandlung | Fehler werden nur einzeln korrigiert | Wiederkehrende Ursachen werden identifiziert und an der Quelle behoben |
| Nachvollziehbarkeit | Mapping und Regeln sind schwer nachvollziehbar | Wesentliche Feld- und Transformationslogiken sind dokumentiert |
Die Implementierung sollte Rechnungsdaten entsprechend der eingesetzten Spezifikation erzeugen. Ein geeignetes Validierungstool kann Schema-, Geschäftsregel- und Codelistenfehler sichtbar machen.
Ein positives Validierungsergebnis zeigt, dass die geprüften technischen Regeln erfüllt wurden. Es ist jedoch keine umfassende Bestätigung, dass die Rechnung steuerlich und sachlich in jeder Hinsicht korrekt ist.
Neben der technischen Prüfung sollten Rechnungsinformationen zum tatsächlichen Geschäftsvorgang passen. Dazu gehören beispielsweise Beträge, Steuersachverhalt, Referenzen und Leistungsinformationen.
Wo möglich, sollten Informationen aus zuverlässigen Quellsystemen übernommen werden. Manuelle Eingaben sollten insbesondere bei häufig verwendeten Stammdaten reduziert werden.
Ein bestimmter Automatisierungsgrad – beispielsweise 70 oder 80 Prozent – ist jedoch kein allgemeiner Qualitätsstandard und sollte nicht pauschal vorgegeben werden.
Bei E-Rechnungen ist zumindest der strukturierte Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form vorliegt. Die umsatzsteuerliche Aufbewahrungsfrist für Rechnungen beträgt grundsätzlich acht Jahre.
Validierungsreports, Checksummen oder umfangreiche technische Audit-Trails können für interne Kontrollen und Fehleranalysen sinnvoll sein. Eine pauschale Pflicht, all diese Informationen zusammen mit jeder Rechnung acht Jahre aufzubewahren, besteht jedoch nicht allein aufgrund der E-Rechnung.
Das lässt sich nicht sinnvoll auf eine kurze allgemeingültige Liste reduzieren. XRechnung basiert auf der EN 16931 und enthält verpflichtende, bedingte und optionale Business Terms sowie zusätzliche Geschäftsregeln.
Welche Informationen in einem konkreten Rechnungssachverhalt erforderlich sind, sollte deshalb anhand der jeweils aktuellen XRechnung-Spezifikation und der konkreten Rechnung geprüft werden.
BT-10 bezeichnet die Käuferreferenz. Im B2G-Bereich kann darüber beispielsweise eine vom öffentlichen Auftraggeber vorgegebene Leitweg-ID übermittelt werden.
BT-13 bezeichnet die Referenz auf die Bestellung des Käufers. Beide Informationen haben unterschiedliche fachliche Bedeutungen und sollten entsprechend dem tatsächlichen Geschäftsvorgang verwendet werden.
Öffentliche Auftraggeber und andere Rechnungsempfänger können bestimmte Referenzinformationen für ihre internen Zuordnungsprozesse verlangen. Ist eine erforderliche Referenz nicht vorhanden oder falsch, kann die Rechnung je nach Empfängersystem und dessen Regeln zurückgewiesen oder einer manuellen Klärung zugeführt werden.
Nein. Eine gesetzliche Vorgabe zu einem bestimmten Automatisierungsgrad gibt es nicht. Wenn Daten zuverlässig aus ERP- oder Stammdatensystemen übernommen werden können, kann Automatisierung jedoch Fehler und manuelle Arbeit reduzieren.
Bei Sonderfällen oder nicht eindeutig verfügbaren Informationen können weiterhin manuelle Eingaben beziehungsweise Kontrollen erforderlich sein.
Bei einer E-Rechnung muss zumindest der strukturierte Teil so aufbewahrt werden, dass er unversehrt in seiner ursprünglichen Form vorliegt. Die umsatzsteuerliche Aufbewahrungsfrist für Rechnungen beträgt grundsätzlich acht Jahre.
Das BMF stellt ausdrücklich klar, dass allein die Speicherung einer E-Rechnung außerhalb eines GoBD-konformen Datenverarbeitungssystems regelmäßig noch keinen Verstoß gegen die umsatzsteuerliche Aufbewahrungspflicht darstellt.
Nicht pauschal. Validierungsreports können für technische Fehleranalyse, interne Kontrollen und Dokumentation sinnvoll sein. Eine allgemeine umsatzsteuerliche Verpflichtung, für jede E-Rechnung dauerhaft einen Validierungsreport mit aufzubewahren, besteht jedoch nicht.
Ja. Im B2G-Bereich gelten zusätzliche Vorgaben des jeweiligen öffentlichen Auftraggebers beziehungsweise der einschlägigen E-Rechnungsregelungen. Dazu können beispielsweise bestimmte Empfängerreferenzen oder Übertragungswege gehören.
Die umsatzsteuerlichen B2B-Regelungen sollten deshalb nicht mit den zusätzlichen technischen und organisatorischen Anforderungen des öffentlichen Rechnungsverkehrs gleichgesetzt werden.
Ein Validierungstool prüft eine strukturierte Rechnung gegen technische Format- und Geschäftsregeln. Dabei können beispielsweise fehlende Informationen, ungültige Codes oder logische Widersprüche erkannt werden.
Das BMF empfiehlt eine Validierung insbesondere bei Erstellung und Versand einer E-Rechnung, stellt aber ausdrücklich klar, dass sie keine unmittelbare Voraussetzung für die steuerliche Anerkennung der Rechnung ist.
Nicht zwingend. Technische oder geschäftsregelbasierte Fehler können dazu führen, dass eine Rechnung vom Empfängersystem zurückgewiesen wird. Das konkrete Verhalten hängt jedoch vom Fehler, vom verwendeten Validator und von den Regeln des Empfängersystems ab.
Deshalb sollte nicht pauschal davon ausgegangen werden, dass jede fehlerhafte Rechnung automatisch oder sofort abgelehnt wird.
Ja. Beide Formate können – bei Verwendung geeigneter Versionen beziehungsweise Profile – die Anforderungen an eine E-Rechnung erfüllen.
Welches Format verwendet wird, kann von den technischen Möglichkeiten und Anforderungen der beteiligten Geschäftspartner abhängen.
Bei regelmäßig benötigten Referenzen kann es sinnvoll sein, Geschäftspartnern klar mitzuteilen, welche Informationen für die eigene Verarbeitung benötigt werden und in welcher Form sie übermittelt werden sollen.
Dabei sollte zwischen gesetzlichen Anforderungen, Anforderungen eines Standards und zusätzlichen internen Anforderungen des Rechnungsempfängers unterschieden werden.
Ein präzises Verständnis strukturierter Rechnungsinformationen ist eine wichtige Grundlage für stabile E-Rechnungsprozesse. Business Terms der EN 16931 ermöglichen eine einheitliche fachliche Beschreibung der Rechnungsdaten und bilden damit die Grundlage für Formate wie XRechnung.
Unternehmen sollten relevante Feldzuordnungen dokumentieren, Stammdaten pflegen und technische Validierung einsetzen, um Fehler möglichst früh zu erkennen. Dabei ist wichtig, gesetzliche Vorgaben und interne Best Practices voneinander zu unterscheiden.
Eine Validierung vor dem Versand ist sinnvoll und wird vom BMF empfohlen, ist aber keine unmittelbare Voraussetzung für die steuerliche Anerkennung. Ebenso ist nicht jede technische Abweichung automatisch mit einer sofortigen Zurückweisung verbunden.
Für die Aufbewahrung gilt grundsätzlich eine Frist von acht Jahren. Bei E-Rechnungen muss zumindest der strukturierte Teil unversehrt in ursprünglicher Form erhalten bleiben. Zusätzliche Audit-Trails, Validierungsreports oder Integritätsmechanismen können den Prozess unterstützen, sollten aber nicht pauschal als gesetzlich zwingende Voraussetzung dargestellt werden.