Factur-X vs UBL vs CII vs Peppol BIS

Here is the reassuring bit: they are mostly the same invoice

Underneath all four names sits one thing: EN 16931, the European semantic standard for electronic invoicing. It defines the meaning of an invoice — which fields exist, what they mean, which are mandatory — without saying how to write them down. Everything below is just a different way of writing down that same model.

So you are not choosing between different invoices. You are choosing a container and a delivery route. That is why approved platforms can convert between them, and generally do.

What each one is

Factur-X — the hybrid PDF

One file that does both jobs. It is an ordinary PDF/A-3 document — open it and you see a normal invoice a human can read — with a structured XML file tucked inside it, in the UN/CEFACT CII syntax, carrying the same figures machine-readably. Technically it is the same standard as the German ZUGFeRD 2.x, published jointly by the French FNFE-MPE and its German counterpart.

Watch out for one thing. Factur-X comes in profiles of increasing completeness — MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED. The lower ones carry header-level data only and are not a full EN 16931 invoice, so "we send Factur-X" is not actually an answer on its own. Ask your customer which profile their platform expects.

Choose it when your customer's staff still want to look at a PDF, or your own system already produces a good-looking PDF you would rather not lose.

UBL — plain XML, the widely-used one

Universal Business Language, an OASIS standard. A pure XML file with no visual rendering at all — there is nothing to look at, and that is rather the point. It is the syntax most European e-invoicing tooling already speaks, and the one sitting underneath Peppol.

Choose it when you already issue e-invoices anywhere else in Europe. Chances are you are producing UBL today without having thought about it.

CII — plain XML, the UN/CEFACT one

Cross Industry Invoice, from UN/CEFACT. The other XML syntax EN 16931 allows, and the one hiding inside a Factur-X PDF. On its own it does the same job as UBL — same model, different element names.

Choose it when your customer's platform asks for it, or when you are already generating the CII payload for Factur-X and sending it bare is less work than wrapping it.

Peppol BIS Billing 3.0 — a profile plus a network

Peppol BIS Billing 3.0 is a specification built on EN 16931 and written in UBL syntax, with extra rules on top. The difference that matters: Peppol is also a delivery network. You send through an access point, your customer receives through theirs, and addressing works by Peppol participant identifier rather than by email.

Choose it when you are already on Peppol for other countries and your customer's French platform accepts Peppol inbound. If both of those are true, you may need to change nothing but the address.

Side by side

Where these numbers come from, so you can weigh them properly: the approved-platform survey this site publishes — 148 platforms, self-reported format support. Not from the DGFiP, which registers platforms but does not publish a format matrix. You can browse the underlying rows on the approved platforms page. And a platform that does not list a format may still accept it, so treat this table as a good starting point for the conversation, not the final answer.

How to actually choose

Five steps, in the order that saves you the most work.

1. Ask the customer, not the internet. Their approved platform decides what arrives cleanly, and they are the only people who can tell you which profile and which routing level to use.
2. Check what you already produce. If you issue UBL or Peppol BIS for other European customers, start there. Building Factur-X because it is "the French one" is a common and completely avoidable expense.
3. Let the platform do the converting. Approved platforms are built around Factur-X, UBL and CII and convert between them, so agreeing on the one you can already emit is usually fine.
4. Validate before you send. This one catches people out: a structurally valid file that breaks an EN 16931 business rule gets rejected just as firmly as a PDF, and the message comes back through the platform rather than to your inbox. See what a rejection looks like.
5. Send one test invoice. Do it before 1 September 2026, while a wrong SIRET is still a five-minute fix.

The usual caveat: this is a description of a standard and a regulation, not tax or legal advice. Format and profile choices have commercial consequences, so confirm them with your customer in writing.

Frequently asked questions