What is UBL? The format, the file and the UBL invoice

UBL (Universal Business Language) is an open standard for business documents. A UBL invoice is therefore an invoice in that format: a structured, machine-readable XML file that accounting software reads, checks and prepares for entry on its own. Unlike a PDF, nobody has to retype the details. In this article you can read how UBL works, from creating an invoice through to sending and processing it. On top of that: what a UBL file contains, how it differs from XML and PDF, what the advantages and drawbacks are, and which misconceptions cause the most trouble.

Three things to separate first. UBL is the format of the document, Peppol is the network you send it over, and e-invoicing is the obligation behind it. People use the terms interchangeably, but you can email UBL invoices without Peppol, and Peppol carries documents other than invoices. In the Netherlands, SI-UBL is the common variant.

Looking for something more specific? If you have invoices in PDF that you want to convert, read converting invoices to UBL. To see the two formats side by side, that comparison sits further down this article. If you work with loose PDF files, read PDF to UBL converter. And to jump straight to how such a file is built up, go to the field table.

Table of contents

• What is UBL?
• What does a UBL file contain?
• UBL, XML and PDF: the difference
• Which UBL versions and variants are there?
• How do you create a UBL invoice?
• How do you send a UBL invoice?
• How do you process a UBL invoice you receive?
• What are the advantages and drawbacks of UBL?
• Four misconceptions about UBL
• UBL, Peppol and the e-invoicing obligation
• Is a UBL invoice mandatory?
• Frequently asked questions about UBL
• In closing

What is UBL?

UBL is an international standard that sets out which fields a business document contains and what those fields are called. That sounds abstract, but the effect is very concrete: because the invoice number always sits in the same field, software does not have to guess where to look. A person reads an invoice by looking at it; software reads a UBL invoice by reading out the fields. That is where the entire difference in processing time comes from.

What does a UBL file contain?

A UBL file carries the extension .ubl or .xml and holds the invoice details as structured fields. The UBL file format looks like this for part of an invoice of € 1,000 excluding VAT:

Detail	UBL field	Example value
Invoice number	cbc:ID	2026-0148
Invoice date	cbc:IssueDate	2026-09-09
Supplier	cac:AccountingSupplierParty	Example Ltd
VAT number	cbc:CompanyID	NL001234567B01
Amount excluding VAT	cbc:TaxExclusiveAmount	1000.00
VAT amount	cbc:TaxAmount	210.00
Total payable	cbc:PayableAmount	1210.00

Notice what happens here: the VAT amount of € 210 sits in a field of its own, separate from the total. As a result, software can post the VAT to the right ledger account straight away without working backwards. With a PDF, that amount first has to be recognised from the image, and there is always a chance that 1210 and 210 get swapped.

UBL invoice example

Inside the file itself, those same details look like this. This is a heavily shortened fragment; a real UBL invoice runs to dozens more lines.

<Invoice>
  <cbc:ID>2026-0148</cbc:ID>
  <cbc:IssueDate>2026-09-09</cbc:IssueDate>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:CompanyID>NL001234567B01</cbc:CompanyID>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">210.00</cbc:TaxAmount>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1210.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
</Invoice>

You can see here why nobody wants to read this by hand, and at the same time why software copes with it so well. Every amount sits in its own element with its own currency indicator, so there is nothing left to interpret.

UBL, XML and PDF: the difference

	Readable for people	Readable for software
PDF	yes	no, recognition required
Arbitrary XML	barely	only with per-supplier agreements
UBL	barely	yes, to a single standard

Every UBL invoice is an XML file, but not every XML file is UBL. That is more than wordplay: with loose XML you have to agree per supplier which field means what, whereas with UBL the standard settles it. And because UBL is barely readable for people, almost every package delivers a PDF alongside the UBL file so you can view and archive it.

In practice the two formats exist side by side. PDF is still the most widely sent invoice format in the Netherlands, particularly among sole traders and smaller businesses, simply because an entrepreneur without processing software has little use for a UBL file and wants a readable invoice. On the receiving side, however, UBL is growing fast, driven by government bodies and the Peppol network. As a result, accountancy firms increasingly take in a hybrid stream: UBL and PDF mixed together, in the same set of records.

Which UBL versions and variants are there?

UBL is maintained by OASIS. Version 1.0 arrived in 2004, 2.0 in 2006 and 2.1 in 2013; that last one was later also adopted as an international ISO/IEC standard. Newer versions followed, but in the Netherlands it is 2.1 that matters in practice. Wondering why a supplier mentions “UBL 2.0”? For an ordinary invoice the differences between 2.0 and 2.1 are small.

More important than the version number is the variant. Nobody implements the full standard, so there are profiles that pin down which fields you use and what they mean. These are the ones you come across in the Netherlands:

Variant	Where you meet it
SI-UBL	The common variant for both business traffic and supplies to government bodies, agreed within the Dutch Peppol authority. This is what you see most often in practice.
UBL-OHNL	The Dutch central government’s own variant, used together with Digipoort and therefore only for supplies to government bodies.
NLCIUS	The Dutch interpretation of the European standard EN 16931. It determines which fields are mandatory in a core invoice.
Peppol BIS	The European specification for exchange over Peppol, which uses part of UBL.

Because of this, it is not always clear up front which fields your software can take over. If you receive invoices that come through only half filled, the problem lies in the variant more often than in the standard. To check what has been formally laid down in the Netherlands, see the list held by Forum Standaardisatie.

