Qu’est-ce que le format CII (Cross Industry Invoice) ? Guide complet

Depuis le 1er septembre 2026, toutes les entreprises françaises assujetties à la TVA doivent être en mesure de recevoir des factures électroniques structurées. Le format CII (Cross Industry Invoice) fait partie des trois formats officiellement acceptés, avec l’UBL et le Factur-X, pour circuler sur les Plateformes Agréées (PDP). Pourtant, de nombreux dirigeants de PME et collaborateurs de cabinet ne savent pas précisément ce que contient un fichier CII, en quoi il se distingue d’un fichier UBL, ni comment l’intégrer concrètement dans leurs systèmes.

Cette complexité technique est réelle, mais identifiable : elle concerne principalement la structure du schéma XSD, les règles Schematron EN 16931 et les règles françaises spécifiques BR-FR-CTC. Cet article vous donne tout ce qu’il faut savoir sur le Cross Industry Invoice : définition, différences avec l’UBL, obligations réglementaires françaises, validation et plan d’action concret pour aborder les échéances sans improviser.

Un standard mondial né dans les couloirs de l’ONU

Le Cross Industry Invoice est un standard de facture électronique en XML publié par l’UN/CEFACT, la Commission des Nations Unies pour la facilitation des procédures commerciales et les transactions électroniques. Son objectif est de permettre l’échange de factures structurées entre entreprises de secteurs différents, sur des types de marchandises variés. L’UN/CEFACT le qualifie de modèle de données à couverture maximale (« maximum data-set invoice ») : une architecture conçue pour couvrir un spectre très large de cas d’usage commerciaux à l’échelle internationale.

Pour formaliser ce standard, l’UN/CEFACT publie trois documents de référence, disponibles gratuitement sur son site et constituant la base technique de toute implémentation conforme. Ces livrables comprennent la Spécification des Exigences Métier (Business Requirement Specification, BRS), qui décrit les exigences opérationnelles du format ; la Correspondance des Spécifications d’Exigences (Requirements Specification Mapping, RSM), qui inventorie le modèle de données et les correspondances entre besoins métier et éléments techniques ; et enfin le schéma XML lui-même, dont la version D16B est celle officiellement citée dans les guides de référence.

CII et UBL : deux syntaxes XML pour un même socle sémantique

UBL et CII transportent les mêmes données obligatoires définies par la norme européenne EN 16931 : numéro de facture, montants, TVA, identifiants des parties contractantes. La différence ne porte pas sur ce qu’il faut transmettre, mais sur la façon dont ces données sont organisées dans l’arbre XML. Un fichier UBL s’ouvre avec la balise racine , tandis qu’un fichier CII commence par . Les espaces de noms divergent également : UBL utilise les préfixes cbc: et cac:, là où le CII emploie rsm:, ram: et udt:.

Ces différences de préfixes reflètent deux philosophies de modélisation distinctes. En CII, rsm désigne le module racine du document, ram porte l’ensemble des blocs métier réutilisables (parties, lignes, montants), et udt gère les types de données simples tels que les dates et les identifiants. En UBL, cbc regroupe les composants élémentaires simples et cac contient les structures complexes agrégées. Ces deux logiques ne sont pas interchangeables : un traitement automatique prévu pour l’un ne fonctionnera pas sur l’autre sans un mappage de conversion précis, ce qui soulève un enjeu réel d’interopérabilité de la facturation électronique entre systèmes hétérogènes.

Un exemple concret illustre bien cette divergence sur le champ « date de facture ». UBL utilise le format ISO YYYY-MM-DD dans un élément IssueDate relativement plat. Le CII encode la même date en YYYYMMDD avec un attribut format= »102″ imbriqué dans une structure DateTimeString. Pour les lignes de facture, UBL les place sous cac:InvoiceLine, tandis que le CII les niche sous ram:IncludedSupplyChainTradeLineItem au sein d’un bloc SupplyChainTradeTransaction. Cette profondeur d’imbrication reflète les origines du format dans la modélisation des transactions commerciales multi-sectorielles de l’UN/CEFACT, à l’opposé de la structure plus plate et orientée document d’UBL.

La réforme française de facturation électronique et le rôle concret du CII

La réforme française s’applique en deux temps selon la taille de l’entreprise. Dès le 1er septembre 2026, toutes les entreprises assujetties à la TVA et établies en France doivent pouvoir recevoir des factures électroniques structurées. À cette même date, les grandes entreprises et les ETI ont également l’obligation d’émettre ces factures. Les PME, TPE et micro-entreprises bénéficient d’un délai supplémentaire : leur obligation d’émission prend effet au 1er septembre 2027. En parallèle, les entreprises concernées doivent transmettre à l’administration fiscale des données de transaction et de paiement via le mécanisme d’e-reporting.

Le CII n’est pas le seul format autorisé, mais il est l’un des trois officiellement acceptés pour les échanges via une Plateforme Agréée (PDP) ou le Portail Public de Facturation (source : DGFiP / impots.gouv.fr). Les factures B2B domestiques ne peuvent plus transiter par simple courriel : elles doivent emprunter ce canal certifié, dans l’un des formats structurés reconnus. Le choix entre CII, UBL et Factur-X dépend souvent des outils déjà en place chez l’émetteur et le récepteur, d’où l’importance de s’assurer que votre Plateforme Agréée prend en charge les trois sans vous contraindre à un format unique.

MyUnisoft, dont la candidature au statut de Plateforme Agréée est en cours d’instruction auprès de l’administration fiscale française, intègre la prise en charge des trois formats directement dans son interface. Les cabinets comptables et leurs clients TPE/PME n’ont ainsi pas à configurer de schémas XML à la main ni à recourir à un connecteur technique supplémentaire pour préparer leur conformité à l’échéance réglementaire.

