Formats UBL et CII : choisir et contrôler les échanges

Le choix entre UBL et CII dépend des données que votre logiciel sait produire et des échanges que votre plateforme sait assurer. La question décisive est le couple format-profil, puis la conservation du sens lors des conversions. Un XML bien formé peut encore contenir une facture incohérente ou incomplète.

Pour décider, préparez un dossier comprenant un fichier représentatif, les règles appliquées et les résultats attendus dans le logiciel destinataire. Ce dossier doit montrer comment les informations deviennent utilisables pour la facturation, les contrôles et la comptabilité.

Distinguer syntaxe, profil et circuit de transmission

UBL et CII désignent des structures d’échange XML. Le profil précise les données et règles à appliquer pour un usage déterminé. Deux fichiers portant le nom « UBL » ne sont donc pas nécessairement interchangeables sans examen du profil, des versions et des règles supplémentaires.

Un fichier produit par le logiciel de vente peut être transformé avant sa transmission. Décrivez donc les étapes : génération, contrôle, conversion éventuelle, échange entre plateformes et restitution au client. Le résultat visible dans l’ERP du fournisseur ne suffit pas à connaître celui qui sera reçu.

Le guide Factur-X explique le cas du document mixte PDF/XML, dont la partie structurée utilise CII. Cette présentation peut faciliter la lecture humaine, mais elle ne dispense pas de vérifier le contenu structuré ni sa cohérence avec ce qui est affiché.

Ce que prévoit le socle réglementaire français

L’Art. 41 septies C de l’annexe IV du CGI vise UBL et CII avec les profils EN16931 ou EXTENDED-CTC-FR, ainsi que le format mixte associant PDF/A-3 et CII dans les conditions qu’il précise. Les profils admis doivent être examinés précisément ; tout PDF contenant un XML ne répond pas automatiquement au socle.

Les plateformes doivent pouvoir recevoir les formats mentionnés et transmettre selon au moins l’un des formats et profils prévus. Elles peuvent proposer d’autres formats à leurs clients. Ces obligations d’interopérabilité ne signifient pas que chaque logiciel client génère spontanément toutes les variantes.

Le même article renvoie aux spécifications XP Z12-014 pour les cas d’usage mis en œuvre et XP Z12-013 pour les API standardisées que les plateformes souhaitent implémenter. Il faut donc distinguer les formats de facture, le comportement attendu pour une opération et l’interface utilisée pour l’échange.

La page de référence de la DGFiP permet de retrouver les documents correspondants, notamment XP Z12-012 pour les formats et profils des messages. Demandez au prestataire la référence précise de la version qu’il applique. Une réponse limitée à « compatible avec la réforme » ne permet pas de comprendre les règles utilisées.

Choisir à partir des fichiers réellement disponibles

Commencez par demander un export représentatif au logiciel de vente, avec une documentation de ses champs. Identifiez ce qu’il produit directement et ce qu’un intermédiaire devra compléter ou convertir. Faites la même démarche auprès de la comptabilité achats : quelles données sont importées sans ressaisie et lesquelles restent seulement consultables ?

Un système qui génère déjà du CII peut conserver cette syntaxe si le profil et les données répondent aux besoins. Un échange demandant de l’UBL appelle une vérification de ses règles propres. La préférence d’un service informatique ne doit pas masquer les conséquences pour le traitement comptable quotidien.

Comparez les options sur un périmètre constant : mêmes opérations, mêmes informations attendues et mêmes corrections. Faites préciser les coûts de développement, de conversion, de traitement des exceptions et de maintenance des versions. Aucun avantage de prix ou de performance ne peut être déduit du seul nom du format.

Inscrivez ces réponses dans le dossier de choix de plateforme. Demandez aussi ce qui se passera si un partenaire transmet un format différent de votre format habituel : réception, conversion, restitution et accès au document d’origine doivent être expliqués.

Préserver le sens lors des conversions

Construisez une table de correspondance comportant, pour chaque information utile, sa source, sa destination et la règle de transformation. Incluez les identifiants, numéro, dates, lignes, unités, taxes, remises, références et modalités de paiement pertinentes.

Ne vérifiez pas seulement que « le montant existe ». Distinguez prix unitaire, total de ligne, total hors taxe, taxe, montant déjà payé et reste à payer. Une valeur numériquement exacte peut produire un résultat faux si elle est importée dans un champ ayant un autre sens.

L’Art. 41 septies C prévoit expressément les conversions qui ne garantissent pas strictement l’intégrité des données : une représentation lisible contenant l’ensemble des données reçues avant conversion doit alors accompagner la transmission ou être mise à disposition du client, selon l’étape concernée. Cette règle ne promet pas l’identité de tous les champs structurés après transformation.

Votre recette doit donc séparer deux résultats : l’information est-elle encore accessible, et est-elle utilisable automatiquement dans le logiciel d’arrivée ? Une référence de commande visible dans le document lisible peut permettre un contrôle humain tout en empêchant le rapprochement automatique attendu.

Préparer des contrôles à plusieurs niveaux

