SSolarc Labs

Formats structurés

Factur-X vs UBL vs CII : comparer les formats de facture électronique

Factur-X, UBL et CII sont trois familles de représentation rencontrées dans les projets de facturation électronique. Le bon choix ne se réduit pas à une préférence de développeur : il dépend du système source, du profil attendu, du contrat de la plateforme et des échanges avec les partenaires. Pour la recette, l’objectif est surtout de vérifier que chaque variante réellement produite respecte le format et le profil annoncés.

Revu le 2026-08-30Sources officielles DGFiP

01

Factur-X : PDF lisible + données structurées embarquées

Factur-X associe un document PDF à des données structurées embarquées. Cette combinaison facilite certains usages humains tout en permettant un traitement machine, mais elle impose de contrôler la cohérence de l’ensemble et la présence du véritable XML attendu. Un PDF ordinaire, même visuellement correct, ne devient pas une facture structurée simplement parce qu’il ressemble à un modèle Factur-X.

  • Contrôler que le XML structuré est réellement embarqué.
  • Identifier le profil Factur-X utilisé par le système source.
  • Tester les variantes de génération PDF et les données, pas uniquement l’affichage.

02

UBL et CII : XML natifs avec vocabulaires différents

UBL et CII sont des syntaxes XML structurées avec leurs propres namespaces, éléments et conventions. Deux fichiers peuvent exprimer une intention métier proche tout en ayant des chemins XML différents. Dans un projet multi-ERP, cette différence se répercute sur les mappings, les transformations et les tests. Le corpus doit donc conserver l’information du format et du profil pour pouvoir regrouper correctement les erreurs.

  • Ne pas appliquer un XPath UBL à un document CII par approximation.
  • Versionner les transformations entre modèle ERP et syntaxe cible.
  • Conserver le contexte de format dans les findings et la preuve de re-test.

03

Comment décider et tester sans fabriquer un faux classement

Il n’existe pas de « gagnant » universel entre ces formats. Le choix doit être compatible avec les scénarios applicables, la PA et les partenaires de l’entreprise. Pour la qualité, construisez des cas représentatifs pour chaque format réellement émis, puis exécutez les mêmes principes : validation structurale, règles applicables, contrôle des termes métier, clustering des erreurs et re-test après correction. La comparaison doit servir l’architecture, pas produire un score marketing arbitraire.

  • Documenter les formats supportés par source et par flux.
  • Tester les cas négatifs et les profils, pas seulement un exemple valide.
  • Éviter de convertir automatiquement un format sans preuve de conservation sémantique.

Étape suivante

Passer du guide à une vérification concrète.

InvoiceBatch FR reste un preflight technique de corpus : il ne remplace pas votre ERP ou votre Plateforme Agréée et ne constitue ni une certification ni une preuve de transmission.

Tester le parcours de préparation (EN)

Sources officielles

Ces sources cadrent les affirmations réglementaires de cette page. Les contrats et API d’une PA réelle doivent en plus être vérifiés auprès du fournisseur concerné.