UBL vs Factur-X vs ZUGFeRD

The short version

UBL is typically a structured XML invoice on its own. Factur-X and ZUGFeRD usually refer to hybrid workflows where a PDF invoice also carries machine-readable XML. XRechnung is another structured invoice format that matters in German public-sector and adjacent workflows. The practical difference is not just technical format; it changes how the file is received, viewed, and handed off.

Users often search these names as if they are four unrelated labels. In practice, the most useful comparison is simpler: is the invoice a standalone structured XML file, or is it a PDF that also hides structured XML inside it? That split tells you whether to start with a viewer, a detector, or an extractor.

Why users get confused

Many people think they are comparing three unrelated invoice standards. In practice, the real split is often between plain structured XML and hybrid PDF-plus-XML workflows. That is why a file can look like a normal PDF invoice and still behave like a structured invoice behind the scenes.

Confusion also happens because naming is inconsistent across vendor communication. One supplier says "UBL", another says "Peppol invoice", another says "Factur-X PDF", and another says "XRechnung". The receiving team may assume those all refer to the same thing. They do not. Some are document syntaxes, some are hybrid packaging approaches, and some are strongly tied to specific country or public-sector workflows.

How to choose the right Tooltensor page

If the file is already XML, start with the viewer or detector. If the file is PDF but should contain invoice data, start with the extractor. If you do not know what you were sent, the detector is the safest starting point because it can push you toward the right next step without pretending certainty.

This matters because the first wrong assumption wastes time. A team that opens a hybrid invoice as if it were only a PDF may miss the structured payload. A team that assumes every XML invoice can be read without context may still need to identify whether it behaves like UBL, CII, or another profile.

Practical decision rule

If the file opens like plain XML, think in terms of structured invoice review. If the file opens like a normal PDF but someone says it is machine-readable, think in terms of hybrid invoice extraction. That one distinction solves most early confusion.

Then ask a second question: is the workflow country-specific? For example, a German customer may expect XRechnung-related handling, while a French or German supplier may send a Factur-X or ZUGFeRD-style hybrid PDF. A Belgian B2B workflow may push more quickly toward UBL and Peppol-style exchange. The file itself gives you clues, but the business context matters too.

Common misunderstanding

People often compare UBL, Factur-X, and ZUGFeRD as if they only differ by label. The more useful comparison is file shape and workflow: standalone XML versus PDF plus embedded XML.

Another common misunderstanding is assuming XRechnung is just "another PDF invoice". It is not. In many cases it refers to structured public-sector invoice expectations where machine readability is the point, not a convenience feature.

What the structures look like

A simplified UBL invoice exposes explicit elements such as invoice number, date, totals, and parties directly in XML. A hybrid Factur-X or ZUGFeRD invoice uses a visible PDF document and pairs it with embedded XML so both human-readable and machine-readable versions travel together.

<Invoice>
  <cbc:ID>INV-2026-1048</cbc:ID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cac:AccountingSupplierParty>...</cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>...</cac:AccountingCustomerParty>
</Invoice>

That is why UBL and XRechnung-style files often move straight into a viewer, while Factur-X and ZUGFeRD files often need an extraction step before the XML can be inspected separately.

Which format will Belgian and German suppliers send?

Belgian suppliers moving into mandatory B2B e-invoicing are likely to encounter UBL and Peppol-style workflows more often, especially when invoice exchange is tied to structured network delivery. German suppliers are more likely to mention XRechnung in public-sector contexts and Factur-X or ZUGFeRD in hybrid invoice workflows. That does not mean the entire market is uniform, but it is a useful working assumption for first-pass review.

If the sender is in Belgium and the file is XML, start by assuming you may be looking at a UBL-related business invoice. If the sender is in Germany and the file is PDF but described as machine-readable, assume hybrid XML may be embedded and check with the extractor. If the sender mentions public procurement or German e-invoicing mandates, XRechnung becomes much more likely.

Workflow consequences

The choice of format changes who can do what with the document. Standalone XML is easier for software and often harder for humans until a viewer renders it cleanly. Hybrid PDFs are easier for humans but create an extra technical step if you need the XML payload. That is why operational teams should care about the format difference even if they do not care about standards terminology.

When teams skip this distinction, they end up misrouting invoices, relying on PDF-only workflows when structured data exists, or opening XML blindly without knowing whether the content is in the expected family. A simple early classification step prevents a large share of those errors.

Related pages

Run the format detector · Extract XML from a PDF · Read about PDF vs structured invoices