Valider un fichier CII : schémas, règles métier et sources officielles

La validation d’un fichier CII ne se résume pas à vérifier qu’il « ressemble » à du XML correct. Elle se déroule en deux couches successives, toutes deux obligatoires avant toute transmission sur une PDP.

Validation XSD

La première couche contrôle la conformité structurelle du fichier par rapport au schéma officiel. Elle vérifie que chaque élément est présent, bien nommé et correctement imbriqué selon la définition publiée par l’UN/CEFACT. Un fichier qui échoue à cette étape est structurellement invalide et ne peut pas progresser vers l’étape suivante.

Validation Schematron

UBL et CII transportent les mêmes données obligatoires définies par la norme européenne EN 16931 : numéro de facture, montants, TVA, identifiants des parties contractantes. La différence ne porte pas sur ce qu’il faut transmettre, mais sur la façon dont ces données sont organisées dans l’arbre XML.
Un fichier UBL s’ouvre avec la balise racine Invoice, tandis qu’un fichier CII commence par CrossIndustryInvoice. Les espaces de noms divergent également : UBL utilise les préfixes cbc: et cac:, là où le CII emploie rsm:, ram: et udt:.

Ces différences de préfixes reflètent deux philosophies de modélisation distinctes. En CII, rsm désigne le module racine du document, ram porte l’ensemble des blocs métier réutilisable (parties, lignes, montants), et udt gère les types de données simples tels que les dates et les identifiants. En UBL, cbc regroupe les composants élémentaires simples et cac contient les structures complexes agrégées. Ces deux logiques ne sont pas interchangeables : un traitement automatique prévu pour l’un ne fonctionnera pas sur l’autre sans un mappage de conversion précis, ce qui soulève un enjeu réel d’interopérabilité de la facturation électronique entre systèmes hétérogènes.

Un exemple concret illustre bien cette divergence sur le champ « date de facture ». UBL utilise le format ISO YYYY-MM-DD dans un élément IssueDate relativement plat. Le CII encode la même date en YYYYMMDD avec un attribut format="102" imbriqué dans une structure DateTimeString.
Pour les lignes de facture, UBL les place sous cac:InvoiceLine, tandis que le CII les niche sous ram:IncludedSupplyChainTradeLineItem au sein d’un bloc SupplyChainTradeTransaction. Cette profondeur d’imbrication reflète les origines du format dans la modélisation des transactions commerciales multi-sectorielles de l’UN/CEFACT, à l’opposé de la structure plus plate et orientée document d’UBL.

Plan d’action concret pour passer au CII sans improviser

La conformité au format CII ne s’improvise pas à la dernière minute, mais elle n’est pas non plus inaccessible avec une démarche structurée. Voici les étapes à suivre dans l’ordre, que vous soyez cabinet comptable ou dirigeant de PME.

Étapes de mise en conformité

1. Identifier votre calendrier précisen fonction de la taille de votre entreprise et de votre statut au regard de la TVA, pour savoir si votre obligation d’émission commence en septembre 2026 ou en septembre 2027.
2. Choisir une Plateforme Agréée qui prend en charge le CII, l’UBL et le Factur-X, afin de ne pas être contraint par un format unique selon votre interlocuteur commercial. Consultez laliste officielle des PDPpubliée par la DGFiP pour comparer les solutions disponibles.
3. Auditer votre logiciel de facturation actuel pour savoir s’il génère déjà du CII conforme ou si un module complémentaire, un connecteur ou une migration vers une solution compatible est nécessaire.
4. Tester vos flux en amont de l’échéance, en validant des fichiers CII réels contre les schémas XSD et les Schematrons publiés par le FNFE-MPE, avec un point d’attention particulier sur les règles BR-FR-CTC.
5. Former vos équipes à lire et interpréter les messages d’erreur de validation pour corriger rapidement les rejets dès les premiers échanges en production.

Pour les cabinets comptables qui gèrent des dizaines de dossiers clients PME, traiter le CII via des connecteurs externes est une source permanente de friction et d’erreurs. Une solution qui intègre directement la génération, la validation et la transmission de factures au format CII absorbe cette complexité technique et réduit considérablement le risque de non-conformité pour l’ensemble du portefeuille clients.

C’est le positionnement de MyUnisoft : la plateforme prend en charge le CII directement dans son interface, aussi bien pour les cabinets que pour leurs clients TPE/PME, sans configuration XML à la main ni intermédiaire supplémentaire. Elle s’appuie sur les besoins concrets remontés par les cabinets partenaires, pas sur des spécifications abstraites.

Ce qu’il faut retenir avant septembre

Le Cross Industry Invoice est bien plus qu’un acronyme technique réservé aux développeurs : c’est l’un des formats structurés au cœur de la réforme française de facturation électronique, et sa maîtrise devient un enjeu opérationnel concret pour tout cabinet et toute PME assujettie à la TVA. Comprendre sa structure XML, ses différences avec l’UBL, les règles BR-FR-CTC qui s’y appliquent et les outils pour le valider permet d’aborder les échéances réglementaires avec une longueur d’avance.

La bonne nouvelle : vous n’avez pas à gérer ces spécifications seul. Des Plateformes Agréées comme MyUnisoft ont précisément été conçues pour que la conformité aux formats structurés soit transparente pour vous et vos clients, et pour que vous puissiez vous concentrer sur votre activité plutôt que sur des schémas XSD. Pour voir comment MyUnisoft gère concrètement les flux CII pour un cabinet comme le vôtre, demandez une démonstration directement depuis le site.