What Is a UBL Invoice? UBL 2.1, CIUS and the Dutch SI-UBL Profile

The short answer

A UBL invoice is an invoice written as an XML document in the OASIS Universal Business Language, version 2.1 — the same standard published by ISO and IEC as ISO/IEC 19845. Its root element is Invoice, and every field inside it comes from two shared vocabularies UBL defines: basic components like an issue date or a line amount, and aggregate components like a party, an address or a tax subtotal.

That is the whole of what UBL is, and it is less than most people assume. UBL says which elements may appear. It does not say which ones anybody will insist on. A file can be flawless UBL and still be rejected the moment it arrives, because the rules that decide acceptance live in three layers above the syntax.

This page walks those four layers, explains what a Core Invoice Usage Specification — a CIUS — may and may not change, and answers the question that brings most Dutch readers here: whether Simpler Invoicing still exists, and what replaced it.

What does a UBL invoice actually look like inside?

A UBL invoice is one XML document with a single root element:

<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:CustomizationID>…</cbc:CustomizationID>
  <cbc:ProfileID>…</cbc:ProfileID>
  <cbc:ID>INV-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-08-23</cbc:IssueDate>
  …
</Invoice>

Three namespaces do all the work, and recognising them makes any UBL file readable:

• The document namespace identifies the kind of document. …xsd:Invoice-2 is an invoice; a credit note has its own.
• cbc: — CommonBasicComponents — holds the simple values. An identifier, a date, an amount, a code.
• cac: — CommonAggregateComponents — holds the structures. A party, a postal address, an invoice line, a tax subtotal. Aggregates nest, which is how a line contains an item which contains a classification code.

UBL 2.1 was released by OASIS on 4 November 2013, and it is still the version Peppol billing is built on. The billing library is larger than invoices alone — orders, despatch advices, catalogues and application responses are all UBL documents — but in billing, two document types do nearly all the work: Invoice and CreditNote.

Why is valid UBL not enough?

Because UBL is a vocabulary, not a rulebook. It is permissive by design: it has to serve industries and countries that disagree about what an invoice needs, so it allows far more than any one of them wants.

EN 16931 is the layer that fixes that for Europe. It is a semantic standard — a list of business terms a core invoice must be able to carry, each with a definition and a cardinality, written in business language rather than XML. "Seller VAT identifier" is a business term; whether it appears as cac:PartyTaxScheme/cbc:CompanyID is a syntax question EN 16931 leaves to the binding.

So the two standards answer different questions, and a document has to satisfy both:

An invoice can pass the UBL schema and fail EN 16931 outright, because the schema will happily accept a document missing something the European standard requires.

What is a CIUS, and what is it allowed to change?

A Core Invoice Usage Specification is a profile that narrows EN 16931 for a particular community without changing what anything means. The mechanism is defined in EN 16931 itself, in chapter 7.

The restriction is the point. Because a CIUS may only narrow, a document valid against a CIUS is automatically valid against EN 16931 — you get community-specific strictness without losing interoperability with everyone else who follows the core standard.

Anything that cannot be expressed as a narrowing is an extension, not a CIUS, and a document using one has left plain EN 16931 behind.

Where does Peppol BIS Billing 3.0 sit?

It is a CIUS, and it says so in its own opening paragraph — that it is a Core Invoice Usage Specification of EN 16931, following the guidance given in chapter 7 of EN 16931, and that any instance document compliant with it will be compliant with the European standard.

Its Appendix A lists the restrictions it applies, and reading that list is the fastest way to understand what a CIUS does in practice. They fall into recognisable shapes: marking values in a code list as not allowed, adding a rule to an element that already exists, and — more sweepingly — removing whole business processes. Two of EN 16931's processes are declared out of scope rather than supported: corrective invoicing, on the grounds that the distinction between a corrective invoice and a credit note was unclear, and partial and final invoicing.

If you have ever wondered why a UBL invoice that looked reasonable was refused by a Peppol access point, this is usually the answer. The refusal came from the profile, not from UBL.

Where does the Dutch Simpler Invoicing profile sit?

This is the question behind most searches that reach us for "Simpler Invoicing UBL", and the honest answer has two halves.

