XSD UN/CEFACT CII D16B explique simplement
Le schema XML qui structure chaque facture Factur-X depuis 2017.
Derriere chaque facture Factur-X se trouve un fichier XML. Et derriere ce fichier XML se trouve un schema qui dit ce qu'il a le droit de contenir : le XSD UN/CEFACT Cross Industry Invoice, version D16B. Cet article explique ce qu'est ce schema, pourquoi cette version précise a ete retenue, et comment il s'articule avec la norme semantique EN 16931 et le profil Factur-X.
Un XSD, c'est quoi ?
Un XSD (XML Schema Définition) est un fichier qui decrit la grammaire d'un document XML. Il enumere les balises autorisees, leur ordre, leur type de donnees (date, montant, chaine de caractères) et leur cardinalite (obligatoire, optionnelle, repetable).
Pour une facture électronique, le XSD joue un rôle d'arbitre : si un fichier XML respecte le schema, on peut affirmer qu'il est syntaxiquement conforme. Cela ne dit pas que la facture est juste sur le fond (un total faux passera) mais cela garantit qu'un logiciel tiers saura la lire sans deviner la structure. La validation XSD est la première etape de tout pipeline serieux, avant les règles metier et les règles Schematron.
UN/CEFACT et la naissance de CII
Le sigle UN/CEFACT designe le United Nations Centre for Trade Facilitation and Electronic Business, organe des Nations Unies qui publie depuis les annees 1980 des standards d'echange commercial (EDIFACT, puis XML). Le travail sur la facture cross-industrie a debute au debut des annees 2000 pour aboutir au modèle CII (Cross Industry Invoice), pense pour couvrir n'importe quel secteur d'activite, sans dépendre d'un EDI national particulier.
UN/CEFACT publie regulierement des releases de ses bibliothèques de schemas, identifiees par une lettre et deux chiffres : D11A, D13B, D16B, D22B, etc. La lettre D signifie Draft Published (etat stabilise mais sans version officielle définitive), suivi de l'annee et d'un identifiant de cycle (A pour le premier semestre, B pour le second). D16Bcorrespond donc au cycle de fin 2016, publie en decembre 2016.
Pourquoi D16B et pas une version plus récente ?
La question revient souvent : UN/CEFACT a publie depuis D17B, D20B, D22B, etc. Pourquoi Factur-X et EN 16931 restent-ils geles sur D16B ? Trois raisons.
| Raison | Explication |
|---|---|
| Stabilite | EN 16931 a ete adoptee en 2017 sur la base de D16B. Changer de version casserait la compatibilité ascendante de millions de factures déjà émises en Europe. |
| Mapping CEN | Le CEN/TC 434 a produit un mapping ligne a ligne entre les 165 termes business d'EN 16931 et les balises CII D16B. Refaire ce mapping pour chaque release UN/CEFACT serait couteux et risque. |
| Interoperabilite | Les operateurs allemands (ZUGFeRD), français (Factur-X) et le réseau Peppol BIS Billing 3.0 consomment tous le même XSD D16B. Le moindre ecart ferait diverger l'ecosysteme. |
Concretement, lorsque vous generez ou validez une facture Factur-X en 2026, c'est bien le schema de decembre 2016 qui sert de référence, et cela ne devrait pas changer avant une revision majeure d'EN 16931.
Les namespaces : ram, rsm, udt, qdt
Quand vous ouvrez un fichier factur-x.xml, vous croisez systematiquement quatre prefixes XML. Ils correspondent aux quatre namespaces composant le modèle CII D16B.
rsm:— Reusable Schemas Module. C'est le namespace racine (CrossIndustryInvoice), qui contient l'enveloppe du document.ram:— Reusable Aggregate business information entity Module. C'est le namespace le plus visible : il regroupe quasiment toutes les entites metier (ApplicableHeaderTradeAgreement,SellerTradeParty,SpecifiedTradeSettlementHeaderMonetarySummation, etc.).udt:— Unqualified Data Types. Les types de donnees primitifs non qualifies : montant, identifiant, date au format brut.qdt:— Qualified Data Types. Les types de donnees qualifies avec un format ou une liste de codes précise (par exemple un format date102pour AAAAMMJJ).
Un extrait minimal donne une idee de l'imbrication :
rsm:CrossIndustryInvoice— racine du documentrsm:ExchangedDocumentContext— identifie le profil Factur-X utilisérsm:ExchangedDocument— numéro, date et type de facturersm:SupplyChainTradeTransaction— contient toute la facture proprement dite
A l'intérieur de SupplyChainTradeTransaction, on trouve les trois blocsram:ApplicableHeaderTradeAgreement, ram:ApplicableHeaderTradeDelivery etram:ApplicableHeaderTradeSettlement qui portent respectivement l'accord commercial, la livraison et le règlement.
Pourquoi EN 16931 et Factur-X reposent dessus
La norme européenne EN 16931 est avant tout un modèle semantique : elle decrit 165 termes business (BT-1, BT-2, etc.) regroupes en business groups (BG-1, BG-2, etc.) sans imposer de syntaxe. Pour rendre ce modèle exploitable techniquement, le CEN a publie deux syntaxes de liaison autorisees :
- UN/CEFACT CII D16B — la syntaxe XML détaillée dans cet article.
- OASIS UBL 2.1 — une syntaxe XML alternative, dominante au Royaume-Uni et dans le réseau Peppol BIS Billing 3.0.
Côté français, l'association FNFE-MPE a choisi la syntaxe CII pour construire Factur-X, en y ajoutant la spécificité du PDF/A-3 contenant le XML en piece jointe. Chaque profil Factur-X (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) réutilise donc le même XSD D16B et active simplement un sous-ensemble différent de balises. Pour comprendre comment ces profils empilent les contraintes sur le même schema, voir notre article sur les différences entre profils Factur-X.
Le profil MINIMUM se limite a 18 champs — le strict necessaire pour une comptabilite analytique : voir les 18 champs du profil MINIMUM. Le profil EN 16931 (souvent appele COMFORT) couvre integralement le modèle semantique européen. EXTENDED ajoute des champs hors EN 16931, utiles pour certains secteurs.
ZUGFeRD, Factur-X et le même XSD
Côté allemand, l'equivalent direct de Factur-X s'appelle ZUGFeRD. Depuis la version 2.1, ZUGFeRD et Factur-X partagent strictement le même XSD D16B et les mêmes profils. Un fichier valide côté français est valide côté allemand, et vice versa. C'est le point détaillé dans ZUGFeRD vs Factur-X. La specification commune actuelle est Factur-X 1.0.08 / ZUGFeRD 2.3.3.
Le XSD bundle dans nos outils
Notre validateur embarque les fichiers XSD officiels CII D16B distribues par UN/CEFACT, ainsi que les surcharges Factur-X publiees par FNFE-MPE. Lorsqu'une facture est soumise, le validateur execute trois etapes successives :
- Validation XSD : vérification que le XML respecte la grammaire D16B. Un attribut manquant, un ordre incorrect ou un type errone déclenché une erreur a ce stade.
- Validation Schematron : application des règles metier EN 16931 (codes BR-*) qui ne peuvent pas s'exprimer en XSD pur. Exemple : si une TVA est présente, le code pays du vendeur doit être défini.
- Règles Factur-X : contrôles propres au profil déclaré dans
GuidelineSpecifiedDocumentContextParameter(presence de la piece jointe XML, format PDF/A-3, etc.).
Les XSD de référence sont disponibles publiquement sur le site UN/CEFACT (annexe XML Schemas, cycle D16B) et sur le site FNFE-MPE pour les fichiers spécifiques Factur-X. Aucun login n'est requis pour les telecharger.
Ce qu'il faut retenir
- Le XSD CII D16B est la grammaire XML publiee par UN/CEFACT en decembre 2016, qui sert de socle technique a Factur-X et a la syntaxe CII d'EN 16931.
- Cette version est gelee par stabilite : tout l'ecosysteme européen (France, Allemagne, Peppol) s'appuie dessus.
- Les quatre namespaces (
rsm,ram,udt,qdt) structurent l'ensemble du modèle. - La validation XSD n'est qu'une etape : elle doit être combinee a Schematron et aux règles Factur-X pour conclure qu'une facture est conforme.
Pour aller plus loin : Qu'est-ce que Factur-X présente le format dans son ensemble, et la specification Factur-X 1.0.08détaillé les règles ajoutees par-dessus le schema D16B.