UN/CEFACT Cross Industry Invoice

Comment est structurée une facture CII, ce que recouvrent les versions D16B et D22B, pourquoi la version ne peut pas être lue dans un document, et où CII diffère réellement d’UBL.

Ce qu’est CII

La Cross Industry Invoice est la facture XML de l’UN/CEFACT. C’est l’une des deux syntaxes dans lesquelles EN 16931 peut être exprimée — l’autre étant UBL 2.1 — et c’est la syntaxe transportée dans Factur-X et utilisée dans toute la facturation électronique française.

Les noms d’éléments proviennent de la Core Component Technical Specification de l’UN/CEFACT, qui construit chaque nom à partir d’une classe d’objet, d’un terme de propriété et d’un terme de représentation. Le résultat est verbeux mais sans ambiguïté : SpecifiedTradeSettlementHeaderMonetarySummation ne peut désigner qu’une seule chose.

Espaces de noms

urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 — la racine du document, conventionnellement rsm.
urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100 — les structures métier, conventionnellement ram.
urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100 — les types de données tels que DateTimeString et Indicator, conventionnellement udt.
urn:un:unece:uncefact:data:standard:QualifiedDataType:100 — les types de données qualifiés, conventionnellement qdt.

Comme en UBL, les URI sont normatives et les préfixes ne le sont pas. Un outil qui recherche la chaîne littérale ram: échouera sur des documents conformes.

La question de la version

C’est le point qui pose le plus de difficultés en pratique, il mérite donc d’être énoncé clairement : la version UN/CEFACT d’un document CII ne peut pas être déterminée à partir du document lui-même.

D16B, D22B et les autres versions publient toutes la Cross Industry Invoice sous la même URI d’espace de noms, …:CrossIndustryInvoice:100. Il n’existe ni élément ni attribut de version. La version est une propriété du schéma face auquel le document a été construit : une information sur l’échange, non un contenu de l’instance.

La conséquence est importante pour la validation. Les artefacts de validation sont propres à une version : des règles publiées pour une version de CII ne s’appliquent pas automatiquement à une autre, et un validateur qui suppose une version produira sans hésiter des résultats affirmatifs et faux. Tout outil qui vous annonce « c’est du D22B » à partir du seul fichier fait une supposition. Ce site ne le fait pas, et le visualiseur CII le dit à l’endroit où vous attendriez la réponse.

Ce que vous pouvez lire dans un document, c’est ce que son émetteur déclare : l’identifiant de guide dans ram:GuidelineSpecifiedDocumentContextParameter/ram:ID, par exemple urn:cen.eu:en16931:2017 ou une URN de profil Factur-X. C’est une déclaration, pas un verdict.

Squelette du document

Une Cross Industry Invoice a trois enfants de premier niveau, dans cet ordre :

rsm:ExchangedDocumentContext — le processus métier (ram:BusinessProcessSpecifiedDocumentContextParameter) et le guide que le document déclare suivre (ram:GuidelineSpecifiedDocumentContextParameter).
rsm:ExchangedDocument — l’en-tête : ram:ID, ram:TypeCode, ram:IssueDateTime et les éventuels ram:IncludedNote.
rsm:SupplyChainTradeTransaction — tout le reste : les lignes, puis l’accord, la livraison et le règlement au niveau de l’en-tête.

À l’intérieur de la transaction :

ram:IncludedSupplyChainTradeLineItem — un par ligne. Chacun possède ses propres sections d’accord (prix), de livraison (quantité) et de règlement (taxe, total de ligne).
ram:ApplicableHeaderTradeAgreement — référence acheteur, parties vendeur et acheteur, références de commande et de contrat.
ram:ApplicableHeaderTradeDelivery — destinataire de la livraison et date de livraison effective.
ram:ApplicableHeaderTradeSettlement — devise, moyens de paiement, ventilation de TVA, remises et majorations, conditions de paiement et récapitulatif monétaire.

