Factur-X, UBL ou CII : quel format votre logiciel doit-il produire ?

Trois formats sont acceptés par la réforme française. Ils ne s'adressent pas aux mêmes usages, et le choix a des conséquences très concrètes sur ce que votre logiciel doit savoir générer.

Les trois formats, en une phrase chacun

UBL

Un format XML international très répandu, structuré et lisible par machine. Pas de représentation visuelle : c'est de la donnée pure.

CII

L'autre format XML retenu, issu des travaux des Nations unies sur les échanges commerciaux. Même principe qu'UBL : données structurées, pas d'affichage.

Factur-X

Un format mixte : un PDF lisible par un humain, dans lequel est intégré un fichier XML lisible par une machine. Un seul fichier pour les deux usages.

Pourquoi Factur-X est généralement le bon choix pour un éditeur

La différence n'est pas technique, elle est humaine. Avec un XML seul, votre client ne peut plus ouvrir sa facture pour la relire : il voit des balises. Avec Factur-X, il ouvre un PDF normal — et la machine, elle, lit le XML intégré.

Pour un logiciel métier dont les utilisateurs consultent, impriment ou transfèrent leurs factures, cette propriété tranche la question. Vous continuez à produire le PDF que vos clients connaissent ; ce PDF devient simplement porteur des données structurées.

Un point qui surprend souvent : Factur-X n'est pas « un PDF avec un XML à côté ». Le XML est incorporé dans le PDF, selon une norme d'archivage précise. Un PDF et un XML envoyés séparément ne constituent pas une facture Factur-X.

Le piège : un XML valide n'est pas une facture conforme

C'est l'erreur la plus coûteuse en temps, et nous l'avons faite nous-mêmes avant de la documenter. Produire un XML bien formé, qui s'ouvre sans erreur, ne garantit rien : la norme européenne applicable comporte des dizaines de règles de validation portant sur la cohérence des données, et pas seulement sur leur présence.

Quelques exemples de ce qui fait échouer une facture techniquement « valide » :

Conséquence pratique pour un éditeur : ne produisez pas ces fichiers à la main. Utilisez une bibliothèque qui implémente la norme et la maintient à jour. Écrire le XML soi-même revient à réimplémenter des dizaines de règles et à les suivre dans le temps — pour un résultat qui, au mieux, égale l'existant.

Ce que votre logiciel doit savoir fournir

Indépendamment du format retenu, les données requises sont les mêmes. Si votre logiciel facture déjà correctement, vous les possédez presque toutes :

DonnéePrécision utile
Identification de l'émetteurNuméro d'identification de l'entreprise et, selon les cas, numéro de TVA.
Identification du destinataireMême exigence. C'est elle qui permet de router la facture — une erreur ici bloque la transmission.
Numéro et date de factureLe numéro doit être unique et séquentiel, comme sur papier.
Lignes de factureDésignation, quantité, unité, prix unitaire, montant de la ligne.
Montants et TVATotaux hors taxes, taxes par taux, total TTC — cohérents entre eux au centime près.
Dates de livraison ou d'exécutionRequises par certains profils ; souvent oubliées parce qu'absentes des factures papier.

Et le choix du format, qui le fait ?

En pratique, il dépend de ce que la plateforme agréée de votre client accepte et de ce que son destinataire sait lire. Les plateformes acceptent généralement les trois formats : le choix vous revient donc, et Factur-X reste le plus confortable côté utilisateur.

Si vos clients facturent de grandes entreprises ou des administrations ayant des exigences propres, vérifiez leurs attendus avant de figer votre génération.

Relaiflow transmet ce que votre logiciel produit, dans le format que vous choisissez — nous ne modifions jamais le contenu d'une facture. Voir ce que fait exactement le composant · Diagnostic en 5 questions

À lire ensuite

Cette page est un guide d'orientation destiné aux éditeurs de logiciels. Elle ne remplace ni la documentation de votre plateforme agréée, ni la norme elle-même, ni un avis professionnel.