La réforme de facturation électronique française reconnaît trois formats dans son socle technique : UBL 2.1, CII et Factur-X. Les trois implémentent la même norme sémantique EN16931 — les mêmes champs métier, les mêmes règles de validation, les mêmes Business Terms (BT). Pourtant, le choix du format a des conséquences directes sur votre pipeline technique.
Ce comparatif s’adresse aux développeurs qui doivent trancher : quel format intégrer dans leur stack, et pourquoi.
Pour le contexte complet de la réforme, voir Facturation électronique 2026 : le guide technique complet pour développeurs.
EN16931 : une norme, deux syntax bindings
EN16931 est une norme sémantique. Elle définit un modèle de données — les Business Terms (BT) et Business Groups (BG) — qui décrit ce qu’une facture doit contenir. Elle ne prescrit pas de format XML spécifique.
Le cadre EN16931, dans ses bindings CEN publiés (EN 16931-3-2 et EN 16931-3-3), s’appuie sur deux syntaxes de référence :
- UBL 2.1 (Universal Business Language), maintenu par OASIS
- UN/CEFACT CII D16B (Cross Industry Invoice), maintenu par UN/CEFACT
En parallèle, Factur-X 1.08 / ZUGFeRD 2.4 fait évoluer son XML hybride vers UN/CEFACT CII D22B, annoncé comme rétrocompatible avec D16B par la FNFE-MPE et le FeRD.
Factur-X n’est pas une troisième syntaxe au sens du CEN. C’est un conteneur hybride : un PDF/A-3 conforme à ISO 19005-3 dans lequel un fichier XML CII est embarqué. Le XML à l’intérieur d’un Factur-X est du CII.
EN16931 (modèle sémantique)
│
├── Syntax Binding CEN : UBL 2.1 (OASIS)
│
├── Syntax Binding CEN : CII D16B (UN/CEFACT)
│
└── Factur-X 1.08 = PDF/A-3 + XML CII D22B embarqué
(FNFE-MPE + FeRD)Anatomie comparée : CII vs UBL
Les deux formats sérialisent les mêmes Business Terms, mais dans des structures XML radicalement différentes.
Namespaces
| Format | Préfixes courants |
|---|---|
| CII | rsm:, ram:, qdt:, udt: |
| UBL 2.1 | cbc:, cac: |
Namespace URIs (seule l’URI a une valeur normative, les préfixes sont des conventions) :
CII → urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100
UBL 2.1 → urn:oasis:names:specification:ubl:schema:xsd:Invoice-2Structure XML
Le même champ métier — par exemple BT-1 (numéro de facture) — se trouve à des emplacements XPath très différents :
<!-- CII (Factur-X) -->
<rsm:CrossIndustryInvoice>
<rsm:ExchangedDocument>
<ram:ID>FX-2024-0001</ram:ID>
</rsm:ExchangedDocument>
</rsm:CrossIndustryInvoice>
<!-- UBL 2.1 -->
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
<cbc:ID>FX-2024-0001</cbc:ID>
</Invoice>Pour un champ plus imbriqué comme BT-30 (identifiant légal du vendeur — par exemple un numéro SIRET) :
<!-- CII -->
<ram:SellerTradeParty>
<ram:SpecifiedLegalOrganization>
<ram:ID schemeID="0002">12345678901234</ram:ID>
</ram:SpecifiedLegalOrganization>
</ram:SellerTradeParty>
<!-- UBL -->
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyLegalEntity>
<cbc:CompanyID schemeID="0002">12345678901234</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingSupplierParty>Les deux portent la même information sémantique (BT-30), mais le XPath, la profondeur d’imbrication et les noms d’éléments sont entièrement différents. Cela a un impact direct sur le code de mapping, les expressions Schematron, et les transformations XSLT.
À ne pas confondre : BT-30 = identifiant légal du vendeur (SIRET, numéro de registre), BT-31 = numéro de TVA intracommunautaire du vendeur.
Cardinalité et champs optionnels
EN16931 définit la cardinalité de chaque BT (obligatoire, optionnel, conditionnel). Les deux syntaxes respectent ces règles, mais une partie importante des contraintes métier n’est pas portée par le XSD seul. C’est le rôle de Schematron de vérifier les conditions métier — par exemple qu’un taux de TVA est renseigné lorsque la catégorie fiscale l’exige.
Factur-X : le conteneur hybride
Factur-X est un format co-développé par la FNFE-MPE (France) et le FeRD (Allemagne). Dans leurs versions harmonisées actuelles (Factur-X 1.08 / ZUGFeRD 2.4), ils sont techniquement identiques. Le format combine deux couches :
- Un PDF/A-3 lisible par un humain (la facture imprimable)
- Un XML CII embarqué comme pièce jointe (les données structurées)
Cette approche résout un problème pratique : les entreprises qui reçoivent une facture Factur-X peuvent la traiter comme un simple PDF (impression, archivage visuel) tout en extrayant les données structurées pour leur ERP.
Versions et compatibilité
| Version | XML embarqué | Statut |
|---|---|---|
| Factur-X 1.0 | CII D16B | Historique |
| Factur-X 1.07 | CII D16B | Largement déployé |
| Factur-X 1.08 / ZUGFeRD 2.4 | CII D22B (rétrocompatible D16B) | En vigueur (15 janvier 2026) |
Les bindings EN16931 publiés par le CEN (via le repository ConnectingEurope) restent centrés sur UBL 2.1 et CII D16B. Factur-X 1.08 / ZUGFeRD 2.4 introduit pour sa part des artefacts propres basés sur CII D22B, avec rétrocompatibilité annoncée par la FNFE-MPE et le FeRD.
Profils Factur-X
Factur-X introduit un concept absent d’UBL et CII bruts : les profils, qui définissent le niveau de détail du XML embarqué :
| Profil | Cas d’usage | Complexité XML |
|---|---|---|
| MINIMUM | Archivage PDF seul (quasi pas de données structurées) | Très faible |
| BASIC WL | Flux hybrides commande/facture | Faible |
| BASIC | Facturation B2C simplifiée | Moyenne |
| EN 16931 | Profil couvrant la totalité du noyau EN16931 | Élevée |
| EXTENDED | Supply chain enrichie (douanes, logistique, remises multiples) | Très élevée |
Les profils inférieurs (MINIMUM, BASIC WL) ne couvrent pas la totalité des BT EN16931. Si vous devez échanger une facture pleinement conforme au noyau EN16931 en Factur-X, le profil EN 16931 est le choix naturel.
Matrice de décision
Le choix du format dépend de votre contexte d’intégration. Le socle réglementaire français reconnaît les trois formats (UBL 2.1, CII et Factur-X) — aucun n’est imposé de manière exclusive.
| Contexte | Orientation | Pourquoi |
|---|---|---|
| B2B français (envoi via PDP) | Factur-X souvent privilégié | Le PDF reste exploitable par le destinataire sans outillage ; UBL et CII sont aussi acceptés par le socle |
| B2G Chorus Pro | UBL 2.1, CII ou Factur-X | Chorus Pro supporte les trois formats ; vérifier les spécifications de votre PDP pour le parcours exact |
| Réseau Peppol international | UBL 2.1 BIS 3.0 | La documentation Peppol BIS Billing 3.0 utilise UBL comme syntaxe de référence |
| Clients allemands / autrichiens | ZUGFeRD (= Factur-X 1.08) | Dans les versions harmonisées actuelles (FX 1.08 / ZUGFeRD 2.4), le format est techniquement identique |
| ERP avec module Factur-X intégré | Factur-X | Si votre ERP génère déjà du CII dans un PDF/A-3, rester sur le format natif évite une conversion supplémentaire |
| Architecture API pure (machine-to-machine) | CII ou UBL brut | Pas besoin de la couche PDF si le flux est exclusivement machine-to-machine |
Le cas de la double obligation
Certains émetteurs doivent envoyer des factures à la fois via Peppol (UBL) et via des PDP françaises (Factur-X). Dans ce cas, deux approches :
- Générer en CII et envelopper dans un PDF/A-3 pour Factur-X. Pour Peppol, convertir le CII en UBL. Le noyau sémantique EN16931 se correspond largement terme à terme, mais la conversion n’est pas un isomorphisme technique garanti sans perte dans tous les cas (arrondis, extensions CIUS, contexte réseau).
- Générer en UBL et le transmettre tel quel à Peppol. Pour les PDP françaises, envelopper le UBL dans un PDF/A-3 — mais ce n’est techniquement pas du Factur-X (qui exige du CII selon la spécification FNFE-MPE/FeRD). Le comportement effectif de chaque PDP vis-à-vis de cette configuration dépend de son implémentation.
L’approche 1 (CII natif + conversion UBL) est généralement plus sûre pour la conformité Factur-X.
Validation : mêmes règles, artefacts différents
Les trois formats sont validés contre les mêmes règles métier EN16931 (les BR-*). Les codes d’erreur sont identiques — un BR-CO-10 signifie la même chose qu’il soit détecté sur du CII ou de l’UBL. Mais les artefacts de validation (XSD et Schematron) sont distincts par syntaxe :
| Artefact | CII | UBL 2.1 |
|---|---|---|
| XSD | Schémas UN/CEFACT CII (D16B pour les artefacts CEN, D22B pour Factur-X 1.08) | UBL-Invoice-2.1.xsd (OASIS) |
| Schematron EN16931 | Artefacts CII publiés par ConnectingEurope | Artefacts UBL publiés par ConnectingEurope |
Les artefacts EN16931 de base sont publiés séparément pour UBL et CII dans le repository ConnectingEurope. Les CIUS nationales ou sectorielles (exigences françaises, XRechnung, Peppol BIS, etc.) viennent se superposer selon les cadres concernés — elles sont publiées par leurs propres organismes, pas dans le repository EN16931 générique.
Le Schematron contient les mêmes règles BR-* mais les expressions XPath ciblent les éléments de chaque syntaxe. Un même BR-CO-10 (somme des TaxSubtotals = TaxAmount) utilise un XPath rsm: en CII et cac: en UBL.
Pour Factur-X spécifiquement, la validation se fait en trois couches :
- PDF/A-3 (ISO 19005-3) — via VeraPDF
- XSD CII — validation structurelle du XML embarqué
- Schematron CII — règles métier EN16931
Pour un guide complet sur la validation Schematron, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*. Pour la couche PDF/A-3, voir PDF/A-3 pour Factur-X : checklist de conformité et pièges courants.
Conversion CII ↔ UBL : possibilités et limites
Les deux syntaxes implémentent le même modèle sémantique EN16931. La correspondance est largement terme à terme au niveau des Business Terms — mais la conversion ne se résume pas à un simple renommage d’éléments XML.
Ce qui se mappe directement :
- La majorité des Business Terms (BT) ont un correspondant direct dans les deux syntaxes
- Les code lists (ISO 4217 devises, ISO 3166 pays, UNTDID 1001 types de document) sont identiques
- Les règles BR-* s’appliquent de la même façon après conversion
Ce qui demande attention :
- Les arrondis TVA (décimales intermédiaires) peuvent diverger si la conversion ne respecte pas l’ordre de calcul
- Les extensions spécifiques (CIUS françaises, allemandes, Peppol BIS) utilisent des XPath différents et ne sont pas couvertes par un mapping standard
- Les identifiants de schéma (
schemeID) doivent être préservés tels quels (ex:0002pour SIRET) - Le profil Factur-X (MINIMUM, BASIC, etc.) n’a pas d’équivalent en UBL pur — cette métadonnée est perdue à la conversion
Des convertisseurs existent dans l’écosystème, mais il faut les qualifier soigneusement — en particulier dès qu’on touche à des CIUS nationales, des extensions réseau (Peppol BIS), ou des règles d’arrondi. Il n’existe pas de jeu unique “officiel CEN” de feuilles XSLT de conversion.
FAQ technique
Q : Factur-X est-il “meilleur” qu’UBL ?
Ce sont des choix d’architecture, pas un classement de qualité. Factur-X est souvent adapté aux flux B2B français où le destinataire n’a pas forcément d’outil d’extraction XML — le PDF reste lisible sans outillage. UBL est la syntaxe de référence pour les échanges Peppol internationaux. La qualité des données est identique : c’est la même norme EN16931.
Q : Mon ERP génère du Factur-X. Dois-je aussi supporter UBL ?
Seulement si vous émettez vers des destinations Peppol qui utilisent UBL. Vérifiez avec votre PDP — le comportement en matière de conversion dépend de chaque opérateur.
Q : Puis-je embarquer du UBL dans un PDF/A-3 au lieu du CII ?
Techniquement, un PDF/A-3 peut embarquer n’importe quel XML. Mais la spécification Factur-X (XP Z12-012) exige du CII. Un PDF/A-3 avec du UBL embarqué ne serait pas un Factur-X valide au sens de la norme FNFE-MPE/FeRD. Le comportement effectif de chaque PDP vis-à-vis de cette configuration est une question d’implémentation, pas de norme.
Q : Quelle syntaxe valider en priorité si je débute ?
Si vous ciblez des PDP françaises : Factur-X (CII) est un point de départ courant, mais UBL et CII sont aussi acceptés par le socle. Si vous avez des obligations Peppol BIS Billing 3.0 : UBL 2.1. Dans les deux cas, la validation EN16931 couvre les mêmes règles métier.
Ressources
- Facturation électronique 2026 : le guide technique complet — architecture, pipeline, calendrier
- Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — validation CII en détail
- PDF/A-3 pour Factur-X : checklist de conformité — la couche conteneur PDF