UBL 2.1 Explained: The XML Standard Behind Modern E-Invoicing

UBL 2.1 (Universal Business Language version 2.1) is the OASIS XML standard for representing 65 business document types — orders, despatch advices, invoices, credit notes, catalogues, statements. It was ratified as an OASIS Standard on 4 November 2013 and is the canonical XML syntax for EN 16931 in Europe, the base format for Peppol BIS Billing 3.0, ZATCA Phase 2 KSA, MyInvois Malaysia, and several other regimes. Every regulator that picked UBL 2.1 did so because it is open, royalty-free, schema-validated, and supports jurisdiction-specific extensions without breaking interoperability.

Why UBL 2.1 keeps appearing

If you read the spec for almost any current e-invoicing mandate — Peppol, ZATCA Phase 2, MyInvois — UBL 2. 1 is underneath.

If you read the spec for almost any current e-invoicing mandate — Peppol, ZATCA Phase 2, MyInvois — UBL 2.1 is underneath. Knowing it is what lets you debug rejections.

What UBL 2.1 actually is

UBL — Universal Business Language — is an OASIS XML standard for procure-to-pay business documents.

UBL — Universal Business Language — is an OASIS XML standard for procure-to-pay business documents. Version 2.1 was ratified by OASIS on 4 November 2013 and defines 65 document types: invoice, credit note, order, order response, despatch advice, receipt advice, catalogue, application response (used for MLR), statement, remittance advice, and more. The schemas live at docs.oasis-open.org/ubl/os-UBL-2.1/.

Why regulators chose UBL 2.1

Open OASIS standard with no licensing cost. Coverage of every procure-to-pay document a tax authority cares about.

• Open OASIS standard with no licensing cost.
• Coverage of every procure-to-pay document a tax authority cares about.
• Strong extension model (UBL extensions container) lets jurisdictions add country-specific fields without breaking core interoperability.
• Tooling exists in every language (Java, .NET, Python, PHP, Go, Node).
• It is the syntax EN 16931 chose, which made it the default across the EU.

Invoice structure — the key blocks

Invoice structure — the key blocks includes: cbc:CustomizationID — identifies the CIUS/Extension (e. g.

• cbc:CustomizationID — identifies the CIUS/Extension (e.g. urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 for Peppol BIS 3.0).
• cbc:ProfileID — business process (e.g. urn:fdc:peppol.eu:2017:poacc:billing:01:1.0).
• cac:AccountingSupplierParty + cac:AccountingCustomerParty — party data with identification schemes.
• cac:InvoiceLine — per-line item, quantity, price, tax category.
• cac:TaxTotal + cac:TaxSubtotal — VAT breakdown by category.
• cac:LegalMonetaryTotal — totals: line extension, tax exclusive, tax inclusive, payable.
• cac:PaymentMeans — UNCL 4461 payment method code + IBAN/BIC.
• ext:UBLExtensions — container for jurisdiction-specific extensions (ZATCA QR + signature; XRechnung Leitweg-ID).

How each regime customises it

Peppol BIS Billing 3. 0: CIUS of EN 16931 in UBL 2.

• Peppol BIS Billing 3.0: CIUS of EN 16931 in UBL 2.1 with Peppol Schematron rules and restricted identifier schemes.
• ZATCA Phase 2 (Saudi Arabia): UBL 2.1 with KSA extensions for the Previous Invoice Hash (PIH), TLV QR, XAdES signature with CSID, Arabic seller name, and KSA invoice type subtype codes.
• MyInvois (Malaysia): UBL 2.1 (JSON profile also accepted) with LHDN-issued UUID, validation URL embedded as QR, and additional MSIC industry code.
• XRechnung (Germany B2G): CIUS of EN 16931 in UBL 2.1 or CII with mandatory Leitweg-ID buyer reference.
• OIOUBL (Denmark): Denmark's pre-EN 16931 profile; still in use alongside Peppol BIS.
• A-NZ Peppol BIS (Australia/New Zealand): Peppol BIS 3.0 with A-NZ identifier schemes and GST-specific rules.

UBL 2.1 vs CII (UN/CEFACT)

EN 16931 permits two syntaxes: UBL 2. 1 (OASIS) and UN/CEFACT Cross Industry Invoice (CII).

EN 16931 permits two syntaxes: UBL 2.1 (OASIS) and UN/CEFACT Cross Industry Invoice (CII). UBL is more widely tooled and adopted; CII is mandatory for some German federal use cases and is the XML inside ZUGFeRD/Factur-X hybrid PDFs. Most platforms convert between the two internally so the user picks one canonical model.

UBL 2.1 vs EN 16931

EN 16931 is the European semantic standard — it defines what fields a compliant invoice must carry. UBL 2.

EN 16931 is the European semantic standard — it defines what fields a compliant invoice must carry. UBL 2.1 is one of the two permitted syntaxes (the other is CII). When you read "Peppol BIS Billing 3.0", read it as "EN 16931 semantic, in UBL 2.1 syntax, with Peppol's CIUS layer".

What this means for your platform

You should not be hand-writing UBL 2. 1.

You should not be hand-writing UBL 2.1. The right abstraction is a logical invoice object; the platform serialises that to UBL 2.1 in the customisation profile the destination mandate requires. Invoicemonk emits UBL 2.1 in the Peppol BIS Billing 3.0, ZATCA KSA, MyInvois, and XRechnung profiles from the same invoice record.

Key takeaways

Key takeaways includes: UBL 2. 1 = OASIS XML standard, 65 document types, ratified 2013.

• UBL 2.1 = OASIS XML standard, 65 document types, ratified 2013.
• It is the syntax under almost every modern e-invoicing mandate.
• Customisations layer on top: CIUS to restrict, Extension to add.
• Abstract the invoice as data, let the platform handle the syntax.

Related reading

Pillar: e-invoicing. Siblings: XAdES digital signatures explained, what is a Peppol Access Point, Peppol EU explained.

Pillar: e-invoicing. Siblings: XAdES digital signatures explained, what is a Peppol Access Point, Peppol EU explained.

Sources

• OASIS — Universal Business Language Version 2.1 (OASIS Standard, 4 Nov 2013)
• OASIS — UBL 2.1 PDF specification
• Peppol BIS Billing 3.0 — UBL Invoice tree
• CEN — EN 16931 publication notice
• KoSIT — XRechnung specification (German B2G CIUS)
• UN/CEFACT — Cross Industry Invoice (alternative syntax)