Das UBL Format gehört zu den wichtigsten technischen Standards für den elektronischen Austausch strukturierter Geschäftsdokumente. Besonders im Zusammenhang mit elektronischen Rechnungen, Peppol, XRechnung und internationalen E-Invoicing-Anforderungen begegnen Unternehmen immer häufiger der Abkürzung UBL.
Doch was verbirgt sich tatsächlich dahinter? Ist jede UBL-Datei automatisch eine gesetzeskonforme E-Rechnung? Was unterscheidet eine UBL Format E-Rechnung von XRechnung oder ZUGFeRD? Welche Version ist für EN 16931 relevant? Und wie lässt sich das UBL Format SAP-seitig verarbeiten?
Dieser Leitfaden beantwortet diese Fragen aus fachlicher und technischer Sicht. Sie erfahren, wie Universal Business Language aufgebaut ist, welche Rolle XML spielt, wie UBL Invoice und Peppol zusammenhängen, wie die Validierung funktioniert und worauf Unternehmen bei der Integration in SAP- und ERP-Landschaften achten sollten.
Ein wichtiger Punkt vorweg: Das UBL Format ist wesentlich mehr als ein Rechnungsformat. OASIS definiert UBL als generisches XML-Austauschformat für Geschäftsdokumente. Neben Rechnungen enthält der Standard unter anderem Dokumenttypen für Bestellungen, Versandinformationen, Gutschriften und zahlreiche weitere Geschäftsprozesse. Die aktuelle allgemeine OASIS-Version UBL 2.4 umfasst 93 Geschäftsdokumenttypen.
Das Wichtigste zum UBL Format in Kürze
UBL steht für Universal Business Language. Dabei handelt es sich um einen von OASIS entwickelten offenen XML-Standard für strukturierte elektronische Geschäftsdokumente. Das Ziel besteht darin, unterschiedlichen IT-Systemen eine gemeinsame maschinenlesbare Sprache für den Austausch von Geschäftsinformationen bereitzustellen.
Für elektronische Rechnungen ist insbesondere der Dokumenttyp UBL Invoice relevant. Eine UBL Format Invoice enthält Rechnungsinformationen nicht primär als visuelle Darstellung, sondern als eindeutig strukturierte XML-Daten. ERP-Systeme können dadurch beispielsweise Rechnungsnummern, Geschäftspartner, Beträge, Steuerinformationen und Positionen direkt auslesen und weiterverarbeiten.
Wichtig ist jedoch die Unterscheidung zwischen dem allgemeinen UBL-Standard und konkreten E-Invoicing-Spezifikationen. Die aktuelle allgemeine OASIS-Version ist UBL 2.4, veröffentlicht am 20. Juni 2024. Für die europäische elektronische Rechnungsstellung nach EN 16931 ist dagegen weiterhin das definierte Syntax Binding zu UBL 2.1 maßgeblich. Die Europäische Kommission weist ausdrücklich darauf hin, dass eine neuere UBL-Version nicht automatisch anstelle der normativ gebundenen Version eingesetzt werden kann.
Für Unternehmen bedeutet dies: Wer eine UBL Format XML-Rechnung erstellt, sollte niemals nur fragen, ob die Datei technisch UBL entspricht. Entscheidend ist vielmehr, welches fachliche Profil, welche Version und welche Geschäftsregeln für den konkreten Empfänger und Übertragungskanal gelten.
Inhaltsverzeichnis
- Was ist das UBL Format?
- Was ist eine UBL Rechnung?
- Wie funktioniert eine UBL Format E-Rechnung?
- Wie ist eine UBL Format Invoice aufgebaut?
- UBL Format Beispiel – Wie sieht eine UBL-Rechnung aus?
- Welche Pflichtangaben muss eine UBL Rechnung enthalten?
- Ist eine UBL Format E-Rechnung automatisch EN-16931-konform?
- Welche Version des UBL Format wird für elektronische Rechnungen verwendet?
- Was ist der Unterschied zwischen UBL und XRechnung?
- UBL, XRechnung, ZUGFeRD und Peppol – wo liegen die Unterschiede?
- Wie kann man eine UBL Format XML-Rechnung öffnen?
- Wie lässt sich eine UBL Rechnung auf Fehler prüfen und validieren?
- Wie wird eine UBL Format Invoice über Peppol versendet?
- Wo wird das UBL Format eingesetzt?
- Welche Vorteile bietet das UBL Format?
- Welche Herausforderungen gibt es beim UBL Format?
- UBL Format SAP – Wie lässt sich UBL in SAP integrieren?
- Welche Rolle spielt SAP Document and Reporting Compliance beim UBL Format SAP?
- UBL Format SAP und SAP Invoice Management by OpenText
- Wie startet man mit einer UBL Format E-Rechnung?
- Best Practices für das UBL Format
- Don'ts beim UBL Format
- Zukunft des UBL Format: UBL 2.4, EN 16931-1:2026 und XRechnung 4.0
- Fazit – Warum das UBL Format für digitale Rechnungsprozesse so wichtig ist
- Häufig gestellte Fragen zum UBL Format
Was ist das UBL Format?
Das UBL Format ist ein standardisiertes XML-basiertes Datenmodell für elektronische Geschäftsdokumente. UBL wurde von OASIS entwickelt, um Unternehmen, Behörden und Softwaresystemen eine gemeinsame Syntax für den elektronischen Geschäftsdatenaustausch zur Verfügung zu stellen.
OASIS beschreibt UBL als generisches XML-Austauschformat, das sowohl eingeschränkt als auch erweitert werden kann, um Anforderungen bestimmter Branchen oder Geschäftsprozesse abzubilden. Der Standard enthält wiederverwendbare Komponenten wie Adressen, Artikelinformationen oder Zahlungsdaten sowie vollständige Dokumentstrukturen etwa für Invoice, Order und Despatch Advice.
Das bedeutet: UBL definiert nicht lediglich, wie eine Rechnung aussieht. Vielmehr bildet der Standard Teile einer kompletten elektronischen Supply Chain ab.
Typische UBL-Geschäftsdokumente sind beispielsweise:
- Invoice
- Credit Note
- Order
- Order Response
- Despatch Advice
- Receipt Advice
- Catalogue
- Remittance Advice
Die aktuelle OASIS-Version UBL 2.4 wurde im Juni 2024 als OASIS Standard veröffentlicht. Sie ist rückwärtskompatibel zu UBL 2.3, 2.2, 2.1 und 2.0 und umfasst inzwischen 93 Geschäftsdokumenttypen.
Damit eignet sich UBL nicht nur für Finance und Accounting, sondern auch für digitale Einkaufs-, Bestell-, Liefer- und Logistikprozesse.
Wofür steht UBL?
UBL bedeutet:
Universal Business Language
Der Name beschreibt das grundlegende Ziel: Unterschiedliche Organisationen und Softwaresysteme sollen Geschäftsdaten in einer standardisierten Sprache austauschen können.
Ein SAP-System muss dadurch beispielsweise nicht die proprietäre Datenstruktur eines ERP-Systems des Geschäftspartners verstehen. Sender und Empfänger können stattdessen auf eine gemeinsam definierte UBL-Struktur abbilden.
Was ist eine UBL Rechnung?
Eine UBL-Rechnung ist ein elektronischer Rechnungsdatensatz, der auf der Dokumentstruktur „Invoice“ des UBL-Standards basiert.
Im Zusammenhang mit dem Neben-Keyword UBL Format Invoice ist daher vor allem eine Unterscheidung wichtig:
UBL bezeichnet den umfassenden Standard.
UBL Invoice bezeichnet einen konkreten Dokumenttyp innerhalb dieses Standards.
Das normative Invoice-Schema der allgemeinen OASIS-Version 2.4 heißt beispielsweise UBL-Invoice-2.4.xsd. OASIS ordnet den Dokumenttyp dem Billing-Prozess zu.
Eine UBL Format XML-Rechnung speichert die einzelnen Informationen in strukturierten Elementen. Anstelle eines Textes wie:
„Rechnungsnummer: 4711“
existiert beispielsweise ein eindeutig adressierbares XML-Element für die Rechnungsnummer.
Dadurch kann ein empfangendes System den Inhalt nicht nur darstellen, sondern fachlich interpretieren.
Genau dies unterscheidet strukturierte elektronische Rechnungen von klassischen PDF-Rechnungen.
Mehr zur technischen Grundlage strukturierter Rechnungsdaten finden Sie im Beitrag:
XML-Rechnung: Aufbau, Vorteile und Anforderungen
Wie funktioniert eine UBL Format E-Rechnung?
Eine UBL Format E-Rechnung durchläuft typischerweise mehrere technische und fachliche Ebenen.
Zunächst entstehen die Rechnungsinformationen im ERP-, Faktura- oder Buchhaltungssystem. Dazu gehören beispielsweise der Rechnungsempfänger, die Rechnungsnummer, Positionen, Preise, Steuersätze und Zahlungsinformationen.
Anschließend werden diese internen Daten auf die vorgegebene UBL-Struktur abgebildet. Welches Mapping erforderlich ist, hängt vom Zielprofil ab.
Eine Rechnung für einen Peppol-Prozess folgt beispielsweise nicht einfach nur dem allgemeinen OASIS-Schema. Zusätzlich müssen die fachlichen und technischen Regeln der verwendeten Peppol Business Interoperability Specification eingehalten werden. Beim aktuellen Peppol BIS Billing 3.0 enthält eine UBL Invoice beispielsweise einen CustomizationID zur Identifikation der Spezifikation und einen ProfileID für den Prozesskontext.
Danach folgt die Validierung. Anschließend wird das Dokument über den vereinbarten Übertragungsweg an den Empfänger versendet.
Der typische Ablauf lautet daher:
ERP-Daten → Mapping → UBL/XML → Validierung → Übertragung → Eingang → Validierung → ERP-Verarbeitung
Bei einer vollständig integrierten Lösung kann dieser Prozess weitgehend ohne manuelle Datenerfassung stattfinden.
Wie ist eine UBL Format Invoice aufgebaut?
Eine UBL Invoice ist hierarchisch aufgebaut.
Das Wurzelelement ist bei einer Rechnung Invoice. Innerhalb dieses Elements befinden sich zahlreiche Basic Components und Aggregate Components.
Die beiden häufig auftretenden Präfixe sind:
cbc – Common Basic Components
Dabei handelt es sich um einzelne Basisinformationen wie Rechnungsnummer, Datum, Betrag oder Währung.
cac – Common Aggregate Components
Diese Elemente fassen komplexere Strukturen zusammen, beispielsweise Geschäftspartner, Steuerinformationen, Zahlungsdaten oder Rechnungspositionen.
Eine typische Rechnung enthält unter anderem:
- Rechnungsidentifikation
- Rechnungsdatum
- Rechnungsart
- Währung
- Lieferant
- Rechnungsempfänger
- Steuerinformationen
- Zahlungsinformationen
- Gesamtsummen
- eine oder mehrere Rechnungspositionen
Die konkrete Kardinalität und die zulässigen Inhalte hängen wiederum vom verwendeten Profil ab. Im Peppol BIS Billing 3.0 sind beispielsweise Rechnungsnummer, Ausstellungsdatum, Invoice Type Code und Dokumentwährung verpflichtende Informationen; zudem muss mindestens eine Rechnungsposition vorhanden sein.
UBL Format Beispiel – Wie sieht eine UBL-Rechnung aus?
Ein vereinfachtes UBL Format Beispiel kann folgendermaßen aussehen:
<?xml version="1.0" encoding="UTF-8"?> <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"> <cbc:UBLVersionID>2.1</cbc:UBLVersionID> <cbc:ID>RE-2026-1001</cbc:ID> <cbc:IssueDate>2026-08-18</cbc:IssueDate> <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cac:AccountingSupplierParty> <cac:Party> <cac:PartyName> <cbc:Name>Beispiel Lieferant GmbH</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingSupplierParty> <cac:AccountingCustomerParty> <cac:Party> <cac:PartyName> <cbc:Name>Beispiel Kunde AG</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingCustomerParty> <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">200.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine> </Invoice>
Dieses UBL Format Beispiel ist bewusst vereinfacht und dient ausschließlich dazu, die XML-Struktur verständlich zu machen.
Es ist nicht automatisch eine vollständige EN-16931-, XRechnung- oder Peppol-konforme Rechnung. Für eine produktive Rechnung müssen alle Regeln des jeweiligen Profils, die erforderlichen Steuerelemente, Summen, Identifikatoren, Code-Listen und Geschäftsregeln eingehalten werden. Dass eine Datei formal eine UBL Invoice ist, genügt für regulatorische Konformität allein nicht.
Welche Pflichtangaben muss eine UBL Rechnung enthalten?
Diese Frage lässt sich nicht allein anhand des UBL Format beantworten.
UBL stellt zunächst die technische Syntax und eine umfangreiche Datenstruktur bereit. Welche Informationen zwingend erforderlich sind, hängt vom verwendeten Anwendungsprofil und den gesetzlichen Vorgaben ab.
Für eine europäische E-Rechnung können beispielsweise Anforderungen aus folgenden Ebenen zusammenwirken:
- Umsatzsteuerrecht
- EN 16931
- nationale CIUS
- XRechnung
- Peppol BIS Billing
- länderspezifische Steuerregeln
- individuelle Geschäftsprozessanforderungen
Für Deutschland verlangt das Umsatzsteuerrecht bei einer E-Rechnung grundsätzlich ein strukturiertes elektronisches Format, das die automatische elektronische Verarbeitung ermöglicht. XRechnung entspricht dabei der europäischen Norm und den deutschen Anforderungen.
Typische Rechnungsinformationen sind unter anderem Rechnungsnummer, Rechnungsdatum, Lieferant und Kunde, steuerliche Identifikatoren, Rechnungspositionen, Mengen, Preise, Steuerkategorien, Steuerbeträge und Gesamtsummen.
Im konkreten Projekt sollte daher nicht die Frage gestellt werden:
„Welche Felder hat UBL?“
Sondern:
„Welche Business Terms sind für unser Zielprofil verpflichtend und wie werden sie auf UBL gemappt?“
Diese Denkweise verhindert einen der häufigsten Fehler bei E-Invoicing-Projekten.
Ist eine UBL Format E-Rechnung automatisch EN-16931-konform?
Nein. Nicht jede UBL-Rechnung ist automatisch eine gültige E-Rechnung nach EN 16931.
Das ist eine der wichtigsten Aussagen dieses Artikels.
Die europäische Norm definiert ein semantisches Datenmodell. Die Informationen dieses Modells werden anschließend über sogenannte Syntax Bindings auf bestimmte technische Syntaxen abgebildet.
Die Europäische Kommission führt für die bisherige EN-16931-Implementierung zwei relevante XML-Syntaxen auf:
- UBL Invoice und Credit Note 2.1
- UN/CEFACT Cross Industry Invoice D16B
Eine Rechnung muss dabei nicht nur die technische UBL-Syntax verwenden, sondern auch die Vorgaben des Syntax Bindings und gegebenenfalls eines darauf aufbauenden Profils erfüllen.
Das bedeutet:
Eine beliebige UBL-2.1-Rechnung ist nicht automatisch EN-16931-konform.
Eine beliebige UBL-2.4-Rechnung ist ebenfalls nicht automatisch EN-16931-konform.
Eine entsprechend dem verbindlichen Syntax Binding erzeugte und nach den einschlägigen Geschäftsregeln validierte UBL-Rechnung kann dagegen eine EN-16931-konforme E-Rechnung darstellen.
Weiterführend:
Welche Version des UBL Format wird für elektronische Rechnungen verwendet?
Hier entstehen besonders häufig Missverständnisse.
Aktuelle allgemeine UBL-Version: UBL 2.4
Die derzeit aktuelle allgemeine OASIS-Version ist UBL 2.4. Sie wurde am 20. Juni 2024 als OASIS Standard veröffentlicht.
Europäische E-Rechnung: UBL 2.1 bleibt relevant
Für die etablierte europäische Syntaxbindung der EN 16931 wird UBL 2.1 verwendet. Die Europäische Kommission weist ausdrücklich darauf hin, dass das Syntax Binding an eine bestimmte Syntaxversion gebunden ist und nicht einfach durch eine neuere UBL-Version ersetzt werden darf.
Diese Unterscheidung ist für Implementierungsprojekte äußerst wichtig.
UBL 2.4 ist der aktuelle allgemeine OASIS-Standard.
UBL 2.1 ist derzeit weiterhin die zentrale produktive Syntax für EN-16931-basierte Rechnungsprofile.
Neue EN 16931-1:2026
Im Mai 2026 wurde die neue EN 16931-1:2026 veröffentlicht. Die vorherige Version von 2017 wurde formal zurückgezogen, bleibt nach Angaben der Europäischen Kommission jedoch während einer Migrationsphase weiterhin compliant. Die Migration der zugehörigen technischen Komponenten, nationalen Standards und Implementierungen erfolgt schrittweise.
Für Unternehmen bedeutet das: Versionsmanagement gewinnt weiter an Bedeutung. Ein Update sollte nicht dadurch erfolgen, dass lediglich eine Versionsnummer in einer XML-Datei geändert wird. Entscheidend sind immer die offiziellen Syntax Bindings, Validierungsartefakte, Profile und nationalen Implementierungsvorgaben.
Was ist der Unterschied zwischen UBL und XRechnung?
UBL und XRechnung befinden sich auf unterschiedlichen Ebenen.
UBL ist eine generische technische Syntax beziehungsweise ein Standard für elektronische Geschäftsdokumente.
XRechnung ist dagegen ein deutscher Standard für elektronische Rechnungen und eine Umsetzung der europäischen E-Invoicing-Anforderungen. XRechnung kann die beiden europäischen Syntaxen UBL und CII verwenden. Die aktuell von KoSIT ausgewiesene Spezifikation XRechnung 3.0.2 enthält ausdrücklich ein Syntax Binding für UBL 2.1.
Vereinfacht formuliert:
UBL = technische Sprache
EN 16931 = semantisches Rechnungsmodell
XRechnung = deutsche Konkretisierung bzw. CIUS und Standard
Eine UBL Format E-Rechnung kann somit eine XRechnung sein – muss es aber nicht.
KoSIT weist im August 2026 weiterhin XRechnung 3.0.2 als aktuelle Spezifikation aus. Die Arbeiten an XRechnung 4.0 laufen bereits und sollen die neue EN 16931-1:2026 in Deutschland umsetzen.
UBL, XRechnung, ZUGFeRD und Peppol – wo liegen die Unterschiede?
Die Begriffe werden häufig miteinander vermischt, obwohl sie unterschiedliche Funktionen erfüllen.
| Begriff | Was ist es? | Technische Basis | Hauptfunktion |
|---|---|---|---|
| UBL Format | XML-Geschäftsdokumentstandard | XML | Strukturierter Datenaustausch |
| EN 16931 | Semantische E-Rechnungsnorm | Semantisches Modell | Einheitliche Bedeutung der Rechnungsdaten |
| XRechnung | Deutsche E-Rechnungsspezifikation | UBL oder CII | Nationale Umsetzung der E-Rechnung |
| ZUGFeRD / Factur-X | Hybrides Rechnungsformat | PDF/A-3 + CII XML | Menschlich und maschinell lesbare Rechnung |
| Peppol BIS Billing | Interoperabilitätsspezifikation | UBL | Standardisierter Rechnungsaustausch |
| Peppol | Netzwerk und Regelwerk | u. a. Peppol BIS | Sicherer Dokumententransport |
Der entscheidende Punkt: Peppol ist nicht dasselbe wie UBL.
Peppol definiert Infrastruktur, Prozesse, Teilnehmeridentifikation und Business Interoperability Specifications. Bei Peppol BIS Billing werden Rechnungsinformationen in einer eingeschränkten und mit Geschäftsregeln versehenen UBL-Struktur übertragen.
Auch ZUGFeRD unterscheidet sich technisch deutlich vom UBL Format. Die strukturierte XML-Komponente von ZUGFeRD beziehungsweise Factur-X basiert auf UN/CEFACT Cross Industry Invoice und nicht auf UBL.
Wie kann man eine UBL Format XML-Rechnung öffnen?
Da eine UBL-Rechnung eine XML-Datei ist, kann sie technisch mit jedem Text- oder XML-Editor geöffnet werden.
Für Fachanwender ist die reine XML-Darstellung jedoch häufig schwer lesbar. Die Informationen sind primär für maschinelle Verarbeitung strukturiert.
Für die komfortable Anzeige eignen sich deshalb:
- spezielle E-Rechnungsviewer,
- ERP-Systeme,
- DMS- oder Invoice-Management-Lösungen,
- XML-Viewer,
- XRechnung- oder Peppol-Viewer.
Die Visualisierung sollte dabei von der eigentlichen strukturierten Rechnungsdatei unterschieden werden.
Eine Darstellung kann aus den XML-Daten erzeugt werden. Die zugrunde liegende strukturierte Datei bleibt jedoch das relevante maschinenlesbare Dokument. Auch das BMF beschreibt strukturierte E-Rechnungen als XML-basiertes Datenformat, das mittels Visualisierungsanwendung menschenlesbar dargestellt werden kann.
Wie lässt sich eine UBL Rechnung auf Fehler prüfen und validieren?
Eine professionelle Validierung einer UBL Format Invoice erfolgt auf mehreren Ebenen.
1. XML-Wohlgeformtheit
Zunächst wird geprüft, ob die Datei syntaktisch gültiges XML darstellt. Nicht geschlossene Tags oder eine fehlerhafte Verschachtelung führen bereits auf dieser Ebene zu Fehlern.
2. XSD-Validierung
Anschließend kann das Dokument gegen das entsprechende XML Schema geprüft werden.
Damit wird beispielsweise festgestellt, ob ein Element an der vorgesehenen Stelle steht und den zulässigen Datentyp besitzt.
3. Geschäftsregelvalidierung
Die reine XSD-Prüfung reicht für eine regulatorische UBL Format E-Rechnung nicht aus.
Zusätzliche Geschäftsregeln prüfen fachliche Zusammenhänge. Beispielsweise können Regeln verlangen, dass mindestens eine Rechnungsposition vorhanden ist, Beträge korrekt summiert werden, definierte Identifikationsschemata genutzt werden oder Steuerinformationen zueinander passen.
Peppol veröffentlicht hierfür umfangreiche Validierungsregeln. Die May-2026-Spezifikation von Peppol BIS Billing enthält beispielsweise zahlreiche EN-16931- und Peppol-spezifische Regeln für Rechnungspositionen, Steuerangaben, Beträge und Codes.
4. Profilvalidierung
Zuletzt muss geprüft werden, ob das Dokument dem konkreten Zielprofil entspricht.
Beispiele sind:
- Peppol BIS Billing
- XRechnung
- nationale CIUS
- branchenspezifische Erweiterungen
Eine Datei kann somit technisch korrektes UBL sein und trotzdem beim Empfänger abgelehnt werden, weil sie dessen Geschäftsregeln nicht erfüllt.
Wie wird eine UBL Format Invoice über Peppol versendet?
Für den Austausch über Peppol müssen Sender und Empfänger nicht direkt eine Punkt-zu-Punkt-Verbindung miteinander betreiben.
Stattdessen erfolgt die Kommunikation über Peppol Access Points.
Eine typische Verarbeitung sieht so aus:
- Die Rechnung entsteht im ERP-System.
- Die Daten werden auf das benötigte Peppol-BIS-Profil abgebildet.
- Die UBL-Datei wird validiert.
- Das Dokument wird an den angebundenen Access Point übergeben.
- Peppol ermittelt die technische Erreichbarkeit des Empfängers.
- Der Access Point des Empfängers erhält das Dokument.
- Die UBL Format XML-Rechnung wird in dessen System weiterverarbeitet.
SAP dokumentiert einen vergleichbaren End-to-End-Prozess für SAP Document and Reporting Compliance: Das System erzeugt ein eDocument, mappt die Transaktionsdaten in das erforderliche Format, übergibt sie an die Cloud Edition als Peppol Access Point, führt Schematron-Prüfungen durch und verarbeitet anschließend die Zustellinformationen.
Weiterführend:
PEPPOL SAP – Netzwerk, Standard oder nur ein Teil der Lösung?
Wo wird das UBL Format eingesetzt?
UBL eignet sich überall dort, wo Geschäftsdokumente strukturiert zwischen unterschiedlichen Systemen ausgetauscht werden sollen.
Besonders relevant ist der Standard in folgenden Szenarien.
Elektronische Rechnungsstellung
Die UBL Format E-Rechnung ist eines der bekanntesten Anwendungsszenarien. UBL bildet eine der etablierten technischen Grundlagen für europäische E-Invoicing-Prozesse.
Peppol
UBL spielt eine zentrale Rolle in Peppol Business Interoperability Specifications, insbesondere im Billing-Umfeld.
Öffentliche Beschaffung
Durch EN 16931, nationale CIUS und E-Procurement-Standards ist UBL eng mit digitalen B2G-Prozessen verbunden.
B2B-E-Invoicing
Auch außerhalb der öffentlichen Verwaltung gewinnt die strukturierte Rechnungsstellung an Bedeutung. In Deutschland muss eine E-Rechnung seit 2025 grundsätzlich in einem strukturierten elektronischen Format ausgestellt, übertragen und empfangen werden und eine elektronische Verarbeitung ermöglichen; für die Ausstellungspflichten gelten gesetzliche Übergangsregelungen.
Digitale Beschaffung
Da UBL auch Orders, Order Responses, Despatch Advices und weitere Dokumente umfasst, lassen sich nicht nur Rechnungen, sondern komplette digitale Beschaffungsketten standardisieren. OASIS sieht UBL ausdrücklich für Procurement-, Delivery- und Payment-Prozesse vor.
Welche Vorteile bietet das UBL Format?
Der größte Vorteil von UBL liegt in der strukturierten und standardisierten Datenübertragung.
Interoperabilität
Sender und Empfänger müssen nicht dasselbe ERP-System verwenden. Solange beide Seiten dasselbe Profil korrekt unterstützen, können Daten systemübergreifend ausgetauscht werden.
Automatisierung
Eine UBL Format Invoice muss nicht wie eine PDF-Rechnung per OCR ausgelesen werden. Die relevanten Informationen befinden sich bereits in strukturierten Feldern.
Dadurch können Prozesse wie Validierung, Kontierung, Matching und Buchung stärker automatisiert werden.
Höhere Datenqualität
Strukturierte Daten reduzieren Übertragungsfehler durch manuelle Erfassung. Gleichzeitig ermöglichen Validierungsregeln eine frühzeitige Erkennung formaler und fachlicher Fehler.
Skalierbarkeit
Standardisierte Formate sind besonders interessant für Unternehmen mit vielen Geschäftspartnern oder internationalen Rechnungsprozessen.
Erweiterung auf weitere Geschäftsdokumente
Da das UBL Format nicht auf Rechnungen beschränkt ist, können Unternehmen perspektivisch Bestellungen, Versandinformationen, Gutschriften und weitere Dokumenttypen in eine durchgängige E-Procurement-Architektur integrieren.
Welche Herausforderungen gibt es beim UBL Format?
Trotz der Standardisierung ist UBL nicht automatisch „Plug and Play“.
Eine der größten Herausforderungen besteht darin, zwischen Syntax und Profil zu unterscheiden.
Ein Unternehmen kann technisch gültiges UBL erzeugen und dennoch eine Rechnung senden, die für Peppol, XRechnung oder den konkreten Empfänger ungültig ist.
Hinzu kommen:
- unterschiedliche nationale Anforderungen,
- verschiedene CIUS und Profile,
- Versionsmanagement,
- Code-Listen,
- Partneridentifikatoren,
- Mapping zwischen ERP- und UBL-Feldern,
- Änderungen regulatorischer Vorgaben,
- Validierungsregeln,
- Transport- und Routinganforderungen.
Gerade bei internationalen Rollouts sollte deshalb möglichst eine zentrale Governance für E-Invoicing-Formate und Mappings geschaffen werden.
UBL Format SAP – Wie lässt sich UBL in SAP integrieren?
Für Unternehmen mit SAP-Landschaften ist das Neben-Keyword UBL Format SAP besonders relevant.
In SAP-Projekten sollte zwischen drei Aufgaben unterschieden werden:
Erstellung beziehungsweise Transformation
SAP-Daten müssen aus FI, SD oder anderen Quellanwendungen in die benötigte externe Rechnungsstruktur überführt werden.
Übertragung und Compliance
Die Rechnung muss über den vorgesehenen Kanal an Geschäftspartner oder Behörden übermittelt werden.
Eingangsverarbeitung
Empfangene Rechnungen müssen geprüft, fachlich verarbeitet, freigegeben und gebucht werden.
SAP Document and Reporting Compliance bildet hierfür einen wichtigen Baustein. Die offizielle SAP-Dokumentation beschreibt das eDocument Framework als generische Grundlage für das Erstellen, Verarbeiten und Überwachen elektronischer Dokumente. SAP dokumentiert außerdem ein Szenario, in dem extern erzeugte Dokumente in einem generischen UBL Format an SAP S/4HANA beziehungsweise SAP ERP übergeben und anschließend als eDocuments weiterverarbeitet werden.
Weitere Informationen:
Welche Rolle spielt SAP Document and Reporting Compliance beim UBL Format SAP?
SAP Document and Reporting Compliance – kurz SAP DRC – unterstützt elektronische Dokumente und gesetzliches Reporting in SAP-Landschaften.
SAP beschreibt die Lösung als Framework, mit dem elektronische Dokumente aus Quellbelegen erzeugt sowie von Geschäftspartnern empfangene elektronische Dokumente verarbeitet werden können. Je nach unterstütztem Länder- und Geschäftsszenario können beispielsweise Kundenrechnungen erzeugt, Lieferantenrechnungen verarbeitet und Peppol-Prozesse integriert werden.
Beim UBL Format SAP kann SAP DRC unter anderem folgende Aufgaben übernehmen:
- Extraktion relevanter Daten aus SAP-Quellbelegen,
- Mapping in das erforderliche elektronische Format,
- Anlage und Monitoring von eDocuments,
- Integration von Peppol Exchange,
- Verarbeitung eingehender XML-Dokumente,
- Status- und Fehlermanagement.
Beim Peppol-Versand beschreibt SAP zusätzlich Schematron-Prüfungen und das Routing über die Cloud Edition beziehungsweise den Peppol-Prozess.
Wichtig ist jedoch: Nicht jede beliebige UBL-Variante wird automatisch in jedem Land und jedem Release unterstützt. Entscheidend sind der konkrete SAP-Release-Stand, die Lokalisierung, das E-Invoicing-Szenario und das benötigte Zielprofil.
Mehr zu SAP DRC:
SAP Document and Reporting Compliance
UBL Format SAP und SAP Invoice Management by OpenText
Während SAP DRC insbesondere die elektronische Dokument- und Compliance-Ebene adressiert, liegt der Schwerpunkt von SAP Invoice Management by OpenText auf der Automatisierung von Kreditorenprozessen.
SAP beschreibt die Anwendung als Lösung zur Digitalisierung und Automatisierung von Accounts-Payable-Prozessen, einschließlich Routing, Genehmigungen und Rechnungsverarbeitung in Verbindung mit SAP ERP.
Damit können beide Komponenten in einer End-to-End-Architektur unterschiedliche Rollen einnehmen:
SAP DRC
E-Invoicing, regulatorische Dokumente, externe Kommunikation, Transformation und Monitoring.
SAP Invoice Management by OpenText
Operative Rechnungsprüfung, Workflow, Ausnahmebehandlung und Freigabe.
Eine eingehende UBL Format XML-Rechnung kann beispielsweise über einen elektronischen Kanal empfangen, im eDocument-Prozess erfasst und anschließend an eine angebundene Eingangsautomatisierungslösung zur weiteren Rechnungsverarbeitung übergeben werden. SAP dokumentiert für elektronische Lieferantenrechnungen ausdrücklich die Integration mit Incoming-Automation-Lösungen.
Mehr zur Eingangsrechnungsverarbeitung:
SAP Invoice Management by OpenText
Wie startet man mit einer UBL Format E-Rechnung?
Eine professionelle Einführung sollte nicht mit der Programmierung eines XML-Mappings beginnen.
Schritt 1 – Zielprozess definieren
Zunächst muss geklärt werden:
Wer ist der Rechnungsempfänger?
In welchem Land findet der Vorgang statt?
Welcher Übertragungsweg wird verwendet?
Welche gesetzliche oder vertragliche Spezifikation gilt?
Schritt 2 – Profil festlegen
Erst danach wird entschieden, welches fachliche Profil erforderlich ist.
Beispiele:
- EN-16931-Syntax Binding
- XRechnung
- Peppol BIS Billing
- nationale CIUS
Schritt 3 – Quelldaten analysieren
Prüfen Sie, ob sämtliche erforderlichen Business Terms bereits im ERP-System vorhanden sind.
Fehlende steuerliche Identifikatoren, Bestellreferenzen oder Adressinformationen lassen sich nicht durch XML-Technik lösen.
Schritt 4 – Mapping erstellen
Anschließend werden ERP-Felder auf UBL-Elemente beziehungsweise die Business Terms des Zielprofils abgebildet.
Schritt 5 – XML erzeugen
Nun kann die eigentliche UBL Format Invoice generiert werden.
Schritt 6 – Mehrstufig validieren
Die Datei sollte technisch, semantisch und gegen die Geschäftsregeln des jeweiligen Profils validiert werden.
Schritt 7 – Übertragungsweg integrieren
Bei Peppol erfolgt beispielsweise die technische Kommunikation über einen Access Point.
Schritt 8 – Rückmeldungen verarbeiten
Accepted-, Rejected- oder technische Fehlermeldungen sollten automatisiert mit dem ursprünglichen SAP- beziehungsweise ERP-Beleg verknüpft werden.
Schritt 9 – Eingangsprozess integrieren
Bei empfangenen UBL-Rechnungen sollten Validierung, Rechnungsprüfung, Freigabe und Buchung möglichst ohne Medienbruch erfolgen.
Schritt 10 – Monitoring und Versionierung etablieren
Profile, Schematron-Regeln, Code-Listen und rechtliche Anforderungen ändern sich. E-Invoicing ist daher kein einmaliges Implementierungsprojekt, sondern benötigt dauerhaftes Lifecycle-Management.
Best Practices für das UBL Format
Do – Profil vor Syntax bestimmen
Fragen Sie zuerst nach der fachlichen Spezifikation und erst danach nach dem XML-Format.
„Wir unterstützen UBL“ ist als Anforderung zu ungenau.
Besser ist beispielsweise:
„Wir benötigen Peppol BIS Billing 3.0 in der definierten UBL-Syntax.“
Do – Validierung mehrstufig aufbauen
Prüfen Sie:
XML-Wohlgeformtheit, XSD, EN-16931-Regeln, Profilregeln, nationale Regeln und eigene Geschäftsregeln.
Do – Originaldaten strukturiert erhalten
Die UBL Format XML-Rechnung sollte während der weiteren Verarbeitung nicht auf eine reine PDF-Darstellung reduziert werden.
Do – Mappings zentral dokumentieren
Gerade internationale Unternehmen sollten dokumentieren, welches SAP-Feld auf welchen Business Term und welches UBL-Element abgebildet wird.
Do – Versionsmanagement etablieren
Die parallele Existenz von UBL 2.4 als allgemeinem OASIS-Standard und UBL 2.1 als weiterhin relevantem europäischen Syntax Binding zeigt, warum Versionsmanagement unverzichtbar ist.
Don’ts beim UBL Format
Don’t – UBL und EN 16931 gleichsetzen
Eine UBL-Datei ist nicht automatisch eine normkonforme E-Rechnung.
Don’t – einfach auf UBL 2.4 wechseln
Nur weil UBL 2.4 neuer ist, bedeutet das nicht, dass ein EN-16931-, XRechnung- oder Peppol-Profil diese Version produktiv voraussetzt.
Don’t – nur mit XSD validieren
Eine syntaktisch korrekte Datei kann fachlich trotzdem fehlerhaft sein.
Don’t – Peppol als Rechnungsformat verstehen
Peppol umfasst Netzwerk, Regelwerk und Interoperabilitätsspezifikationen. Die darin verwendete Rechnung kann in UBL repräsentiert werden.
Don’t – SAP-Mapping isoliert betrachten
Stammdaten, steuerliche Logik, Partneridentifikation, Prozessstatus und Archivierung gehören zur Gesamtarchitektur.
Zukunft des UBL Format: UBL 2.4, EN 16931-1:2026 und XRechnung 4.0
2026 befindet sich die europäische E-Invoicing-Landschaft in einer wichtigen Übergangsphase.
Auf der einen Seite existiert mit UBL 2.4 bereits seit 2024 eine weiterentwickelte allgemeine UBL-Version. Auf der anderen Seite basieren etablierte EN-16931-Syntax-Bindings weiterhin auf UBL 2.1.
Parallel wurde im Mai 2026 EN 16931-1:2026 veröffentlicht. Die Europäische Kommission weist darauf hin, dass die bisherige 2017er Version während einer Migrationsphase weiterhin compliant bleibt und die Umstellung durch Standardsorganisationen und nationale Behörden vorbereitet wird.
In Deutschland arbeitet KoSIT entsprechend an XRechnung 4.0. Die neue Version soll die Weiterentwicklung der europäischen Norm aufgreifen. Zum aktuellen Stand wird auf der offiziellen XRechnung-Seite weiterhin XRechnung 3.0.2 als gültige Spezifikation geführt.
Für Unternehmen ergibt sich daraus eine klare Handlungsempfehlung:
Nicht auf Versionsnummern reagieren, sondern auf verbindliche Profile und offiziell veröffentlichte Implementierungsartefakte.
Gerade SAP-Unternehmen sollten deshalb DRC-, Peppol-, Mapping- und Validierungskomponenten so gestalten, dass neue Versionen zentral eingespielt und getestet werden können.
Fazit – Warum das UBL Format für digitale Rechnungsprozesse so wichtig ist
Das UBL Format ist eine der wichtigsten technischen Grundlagen für standardisierten elektronischen Geschäftsdatenaustausch.
Seine Bedeutung reicht weit über die UBL Format Invoice hinaus. Universal Business Language unterstützt zahlreiche Dokumenttypen entlang von Beschaffungs-, Liefer- und Zahlungsprozessen und schafft dadurch eine gemeinsame XML-basierte Sprache für unterschiedliche Systeme.
Im E-Invoicing-Umfeld ist vor allem UBL 2.1 von besonderer Bedeutung, da es als Syntax für europäische E-Rechnungsprozesse und darauf aufbauende Profile genutzt wird. Gleichzeitig ist UBL 2.4 bereits der aktuelle allgemeine OASIS-Standard. Diese Unterscheidung ist für eine professionelle Implementierung entscheidend.
Unternehmen sollten außerdem klar zwischen UBL Format E-Rechnung, EN 16931, XRechnung, Peppol und ZUGFeRD unterscheiden. Die Begriffe beschreiben unterschiedliche technische und fachliche Ebenen.
Für SAP-Unternehmen entsteht eine zukunftsfähige Architektur insbesondere dann, wenn:
SAP beziehungsweise SAP S/4HANA die relevanten Geschäftsdaten bereitstellt,
SAP Document and Reporting Compliance die E-Invoicing- und Compliance-Prozesse unterstützt,
Peppol oder andere Kanäle für den Dokumentenaustausch integriert werden,
und Lösungen wie SAP Invoice Management by OpenText die operative Eingangsrechnungsverarbeitung automatisieren.
Wer das UBL Format SAP-seitig nicht als isolierte XML-Schnittstelle, sondern als Bestandteil eines durchgängigen Finance-, Procurement- und Compliance-Prozesses versteht, schafft die Grundlage für skalierbare internationale E-Invoicing-Prozesse.
Häufig gestellte Fragen zum UBL Format
Was ist eine UBL Rechnung und wie funktioniert sie?
Eine UBL-Rechnung ist eine strukturierte XML-Rechnung auf Basis des Universal-Business-Language-Standards. Ihre einzelnen Rechnungsinformationen sind in eindeutig definierten XML-Elementen gespeichert und können dadurch automatisch von ERP- und Buchhaltungssystemen verarbeitet werden.
Wie erstellt man eine UBL Rechnung im XML-Format?
Eine UBL Format XML-Rechnung wird in der Praxis meist aus einem ERP- oder Fakturasystem erzeugt. Die internen Rechnungsdaten werden auf ein konkretes UBL-Profil gemappt, als XML ausgegeben und anschließend gegen die relevanten technischen und fachlichen Regeln validiert.
Welche Pflichtangaben muss eine UBL Rechnung enthalten?
Das lässt sich nicht allein anhand von UBL bestimmen. Die Pflichtfelder ergeben sich aus dem angewandten Profil und den gesetzlichen Regeln. Bei EN-16931-, Peppol- oder XRechnung-Szenarien sind deshalb die jeweiligen Business Terms und Geschäftsregeln maßgeblich.
Was ist der Unterschied zwischen UBL Rechnung und XRechnung?
UBL ist eine generische XML-Syntax für Geschäftsdokumente. XRechnung ist eine deutsche E-Rechnungsspezifikation, die unter anderem UBL 2.1 als technische Syntax verwenden kann. XRechnung 3.0.2 ist aktuell die von KoSIT veröffentlichte Spezifikation; XRechnung 4.0 befindet sich in Vorbereitung.
Ist eine UBL Format E-Rechnung eine gültige E-Rechnung nach EN 16931?
Nicht automatisch. Eine UBL-Rechnung muss das definierte Syntax Binding sowie die relevanten semantischen und fachlichen Regeln erfüllen. UBL 2.1 gehört zu den für EN 16931 definierten Syntaxen.
Wie kann man eine UBL Rechnung öffnen und lesbar anzeigen?
Eine UBL-Datei kann grundsätzlich mit einem Text- oder XML-Editor geöffnet werden. Für Fachanwender sind spezielle E-Rechnungsviewer, ERP-Systeme oder Rechnungsmanagementlösungen besser geeignet, da sie die XML-Daten in einer übersichtlichen Darstellung visualisieren.
Wie lässt sich eine UBL Rechnung auf Fehler prüfen?
Eine professionelle Prüfung umfasst XML-Wohlgeformtheit, XSD-Validierung und fachliche Geschäftsregeln. Für Profile wie Peppol BIS Billing kommen zusätzliche Schematron- und Profilregeln hinzu.
Wie wird eine UBL Format Invoice über Peppol versendet?
Die Rechnung wird entsprechend der relevanten Peppol BIS erstellt und validiert und anschließend über einen Peppol Access Point übertragen. Der Empfänger erhält die strukturierte Nachricht über seinen angebundenen Access Point. SAP DRC Cloud Edition kann in unterstützten Szenarien in diesen Peppol-Prozess integriert werden.
Was ist der Unterschied zwischen UBL, ZUGFeRD und XRechnung?
UBL ist ein generischer XML-Standard. XRechnung ist eine deutsche E-Rechnungsspezifikation, die UBL oder CII nutzen kann. ZUGFeRD beziehungsweise Factur-X ist ein Hybridformat aus PDF/A-3 und eingebetteten strukturierten CII-Daten.
Welche UBL-Version wird für elektronische Rechnungen verwendet?
Die aktuelle allgemeine OASIS-Version ist UBL 2.4. Für die etablierte europäische E-Rechnungs-Syntaxbindung ist jedoch weiterhin UBL 2.1 relevant. Unternehmen sollten deshalb immer die Version des konkret anzuwendenden Profils prüfen.
Was bedeutet UBL Format SAP?
UBL Format SAP beschreibt die Erstellung, Verarbeitung oder Integration von UBL-basierten Geschäftsdokumenten innerhalb einer SAP-Landschaft. SAP Document and Reporting Compliance kann in unterstützten Szenarien elektronische Dokumente erzeugen, empfangen, transformieren, überwachen und mit Peppol-Prozessen verbinden.
Ist UBL nur für Rechnungen geeignet?
Nein. UBL umfasst zahlreiche Geschäftsdokumenttypen und unterstützt unter anderem Bestellung, Versand, Rechnung, Gutschrift und weitere Beschaffungs- und Logistikprozesse. Die aktuelle UBL-2.4-Spezifikation enthält 93 Geschäftsdokumenttypen.