UBL (Universal Business Language): Aufbau und Einsatz der OASIS-Syntax

Herkunft und Rolle

UBL wird von OASIS gepflegt, einem Konsortium für offene Standards, und beschreibt nicht nur Rechnungen, sondern eine ganze Familie von Geschäftsdokumenten — Bestellung, Lieferschein, Katalog, Gutschrift. Die Rechnung ist ein Dokumenttyp darin.

In Europa ist UBL vor allem deshalb allgegenwärtig, weil Peppol darauf setzt. Wo öffentliche Beschaffung elektronisch abgewickelt wird, ist UBL fast immer die Syntax.

Der Aufbau

UBL legt die Gruppen flach nebeneinander statt sie tief zu verschachteln:

1ubl:Invoice
2├── cbc:CustomizationID      welches Regelwerk gilt (BT-24)
3├── cbc:ID                   Rechnungsnummer (BT-1)
4├── cbc:IssueDate            Rechnungsdatum (BT-2)
5├── cbc:BuyerReference       Käuferreferenz (BT-10)
6├── cac:AccountingSupplierParty   Verkäufer (BG-4)
7├── cac:AccountingCustomerParty   Käufer (BG-7)
8├── cac:PaymentMeans              Zahlungsangaben (BG-16)
9├── cac:TaxTotal                  Steuern
10├── cac:LegalMonetaryTotal        Summen
11└── cac:InvoiceLine                Positionen (BG-25)

Wer eine Rechnung zum ersten Mal im XML ansieht, findet sich hier meist schneller zurecht als in CII: Die Reihenfolge folgt grob der eines gedruckten Belegs.

cbc und cac

Die beiden Präfixe teilen alle Elemente in zwei Klassen:

• cbc — Common Basic Components: einzelne Werte. Eine Nummer, ein Datum, ein Betrag.
• cac — Common Aggregate Components: Gruppen, die wiederum Elemente enthalten. Eine Partei, eine Adresse, eine Position.

Die Faustregel: Was ein Blatt im Baum ist, ist cbc. Was einen Ast bildet, ist cac.

Ein Feld an seinem Platz

Dieselbe Umsatzsteuer-Identifikationsnummer (BT-31) wie im CII-Artikel, hier in UBL:

1<cac:AccountingSupplierParty>
2  <cac:Party>
3    <cac:PartyLegalEntity>
4      <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
5    </cac:PartyLegalEntity>
6    <cac:PartyTaxScheme>
7      <cbc:CompanyID>DE811128135</cbc:CompanyID>
8      <cac:TaxScheme>
9        <cbc:ID>VAT</cbc:ID>
10      </cac:TaxScheme>
11    </cac:PartyTaxScheme>
12  </cac:Party>
13</cac:AccountingSupplierParty>

Der Unterschied zu CII ist gut sichtbar: Wo CII die Art der Nummer über ein Attribut (schemeID="VA") unterscheidet, benutzt UBL ein eigenes Unterelement (cac:TaxScheme mit VAT). Dieselbe Aussage, andere Mechanik.

Die Spezifikationskennung

Ein Element verdient besondere Aufmerksamkeit, weil es über die gesamte Prüfung entscheidet:

1<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>

An dieser Kennung (BT-24) erkennt ein Empfänger, nach welchem Regelwerk er prüfen muss. Steht dort nur die europäische Norm, prüft er nicht gegen die deutschen Zusatzregeln — und eine Rechnung, die eigentlich eine XRechnung sein sollte, kommt als einfache EN-16931-Rechnung an.

🔴 Eine falsche CustomizationID erzeugt keinen Fehler. Sie erzeugt eine Prüfung gegen das falsche Regelwerk, und das fällt erst beim Empfänger auf.

Wann Sie es mit UBL zu tun bekommen

Beim Erzeugen immer dann, wenn Peppol BIS das Ziel ist — dort gibt es keine Alternative. Bei der XRechnung ist UBL die verbreitetere der beiden zulässigen Varianten.

Beim Empfangen genauso zwangsläufig wie CII. Wer Rechnungen aus mehreren Quellen bekommt, bekommt beide Syntaxen, und zwar unangekündigt.

💡 Deshalb gilt hier derselbe Rat wie bei CII: Die Syntax gehört an die Außengrenze, nicht ins eigene Datenmodell. Intern in BT-Feldern zu denken macht den Wechsel zwischen UBL und CII zu einer Frage der Ausgabe — und nicht zu einem Umbau der Fachlogik.