How do you create a UBL invoice?

Writing a UBL file by hand is complex and error-prone, because the XML format demands exact structures. Let your invoicing or accounting package do the work instead: most packages, such as Exact, Twinfield or Moneybird, export an invoice directly as UBL alongside the ordinary PDF. That way a couple of clicks produce a correct UBL invoice, and you never need to study the field names from the table above.

How do you send a UBL invoice?

Sending happens in the package you invoice from. You create the sales invoice, choose UBL as the output and send it along one of these three routes:

• By email. You attach the UBL file, usually alongside the PDF. That works without signing up to any network, but your customer has to read the file in themselves.
• Through Peppol. Your package or access point delivers the invoice to your customer’s Peppol ID. As a result it lands straight in their records, with no email in between.
• Through a customer portal. Large buyers and government bodies sometimes ask for an upload in their own portal, with UBL as the prescribed format.

Note the division of roles. TriFact365 sits on the receiving side: you get a Peppol ID and receive Peppol invoices there, which then wait for you as an entry proposal. Sending your own sales invoices is therefore arranged in your invoicing or accounting package, not here.

How do you process a UBL invoice you receive?

When a UBL invoice comes in, your processing tool reads the fields directly and prepares an entry proposal; all that is left for you is the check. TriFact365 recognises both UBL files and PDFs and turns them into an entry proposal inside your own portal, which moves to your accounting package once you approve it. If you still receive mostly PDFs, automated invoice processing converts those into usable data first. Either way, the retyping disappears.

What are the advantages and drawbacks of UBL?

In short: UBL speeds up processing on the receiving side, but it does not solve everything. Both sides are set out below, because that second half goes unmentioned in most explanations.

Advantages of UBL

• No retyping. Amounts, dates and numbers come straight out of the file, so no typing errors creep in during entry.
• VAT lands in the right place. Because every amount sits in its own field, nobody has to work backwards from the total to the VAT amount.
• One file for every package. The standard is fixed, so you make no per-supplier arrangements about how the file is laid out.
• Faster through the check. What is left is judging rather than entering. As a result, less time goes into the step before an invoice is ready to pay.

Drawbacks of UBL

• Not readable for people. You always need a PDF or a view inside your software to actually look at the invoice and archive it.
• The sender has to play along. If a supplier only sends PDFs, you cannot force them. For that stream you still need recognition.
• The variant decides what comes through. If a supplier leaves a field empty, it stays empty in your records too. That sits in the profile, not in the standard.
• It replaces character recognition, not booking recognition. This is the drawback that gets skipped most often. The details arrive reliably, but which ledger account and which VAT code belong to them is not in the file. That mapping remains work.

So UBL is a starting point rather than an end point. It takes the retyping out of the process, but the question of where an invoice should be posted still stands. That is exactly the work processing software takes over.

Four misconceptions about UBL

• “UBL and XML are the same thing.” UBL is one specific XML standard. If a supplier sends you “an XML invoice”, ask whether it is UBL, because otherwise your package has to be configured per supplier.
• “A PDF with data inside it is UBL too.” Hybrid formats do exist in which data travels inside a PDF, but that is not UBL. Your package has to support it explicitly.
• “With UBL I am ready for Peppol.” The format is one thing, being connected to the network is another. For Peppol you also need a Peppol ID and an access point.
• “With UBL there is nothing left to check.” The details are read in reliably, but whether the invoice is correct on substance, whether it belongs to an order and whether it may be paid remains a human judgement.

UBL, Peppol and the e-invoicing obligation

UBL is the format of the invoice, Peppol is the network you use to send and receive those invoices securely. On top of that, e-invoicing is becoming mandatory in more and more places: in the Netherlands already for supplies to government bodies, and in Belgium between businesses since 1 January 2026. At European level this expands further over the coming years through ViDA. Therefore, if you already work with UBL, the step towards such an obligation is small, because the format is in order and only the sending channel is left to arrange.

Is a UBL invoice mandatory?

A lot gets mixed up here, so first the most important nuance: UBL itself is nowhere mandatory. What is being made mandatory is e-invoicing, meaning a structured format instead of a PDF. UBL is the most widely used implementation of that in the Netherlands, but it is not the only one. Where things stand:

• Do you supply Dutch government bodies? Then e-invoicing is mandatory. For central government that has applied since 2017, and under the European directive government bodies must be able to receive and process e-invoices.
• Do you invoice businesses within the Netherlands? Then there is no obligation at present. You may simply keep sending a PDF, even to large buyers. That some buyers demand UBL is their own purchasing condition, not the law.
• Do you invoice Belgian businesses? There, e-invoicing between businesses has been mandatory since 1 January 2026.
• And beyond that? Through ViDA, a European obligation for cross-border transactions arrives on 1 July 2030. That looks far off, but packages and buyers tend to move earlier than legislation.

Besides, something is already changing on the receiving side without any obligation. Because more and more suppliers send UBL along, almost every set of records now takes in a mixture of UBL and PDF. As a result, the practical question is not whether you have to, but whether your processing can handle both.

Frequently asked questions about UBL

In closing

UBL stops being complicated as soon as you see it as one thing: an agreement about where each detail sits. That agreement is exactly what allows software to read an invoice without anyone retyping it, and it is what separates a stack of PDFs from an administration that largely fills itself. The format is the foundation; the network and the obligations build on top of it.