Qu’est-ce que le format UBL ? Guide complet

Depuis le 1er septembre 2026, la facturation électronique B2B est obligatoire en France. Derrière cette réforme se cache un format largement supporté par les logiciels conformes, sans que personne n’en parle clairement : le langage XML standardisé que l’on appelle Universal Business Language, ou UBL. La question mérite d’être posée directement : de quoi s’agit-il concrètement, et pourquoi est-il devenu le langage commun des échanges commerciaux à l’échelle européenne ?

La réponse courte : vous n’aurez probablement jamais à ouvrir un tel fichier vous-même. Des solutions certifiées Plateforme de Dématérialisation Partenaire comme MyUnisoft génèrent ces fichiers automatiquement, en coulisse, à partir des données saisies dans le logiciel. Mais comprendre ce que ce format contient, c’est comprendre pourquoi votre logiciel fait ce qu’il fait, et pourquoi le choix de votre plateforme compte autant qu’il ne le semble.

À la fin de cet article, vous saurez ce qu’est ce standard XML, quelles versions existent, comment valider un fichier, et comment tout cela s’intègre dans la réforme française.

Un format né d’un consensus international, pas d’un choix arbitraire

L’Universal Business Language a été développé par OASIS (Organization for the Advancement of Structured Information Standards), un comité technique international dont la mission était de créer un vocabulaire XML commun pour automatiser les échanges commerciaux entre entreprises, sans dépendance à un éditeur logiciel particulier. L’objectif était ambitieux : qu’une facture émise par un logiciel puisse être lue, interprétée et traitée par n’importe quel autre logiciel, en France comme en Finlande, sans ambiguïté ni ressaisie.

La version 2.1 du standard a franchi un cap décisif en décembre 2015, en étant publiée comme norme internationale sous la référence ISO/IEC 19845:2015. Cette double étiquette, OASIS pour la gouvernance technique, ISO pour la légitimité réglementaire mondiale, est précisément la raison pour laquelle ce format s’est imposé dans les textes européens. La norme EN 16931, qui définit le modèle sémantique de la facture électronique européenne, l’admet comme syntaxe d’implémentation officielle aux côtés de UN/CEFACT CII.

Le réseau Peppol (Pan-European Public Procurement On-Line), piloté par OpenPeppol, a retenu ce standard comme format natif pour ses profils d’échange, notamment Peppol BIS Billing 3.0. Ce choix a été décisif : d’abord cantonné aux marchés publics, le format s’est progressivement diffusé dans l’ensemble des échanges B2B européens, portant avec lui l’interopérabilité transfrontalière que la réforme française suppose aujourd’hui.

Ce qu’un fichier UBL contient réellement

Le standard définit un grand nombre de types de documents commerciaux, mais trois d’entre eux couvrent la grande majorité des flux courants.
Le document Invoice (facture) déclenche le paiement. Le document Order (commande) initie l’achat.
Le document DespatchAdvice (avis d’expédition) notifie l’envoi des marchandises.
Chacun suit la même logique de structure hiérarchique en XML.

Une facture structurée selon ce format se compose de blocs imbriqués. Les principaux composants sont les suivants :

• cbc:ID, numéro de facture ;
• cbc:IssueDate, date d’émission ;
• cbc:DocumentCurrencyCode, devise ;
• cac:AccountingSupplierParty, émetteur ;
• cac:AccountingCustomerParty, destinataire ;
• cac:InvoiceLine, lignes de facturation ;
• cac:LegalMonetaryTotal, totaux financiers.

Les préfixes cbc désignent les composants de base (valeurs simples), et
cac les composants d’agrégat (blocs structurés).
Cette séparation n’est pas anecdotique : elle garantit que deux logiciels différents, même dans deux pays différents,
interprètent les mêmes données de la même façon.

Voici un extrait simplifié mais représentatif d’une facture conforme à la version 2.1 du standard :

<Invoice>
    <cbc:ID>FA-2026-00145</cbc:ID>
    <cbc:IssueDate>2026-09-01</cbc:IssueDate>
    <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
</Invoice>

Versions et schémas XSD : lesquels utiliser en 2026 ?

La version 2.1 reste la référence opérationnelle en 2026. C’est elle qui est normalisée sous ISO/IEC 19845:2015, et c’est elle que retient Peppol BIS Billing 3.0 ainsi que la norme EN 16931. Les schémas XSD correspondants se trouvent dans le paquet de publication OASIS, sous les chemins xsd/maindoc/UBL-Invoice-2.1.xsd pour la facture et xsd/maindoc/UBL-CreditNote-2.1.xsd pour l’avoir, téléchargeables sur docs.oasis-open.org.

La version 2.5 est la dernière publication OASIS en date, parue le 12 août 2026. Elle apporte des évolutions à la bibliothèque de documents et améliore certains schémas, mais elle n’a pas encore été intégrée dans les profils Peppol ni dans les réglementations nationales. En pratique, si votre objectif est la conformité Peppol ou la réforme française, vous devez cibler la version 2.1, pas la 2.5. Un éditeur qui annonce le support de la version 2.5 ne garantit pas automatiquement la conformité Peppol : il faut vérifier explicitement le support de Peppol BIS Billing 3.0 et d’EN 16931.