The organisation no longer exists. Stichting Simplerinvoicing — the Dutch foundation that built the profile — ceased to exist on 31 December 2020. Its website says so in both Dutch and English and redirects visitors to the Netherlands Peppol Authority, which took over the role. OpenPeppol's own register of Peppol Authorities lists the Netherlands under the Netherlands Peppol Authority (NPa), which operates on behalf of the Dutch Ministry of the Interior and Kingdom Relations.

The profile did not go anywhere. What Simplerinvoicing built lives on as SI-UBL 2.0, the Dutch CIUS of EN 16931, written in the Authority's own publications as SI-UBL 2 (NLCIUS). It is still maintained and still released on the ordinary Peppol schedule — the Authority published its most recent validation artefacts for SI-UBL 2 and Peppol BIS 3 in the May 2026 release, dated 22 May 2026, with the release before it in November 2025.

So if you are searching for Simpler Invoicing, SI-UBL 2.0 is the thing you are looking for, and the Netherlands Peppol Authority is who maintains it.

What the Netherlands asks for on top

The Authority names two mandatory document-level standards — SI-UBL 2.0 and Peppol BIS Billing 3.0 — carried over the Peppol AS4 profile at transport level. It also names which identifiers may be used for Dutch parties: a Chamber of Commerce number (NL:KVK, scheme 0106), a VAT identifier (NL:VAT, scheme 9944), or an NL:OIN (scheme 0190). The OIN is required for central government, provinces and municipalities; other organisations may choose between the KVK and VAT forms.

Peppol's national rules for Dutch suppliers then apply on top, and they are fatal rather than advisory. Among them:

A further set of Peppol common rules checks the shape of those identifiers rather than their presence — that a KVK number is eight digits, that a Dutch VAT identifier reads NL123456789B12 — and these are raised as warnings rather than fatal findings.

None of this changes UBL. Every one of these rules is a constraint on a document that was already valid UBL 2.1.

And PINT?

PINT is the same idea applied outside Europe: a Peppol billing model with a shared core and jurisdiction-specific profiles, used where EN 16931 is not the governing standard — PINT Oman for the Fawtara programme, PINT A-NZ, PINT Japan. It is UBL too, and it travels the same network, but it is a different base with different rule sets. We have written that comparison separately in Peppol vs PINT: the difference explained rather than repeat it here.

How do you tell which profile a UBL invoice follows?

Read its CustomizationID. That one element declares which specialisation the document claims to follow, and the receiving system uses it to decide which rule set to run against the file. A second element, ProfileID, says which business process the document belongs to.

This is why "is my invoice valid UBL?" is rarely the useful question. A document announces its own profile, and it is then judged against that profile's rules. Validating against UBL alone tells you the XML is well shaped and almost nothing about whether it will be accepted.

What this means if you are building or buying

Three things follow from the four layers, and they are worth stating plainly:

1. Ask which profile, not which format. "We support UBL" is close to meaningless on its own. The question that matters is which CustomizationID a system emits, and whether that is the one your counterparty or your tax authority expects.
2. Validate against the profile, not the schema. Schema validation catches malformed XML. Every other class of rejection — a missing business term, a forbidden code value, a national rule — is caught only by running the profile's own rules.
3. Expect the jurisdiction layer to be where the work is. Moving from a domestic profile to another country's is rarely a syntax change. It is a data change, and it usually lands on whoever maintains the customer master rather than on whoever maintains the integration.

GoRoute validates documents against the profile they declare rather than against UBL alone, which is why a validation response names the rule that fired by its own identifier instead of returning a bare pass or fail. You can read the underlying terms in our e-invoicing glossary, or start from what Peppol is and how the network fits together.

Sources

• OASIS UBL 2.1, the standard itself and its XML schemas — also published as ISO/IEC 19845. The schemas quoted here are the OASIS release of 4 November 2013.
• Peppol BIS Billing 3.0 — its statement that it is a CIUS of EN 16931, its Appendix A list of restrictions, and its national rules for the Netherlands.
• Netherlands Peppol Authority — the mandatory standards, the Dutch Peppol identifier schemes, and the SI-UBL 2 (NLCIUS) release notices.
• Simplerinvoicing — the foundation's own notice that it ceased to exist on 31 December 2020.
• OpenPeppol's register of Peppol Authorities — the Netherlands entry.

All read on 23 August 2026.