UBL vs CII : quelle syntaxe XML de facturation choisir ?

Deux syntaxes XML peuvent représenter une facture électronique conforme à EN16931 : UBL 2.1 et UN/CEFACT Cross Industry Invoice (CII). Les deux sont correctes. Les deux sont acceptées par EN16931. Et les deux sont structurellement suffisamment différentes pour qu’un code écrit pour l’une ne puisse pas analyser l’autre sans une implémentation distincte.

Si vous construisez un pipeline de facturation en Europe en 2026, vous rencontrerez probablement les deux. Voici ce que vous devez savoir pour choisir la bonne et gérer l’autre.

Ce qu’elles ont en commun

UBL et CII sont toutes deux des sérialisations du même modèle sémantique : EN16931. Un nom de vendeur est un nom de vendeur. Un montant de TVA est un montant de TVA. Les termes métier (BT) et les groupes métier (BG) sont identiques dans les deux syntaxes.

EN 16931-2 définit le mappage officiel de chaque BT vers son chemin XML dans les deux syntaxes. Le document est disponible gratuitement auprès de CEN/TC 434 et constitue la référence de référence lorsque vous devez implémenter les deux.

Les deux formats sont basés sur des normes internationales et acceptés par les validateurs EN16931. Les deux produisent des factures structurées lisibles par machine.

Comment elles diffèrent structurellement

Les différences sont importantes et omniprésentes. Les noms d’éléments, les préfixes d’espaces de noms, les structures d’imbrication et les conventions d’attributs sont tous différents.

Nom du vendeur (BT-27)

UBL 2.1 :

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

CII :

<rsm:SupplyChainTradeTransaction>
  <ram:SellerTradeParty>
    <ram:Name>Acme GmbH</ram:Name>
  </ram:SellerTradeParty>
</rsm:SupplyChainTradeTransaction>

UBL utilise une imbrication profonde avec des espaces de noms de composants agrégés (cac:) et de base (cbc:). CII est plus plat, avec des espaces de noms ram: (Reusable Aggregate Module) et rsm: (Reusable Schema Module).

Montant de la ligne de facture (BT-131)

UBL 2.1 :

<cac:InvoiceLine>
  <cbc:LineExtensionAmount currencyID="EUR">250.00</cbc:LineExtensionAmount>
</cac:InvoiceLine>

CII :

<ram:IncludedSupplyChainTradeLineItem>
  <ram:SpecifiedLineTradeSettlement>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>250.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

Les codes de devise en CII sont des attributs d’éléments à certains endroits et absents à d’autres (avec la devise déclarée au niveau de l’en-tête). UBL est plus cohérent : currencyID apparaît sur chaque élément de montant monétaire.

Élément racine et espaces de noms

UBL 2.1 utilise trois espaces de noms :

<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">

CII utilise trois espaces de noms différents :

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">

Il n’y a aucun chevauchement entre les deux ensembles d’espaces de noms. Un parseur ciblant un format ne peut pas traiter l’autre.

Quel format est imposé où

Le choix est rarement le vôtre. Le format est déterminé par le pays cible, le canal de livraison et le cadre de conformité.

Format	Imposé par
UBL 2.1	Peppol BIS Billing 3.0 (transport réseau)
CII	Factur-X, ZUGFeRD, XRechnung (CII et UBL acceptés)
CII ou UBL	France (Portail Public de Facturation : les deux acceptés)

Peppol BIS Billing 3.0 est uniquement UBL. Si vous transmettez sur le réseau Peppol, vous devez produire de l’UBL.

Factur-X et ZUGFeRD sont en CII. La pièce jointe factur-x.xml dans un PDF/A-3 est toujours en CII.

XRechnung accepte CII et UBL, mais CII (CrossIndustryInvoice) est plus couramment testé par les validateurs des portails gouvernementaux allemands.

Conversion entre formats

Il n’existe pas de conversion automatique sans perte entre UBL et CII. Le contenu sémantique est identique, mais :

Certains champs se mappent sur des attributs dans un format et sur des éléments dans l’autre
La profondeur d’imbrication diffère, affectant la façon dont vous lisez les éléments séquentiels tels que les lignes de facture
Le placement du code de devise diffère entre les formats (certaines implémentations CII supposent que la devise de l’en-tête s’applique à toutes les lignes)
Les formats de date diffèrent : UBL utilise AAAA-MM-JJ, CII utilise AAAAMMJJ avec un attribut format="102"

La conversion est possible mais nécessite une couche de mappage dédiée. L’utilisation de XSLT est courante ; la communauté OpenPEPPOL fournit des mappages de référence.

Performance et outillage

UBL est plus largement pris en charge dans les bibliothèques .NET et Java. OASIS UBL existe depuis 2006 et la plupart des outils XML d’entreprise le prennent explicitement en charge.

CII est moins courant dans les outils pour développeurs européens en dehors de la France et de l’Allemagne. Des bibliothèques de parseurs existent mais tendent à être plus spécialisées.

Saxon HE gère la validation Schematron pour les deux. Les fichiers XSLT précompilés des versions GitHub de Peppol BIS incluent des fichiers XSLT séparés :

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

Exécutez chacun contre le format d’entrée approprié.

Lequel implémenter en premier

Pour la plupart des développeurs commençant une nouvelle intégration de facturation européenne en 2026, UBL est le meilleur point de départ :

Le transport réseau Peppol exige UBL
La plupart des pays de l’UE acceptent UBL sur les portails nationaux
L’outillage .NET et Java est plus mature
La spécification UBL est plus cohérente dans le placement des attributs

Si vous opérez spécifiquement en France ou en Allemagne, CII devient nécessaire pour Factur-X et ZUGFeRD. C’est une deuxième couche d’implémentation, pas un remplacement.

Pour l’archivage, PDF/A-3 avec CII embarqué est la norme. La plupart des pipelines qui transmettent du Peppol UBL sur le réseau génèrent également un PDF Factur-X CII pour l’archive de l’acheteur. Les deux remplissent des fonctions différentes et coexistent.

Une note sur la validation

Quelle que soit la syntaxe utilisée, validez par rapport aux règles Schematron du profil correct. Une facture UBL valide peut échouer aux règles Peppol BIS 3.0 si elle manque des éléments spécifiques à Peppol obligatoires. Une facture CII valide peut échouer au profil EN 16931 Factur-X si des champs facultatifs requis par ce profil sont absents.

Le problème plus profond est que la plupart des pipelines ont besoin des deux. Une livraison Peppol exige UBL. L’archive de l’acheteur exige un PDF Factur-X avec CII embarqué. Maintenir deux chemins de génération XML indépendants, deux passes de validation et deux ensembles de fichiers de règles Schematron double la surface pour les bogues de correction.

SealDoc génère les deux à partir de la même entrée. Un seul appel API avec vos données de facturation produit le document UBL pour la transmission Peppol et le PDF/A-3 avec CII embarqué pour l’archive de l’acheteur. La validation Schematron s’exécute sur les deux sorties avant qu’elles ne soient retournées. Vous n’avez pas besoin de maintenir l’un ou l’autre chemin de génération XML ni de suivre les versions de Peppol BIS.

Pour vérifier des fichiers existants, le validateur public SealDoc accepte UBL et CII et signale les échecs par numéro BT et code de règle métier. Utile pour diagnostiquer des documents reçus de partenaires commerciaux ou pour calibrer un export de factures tiers par rapport aux exigences EN16931.