Pour une validation locale, il faut conserver l’arborescence complète du paquet OASIS, car les schémas principaux importent des composants situés dans les sous-dossiers xsd/common/. Télécharger uniquement le fichier UBL-Invoice-2.1.xsd sans ses dépendances aboutit à des erreurs d’importation. Pour des jeux de test, les dépôts GitHub de Tradeshift (tradeshift-ubl-examples), ConnectingEurope (eInvoicing-EN16931) et la suite de tests XRechnung proposent des exemples de fichiers prêts à l’emploi.

Valider un fichier UBL : deux niveaux, pas un seul

Une erreur fréquente consiste à croire qu’un fichier XML bien formé est un fichier valide au sens du standard. Ce n’est pas le cas. La validation se déroule en deux étapes distinctes, et c’est la seconde qui filtre les erreurs les plus coûteuses.

Validation XSD

La première étape vérifie que la structure du fichier est conforme au schéma officiel OASIS : bons éléments, bons types, bonne hiérarchie. C’est un contrôle de forme, nécessaire mais insuffisant.

Validation Schematron

La seconde étape contrôle la cohérence sémantique : montants calculés, champs obligatoires selon le profil déclaré, validité des codes utilisés. Ce niveau, piloté par les règles EN 16931 et les couches Peppol BIS Billing 3.0, détecte les erreurs qu’un schéma XSD ne peut pas exprimer, des montants incohérents entre les lignes et le total, une TVA mal calculée, ou un champ obligatoire absent selon le profil choisi.

Plusieurs outils couvrent ces deux niveaux :

• ValidateFin: validation en temps réel contre XSD et règles Peppol BIS Billing 3.0.
• NOMANA-IT UBL Tools: validation XSD et Schematron avec paquet EN 16931 intégré.
• InvoiceXML UBL & Peppol Validator API: couvre XSD version 2.1, Schematron EN 16931, Peppol BIS Billing 3.0 et couches nationales.
• Interoperability Test Bed (ITB) de la Commission européenne : paramétrable avec des artefacts XSD et Schematron externes.
• e-invoice.be / Peppol Invoice Viewer : trois couches de contrôle, du schéma XML au Schematron Peppol.

Avant toute mise en production, testez systématiquement avec deux validateurs différents. Les règles Schematron peuvent être interprétées légèrement différemment selon les implémentations, et un double contrôle évite les mauvaises surprises au moment de la transmission réelle.

UBL et la réforme française : ce que ça change pour vous concrètement

La réforme de la facturation électronique B2B repose sur un réseau d’échange entre Plateformes de Dématérialisation Partenaires (PDP) et le Portail Public de Facturation (PPF). Le réseau Peppol, qui assure l’interopérabilité entre ces plateformes, utilise nativement ce format XML via le profil Peppol BIS Billing 3.0. Résultat : les entreprises qui ont des clients ou des fournisseurs hors de France ont un intérêt direct à s’assurer que leur plateforme gère ce standard nativement, sans conversion intermédiaire.

La réforme française reconnaît trois formats structurés : Factur-X, UBL et CII. Toute facture B2B émise ou reçue doit désormais transiter par une PDP ou le PPF dans l’un de ces formats. Depuis septembre 2026, l’obligation est en vigueur pour les grandes entreprises, avec un calendrier progressif pour les ETI, les PME et les TPE. Les entreprises ne génèrent pas elles-mêmes leur XML à la main : c’est le rôle de leur logiciel ou de leur plateforme d’assurer la génération, la validation et la transmission des fichiers.

C’est précisément là qu’une solution comme MyUnisoft absorbe cette complexité. Conçue pour répondre aux exigences de la réforme, la plateforme génère les fichiers conformes à Peppol BIS Billing 3.0 et EN 16931 à partir des données saisies dans le logiciel, sans que le cabinet ou l’entreprise n’ait à intervenir sur le XML. Dans l’autre sens, une facture entrante dans ce format est lue, décodée et intégrée dans le flux comptable directement, sans ressaisie. Les équipes travaillent sur des données lisibles, pas sur des balises. C’est le gain de temps concret que représente une plateforme qui prend en charge l’intégralité du cycle technique.

Ce qu’il faut retenir

L’Universal Business Language n’est pas une contrainte technique de plus. C’est le langage commun qui rend possible l’interopérabilité des échanges commerciaux à l’échelle européenne. Sa structure XML rigoureuse, ses schémas XSD publics et accessibles, sa validation à deux niveaux en font un format fiable, auditable et indépendant de tout éditeur. Pour la réforme française, la version 2.1 est celle qui compte, et Peppol BIS Billing 3.0 en est le profil d’usage.

Pour un cabinet ou une entreprise, la question n’est pas de maîtriser ce format soi-même. C’est de choisir un outil qui le fait proprement à votre place, sans approximation ni dépendance à des conversions fragiles. C’est le rôle d’une plateforme conforme à la réforme. Si vous souhaitez savoir comment MyUnisoft gère ce cycle complet pour vos dossiers ou ceux de vos clients, l’équipe MyUnisoft est disponible pour en discuter.