La première vérification porte sur la structure du fichier : peut-il être lu et correspond-il au schéma attendu ? La suivante porte sur les règles de données et de cohérence. Enfin, il faut vérifier l’effet de l’import dans le système destinataire. Un résultat positif à une étape ne dispense pas des autres.

Le FNFE-MPE publie des composants de validation, dont des schématrons pour les profils et règles françaises. Ces outils appliquent des règles définies ; leur utilisation ne constitue pas une appréciation générale de la réalité économique de la facture. Demandez les versions utilisées et conservez le rapport obtenu.

L’Art. 41 septies F prévoit notamment des contrôles de présence des données, d’identification des parties, de cohérence des montants de TVA et d’unicité du numéro. Le contrôle réglementaire doit être distingué d’une vérification commerciale : une facture peut satisfaire une série de règles techniques tout en portant sur une prestation contestée.

Pour chaque échec, exigez un message exploitable : règle concernée, champ en cause, valeur reçue et correction attendue. Évitez les corrections destinées uniquement à faire disparaître un message, telles qu’une référence inventée ou un taux choisi sans qualification fiscale.

Constituer un jeu de scénarios représentatifs

Utilisez des données fictives cohérentes dans l’environnement convenu avec le prestataire. Sélectionnez les situations rencontrées dans votre activité : plusieurs taux, remises, acompte, avoir, autoliquidation ou opération mixte, selon le cas. Les scénarios proposés ici ne sont pas les résultats d’essais déjà réalisés.

Précisez les hypothèses fiscales de chaque scénario. Une recette ne doit pas donner pour acquis le traitement d’une opération encore discutée. La validation technique peut identifier un champ correctement transmis sans résoudre la question du fondement fiscal qui justifie sa valeur.

Faites examiner également les documents reçus. La réussite de l’émission ne démontre pas que les factures fournisseurs seront importées avec leurs références et pièces jointes. Conservez les fichiers, les rapports et les observations nécessaires pour reproduire une anomalie.

Relier les fichiers aux statuts et aux corrections

La facture fait partie d’un échange qui continue après son dépôt. Le cycle de vie de la facture doit permettre de retrouver les retours et les actions effectuées. L’Art. 41 septies G distingue notamment dépôt, rejet, refus et encaissée, avec des acteurs différents pour leur mise à jour.

Ne remplacez pas tous ces états par « envoyé » dans le tableau de suivi. Un rejet lié au format appelle l’examen du fichier ou des contrôles ; un refus du destinataire demande de comprendre sa raison. La correction doit rester rattachée à la pièce initiale et à l’historique utile.

Lorsqu’un envoi est interrompu, recherchez son état avant une nouvelle tentative. Demandez comment l’intégration reconnaît une facture déjà traitée et comment elle évite une seconde comptabilisation. Le choix entre UBL et CII ne règle pas, à lui seul, cette question de reprise.

Prévoir les évolutions et la conservation

Le dossier de référence doit conserver les versions des formats, profils et composants utilisées pour chaque campagne de vérification. Lors d’une mise à jour, identifiez ce qui change et les scénarios à rejouer. Une modification de règle peut affecter un cas particulier sans imposer de revoir indistinctement tout le système.

Anticipez aussi les données structurées supplémentaires prévues à partir de septembre 2027 par l’Art. 41 septies D(II), selon son champ. La disponibilité d’une information dans une zone lisible ne garantit pas qu’elle soit déjà produite dans le champ structuré attendu. Rapprochez ce besoin des données sources et de la feuille de route de l’éditeur.

Enfin, organisez la conservation des factures : fichiers, représentation lisible, pièces utiles et liens entre corrections doivent rester retrouvables selon les obligations applicables. Vérifiez l’export avant une migration. Une facture consultable aujourd’hui dans un portail peut devenir difficile à exploiter si vous ne récupérez qu’une partie des éléments.

Formaliser la décision de format

La décision finale doit nommer la syntaxe, le profil, les versions et les conversions retenues. Ajoutez le périmètre des scénarios examinés, les limites connues et les responsabilités de correction. Indiquez ce qui reste manuel et qui en supporte la charge.

Cette fiche permet d’accepter une solution pour un besoin déterminé, avec des réserves explicites. Elle évite de transformer le succès d’une seule facture simple en preuve de couverture de toute l’activité.

Ce qu’il faut retenir

• Choisissez un couple syntaxe-profil adapté aux données et aux échanges.
• Vérifiez séparément structure, règles de données et résultat de l’import.
• Identifiez les informations qui restent lisibles mais ne sont plus structurées après conversion.
• Reliez les fichiers aux statuts, aux corrections et à la conservation.

Questions fréquentes

UBL est-il plus conforme que CII ?

Le socle prévoit les deux syntaxes avec des profils déterminés. La conformité dépend aussi des données, des règles appliquées et du circuit de transmission.

Faut-il utiliser le même format que son client ?

Pas nécessairement. Les plateformes assurent l’interopérabilité prévue, mais les conversions et la restitution doivent être vérifiées pour votre usage.

Un XML valide peut-il encore être rejeté ?

Oui. Sa structure ne prouve pas que ses montants, identifiants et autres données satisfont tous les contrôles applicables. Examinez la règle précise en échec.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.