Notez l’ordre : les lignes viennent avant les parties, à l’inverse d’UBL.

Où CII diffère d’UBL

Les deux syntaxes expriment le même modèle sémantique, mais ce n’est pas le même document avec d’autres noms de balises. Les différences qui comptent lorsqu’on écrit une transposition :

Immatriculations fiscales. CII utilise ram:SpecifiedTaxRegistration/ram:ID avec un attribut schemeID : VA pour la TVA, FC pour un numéro fiscal local. UBL imbrique un élément cac:TaxScheme à la place.
Dates. CII écrit une chaîne accompagnée d’un qualifiant de format UN/EDIFACT 2379 : <udt:DateTimeString format="102">20260615</udt:DateTimeString> correspond au 15 juin 2026. UBL utilise directement des dates calendaires ISO.
Indicateur de remise ou de majoration. CII l’encapsule : ram:ChargeIndicator contient udt:Indicator. UBL dispose d’un booléen simple, cbc:ChargeIndicator.
Date d’échéance. CII n’a pas de date d’échéance au niveau de l’en-tête ; elle figure dans ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime.
Devise. En CII, la plupart des montants omettent currencyID et héritent de ram:InvoiceCurrencyCode. EN 16931 n’exige l’attribut que sur le total de taxe exprimé dans la devise comptable.
Prix brut. CII dispose d’un ram:GrossPriceProductTradePrice explicite, à côté de ram:NetPriceProductTradePrice. UBL exprime un prix brut indirectement, via une remise au niveau du prix.
IBAN. CII dispose d’un élément ram:IBANID dédié. UBL utilise un identifiant de compte générique dont l’interprétation dépend du moyen de paiement.

Une conversion qui traite ces écarts comme cosmétiques perdra ou inventera des données. Là où un champ signifie réellement la même chose dans les deux syntaxes, la correspondance est directe ; ailleurs, la différence doit être conservée.

Essayer

Ouvrez un document dans le visualiseur CII pour voir la structure résolue, avec le XML brut et le modèle analysé à côté. Pour le format PDF hybride construit sur CII, voyez Factur-X ; pour le modèle sémantique, voyez EN 16931.

Questions fréquentes

Comment savoir si un fichier CII est en D16B ou en D22B ?

À partir du seul fichier, c’est impossible. Toutes les versions publient la Cross Industry Invoice sous la même URI d’espace de noms, …:CrossIndustryInvoice:100. La version indique face à quel schéma le document a été construit : c’est une information sur l’échange, non un contenu de l’instance. En pratique, on l’apprend de la spécification que l’on met en œuvre — par exemple Factur-X 1.0.7 et versions ultérieures sont alignées sur D22B — ou en validant face à un schéma précis et en observant lequel accepte le document.

Pourquoi les noms d’éléments CII sont-ils aussi longs ?

Ils sont produits à partir de la Core Component Technical Specification de l’UN/CEFACT, où un nom est construit à partir d’une classe d’objet, d’un terme de propriété et d’un terme de représentation. SpecifiedTradeSettlementHeaderMonetarySummation est sans ambiguïté par construction. C’est verbeux à lire, mais cela signifie la même chose dans tous les types de documents UN/CEFACT.

Quelle est la différence entre rsm, ram, udt et qdt ?

Ce sont quatre espaces de noms. rsm porte la structure de la Cross Industry Invoice au niveau du document. ram porte les structures métier réutilisables : parties, lignes, taxe, totaux. udt porte les types de données non qualifiés comme DateTimeString et Indicator. qdt porte les types de données qualifiés, utilisés par exemple par FormattedIssueDateTime sur les documents référencés. Comme toujours, les URI sont normatives et les préfixes ne le sont pas.

Où se trouve la date d’échéance dans une facture CII ?

Il n’y a pas de date d’échéance au niveau de l’en-tête. Elle figure dans les conditions de paiement : ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime. C’est une véritable différence structurelle avec UBL, qui place cbc:DueDate directement sur le document.