Factur-X : le format hybride expliqué

Ce qu'est Factur-X et pourquoi on parle de format hybride

Factur-X est un standard franco-allemand de facture électronique développé conjointement par le FNFE-MPE en France et le FeRD en Allemagne. Son équivalent allemand s'appelle ZUGFeRD : les deux formats sont techniquement identiques, seul le nom change selon le pays d'émission.

Le terme hybride désigne une propriété précise : un fichier Factur-X contient simultanément deux représentations complètes de la même facture. La première est un document PDF qu'un être humain peut ouvrir, lire et imprimer avec n'importe quel lecteur standard. La seconde est un fichier XML structuré, embarqué à l'intérieur du PDF, que les logiciels de comptabilité, les ERP et les plateformes agréées lisent et traitent automatiquement.

Ces deux couches ne se résument pas à une copie l'une de l'autre. Elles coexistent dans le même conteneur, chacune servant un usage distinct. Le PDF assure la continuité des habitudes de travail : un dirigeant, un comptable ou un client peut vérifier la facture visuellement sans aucun outil spécialisé. Le XML, lui, alimente directement les systèmes d'information sans ressaisie, sans OCR et sans risque d'erreur de transcription.

C'est précisément cette double capacité qui a conduit à retenir Factur-X comme l'un des trois formats du socle minimal de la réforme française, aux côtés de l'UBL et du CII pur. Il répond à deux contraintes simultanées que les formats XML purs ne peuvent pas résoudre seuls : être traitable par une machine et rester lisible par un humain sans logiciel métier.

Comment un fichier Factur-X est construit

Un fichier Factur-X repose sur une architecture en trois éléments indissociables. Si l'un manque ou est mal formé, les plateformes agréées rejettent le document avant même d'en lire les données.

Le premier élément est le conteneur PDF/A-3. Il s'agit d'une variante archivable du format PDF, définie par la norme ISO 19005-3. Par rapport aux versions antérieures du format PDF/A, la version 3 autorise l'intégration de pièces jointes de tout type à l'intérieur du document. C'est cette capacité qui rend possible l'architecture hybride : le fichier XML est attaché à l'intérieur du PDF, non pas à côté de lui. Un PDF classique ne peut pas jouer ce rôle, même s'il est renommé ou signé électroniquement.

Le deuxième élément est le fichier XML embarqué, obligatoirement nommé factur-x.xml. Ce fichier suit la syntaxe CII (Cross Industry Invoice) de l'UN/CEFACT. Il organise les données de la facture en une hiérarchie précise : en-tête avec le numéro, la date et le type de document ; parties avec les identités complètes du vendeur et de l'acheteur, leurs numéros de TVA et leurs SIREN ; lignes de facturation avec les quantités, prix unitaires et taux de TVA ; totaux récapitulatifs ; conditions de paiement. La sémantique de ces données est définie par la norme européenne EN 16931, publiée par le Comité Européen de Normalisation.

Le troisième élément est un bloc de métadonnées XMP intégré au PDF. Ces métadonnées déclarent le profil de conformité du fichier via un champ spécifique. Une incohérence entre ce champ et le profil réellement déclaré dans le XML est détectée par les validateurs et entraîne un rejet. Les trois éléments doivent donc être cohérents entre eux : conteneur PDF/A-3 valide, XML correctement nommé et structuré, métadonnées XMP alignées sur le profil du XML.

La règle de cohérence entre les deux couches est asymétrique : toutes les données présentes dans le XML doivent figurer dans le PDF visible, mais le PDF peut afficher des informations supplémentaires (logo, conditions générales, commentaires) absentes du XML, à condition qu'il ne s'agisse pas de mentions obligatoires soumises à contrôle. En cas de divergence sur les montants ou les données fiscales, c'est le XML qui fait foi pour le traitement automatique.

Pourquoi ce format a été retenu pour la réforme française

La réforme française de la facturation électronique impose, à partir du 1er septembre 2026, que toutes les entreprises assujetties à la TVA soient en capacité de recevoir des factures électroniques via une plateforme agréée. L'obligation d'émettre suit un calendrier progressif : les grandes entreprises et les ETI basculent au 1er septembre 2026, les PME, TPE et micro-entreprises selon un calendrier fixé par décret à partir de 2027.

Factur-X a été retenu dans le socle minimal pour plusieurs raisons concrètes. La première est sa capacité à accompagner la transition sans rupture brutale. Une entreprise qui reçoit un fichier Factur-X peut l'ouvrir comme un PDF ordinaire si son logiciel n'est pas encore configuré pour lire le XML, puis automatiser progressivement le traitement à mesure que ses outils évoluent. Cette souplesse est particulièrement précieuse pour les TPE et PME qui n'ont pas encore finalisé leur raccordement à une plateforme agréée.

La deuxième raison est l'interopérabilité franco-allemande. Factur-X et ZUGFeRD étant techniquement identiques, une entreprise qui facture des clients en France et en Allemagne utilise le même format pour les deux marchés, sans conversion supplémentaire.

La troisième raison est l'adoption déjà large du format. Factur-X est implémenté par plus de 130 plateformes agréées et par un grand nombre de logiciels de facturation et de gestion financière, ce qui réduit les risques de rejets liés à des incompatibilités techniques entre émetteurs et récepteurs.

Il est important de noter que Factur-X n'est pas obligatoire en tant que tel. La réforme impose une facture électronique structurée transmise par plateforme agréée. Factur-X est l'un des trois formats possibles du socle, aux côtés de l'UBL et du CII pur. Les plateformes agréées sont tenues de savoir convertir les trois formats, ce qui signifie qu'un émetteur en Factur-X peut tout à fait alimenter un destinataire qui reçoit en UBL, et inversement.

Les différences entre Factur-X, UBL et CII

Les trois formats du socle minimal transportent la même sémantique définie par la norme EN 16931. Ils ne se distinguent ni par la richesse des données qu'ils peuvent contenir, ni par leur validité réglementaire. La différence porte sur la nature du fichier, la lisibilité humaine et les écosystèmes dans lesquels ils s'inscrivent.

Le critère déterminant pour choisir entre ces trois formats est souvent la lisibilité humaine. Un destinataire qui ne dispose pas encore d'un logiciel compatible peut ouvrir un fichier Factur-X et le lire comme n'importe quelle facture PDF. Un fichier UBL ou CII pur, lui, ne s'affiche pas dans un lecteur standard : sans outil de visualisation, il apparaît comme une suite de balises XML illisibles. C'est ce seul critère qui explique la prédominance de Factur-X chez les petites structures pendant la période de transition.

Pour les entreprises qui traitent des volumes importants avec des systèmes entièrement automatisés, UBL ou CII pur peuvent être préférables : le fichier est plus léger, le traitement est entièrement machine, et aucune couche PDF ne vient alourdir les échanges. Les plateformes agréées assurant la conversion entre les trois formats, le choix du format d'émission n'impose aucune contrainte au destinataire.

Les profils de Factur-X et ce que chacun implique

Factur-X définit cinq profils qui déterminent la richesse des données présentes dans le XML embarqué. Les profils sont cumulatifs : chaque niveau inclut les champs du niveau inférieur et en ajoute. Choisir un profil, c'est choisir le niveau de détail que le destinataire pourra extraire automatiquement de la facture.

Le profil MINIMUM contient uniquement les données d'identification de la facture : numéro, date, identités du vendeur et de l'acheteur, montants totaux. Aucune ligne de détail n'est structurée dans le XML. Le destinataire doit lire le PDF pour comprendre le contenu de la facture. Ce profil est insuffisant pour les échanges B2B dans le cadre de la réforme.

Le profil BASIC WL (Without Lines) ajoute les informations d'en-tête et de pied de facture, ainsi que la ventilation TVA agrégée et les conditions de paiement, mais toujours sans lignes de détail. Il est toléré à titre transitoire au démarrage de la réforme, mais n'a pas vocation à constituer une cible de production durable.

Le profil BASIC est le premier à inclure des lignes de facture dans le XML : nom de l'article, quantité, prix unitaire, montant net, catégorie de TVA par ligne. Bien qu'il soit techniquement un sous-ensemble d'EN 16931, il n'est pas retenu comme profil déclarable dans la réforme française : une facture BASIC conforme doit se déclarer en profil EN 16931.

Le profil EN 16931 couvre l'intégralité du noyau sémantique européen, soit l'ensemble des champs obligatoires et conditionnels définis par la norme. Il inclut les remises et charges au niveau du document, les références de commande, les périodes de facturation et la ventilation TVA complète. C'est le profil recommandé pour la grande majorité des échanges B2B.

Le profil EXTENDED, et sa variante française EXTENDED-CTC-FR, étend EN 16931 avec des données logistiques, douanières et sectorielles. Il est pertinent pour les entreprises dont les factures impliquent des structures complexes : multi-commandes, multi-livraisons, incoterms, sous-lignes pour des kits ou des articles composites.

Ce qui distingue une facture Factur-X d'un simple PDF envoyé par e-mail

La confusion entre un PDF classique et un fichier Factur-X est la plus répandue et la plus coûteuse. Un PDF ordinaire, même signé électroniquement, même accompagné d'une piste d'audit fiable, n'est pas une facture Factur-X. Les deux fichiers peuvent se ressembler visuellement à l'ouverture, mais leur nature technique est fondamentalement différente.

Un PDF classique est un document de présentation. Il contient des éléments graphiques, du texte mis en forme, éventuellement une signature numérique. Aucun logiciel ne peut en extraire automatiquement les données de facturation sans recourir à l'OCR (reconnaissance optique de caractères) ou à une saisie manuelle. L'OCR introduit des risques d'erreur, notamment sur les montants, les numéros de TVA et les références. Un PDF scanné cumule ces risques.

Un fichier Factur-X est un conteneur PDF/A-3 qui embarque un fichier XML structuré. Les données sont disponibles directement, dans un format que les logiciels lisent sans interprétation visuelle. Un logiciel de comptabilité peut importer la facture, vérifier les totaux, rapprocher les lignes avec les bons de commande et l'enregistrer au grand livre sans aucune intervention humaine.

À partir du 1er septembre 2026, un PDF envoyé par e-mail n'est plus un mode d'émission conforme pour les transactions B2B entre entreprises françaises assujetties à la TVA. La facture doit être transmise via une plateforme agréée, dans l'un des trois formats du socle (Factur-X, UBL ou CII). L'e-mail direct ne vaut plus émission conforme pour ces transactions, même si le fichier joint est un Factur-X techniquement valide.

Trois différences résument l'écart entre un PDF classique et un Factur-X :

• Le PDF classique est lisible par l'humain uniquement ; le Factur-X est lisible par l'humain et par la machine.
• Le PDF classique ne peut pas être traité automatiquement sans OCR ; le Factur-X s'intègre directement dans les systèmes d'information.
• Le PDF classique envoyé par e-mail ne sera plus conforme pour le B2B domestique à partir de septembre 2026 ; le Factur-X transmis par plateforme agréée l'est.

Comment on produit et comment on lit une facture Factur-X en pratique

Produire un fichier Factur-X valide n'est pas une opération manuelle. Assembler un PDF/A-3 conforme, générer un XML CII correctement structuré, vérifier la cohérence des métadonnées XMP et s'assurer que les totaux passent les règles Schematron : aucune de ces étapes n'est réalisable à la main dans un contexte de production. Le logiciel de facturation ou de gestion prend en charge l'intégralité de cette chaîne.

Pour une TPE ou un indépendant, la démarche se résume à deux vérifications : le logiciel émet-il un profil accepté (EN 16931 ou EXTENDED), et est-il raccordé à une plateforme agréée avant l'échéance applicable ? Le reste relève de l'éditeur. Pour un responsable comptable, le périmètre s'élargit : tester les exports, les avoirs, les factures d'acompte, la remontée des statuts de cycle de vie et les conditions d'archivage. Pour une DSI ou un intégrateur, le chantier est un mapping complet entre le modèle de données interne et les champs CII du profil cible, avec validation systématique avant mise en production.

La validation d'un fichier Factur-X opère en quatre étapes indépendantes. La première vérifie la conformité du conteneur PDF/A-3. La deuxième contrôle la validité du XML face à son schéma XSD : structure, types de données, cardinalités. La troisième applique les règles Schematron EN 16931, soit plus de 200 règles métier portant sur la cohérence arithmétique des totaux, les conditions selon la catégorie de TVA et la validité des codes utilisés. La quatrième applique les règles françaises additionnelles. Un fichier peut passer les deux premières étapes et échouer à la troisième : c'est là que se concentre la majorité des rejets en production.

Du côté du destinataire, exploiter un Factur-X reçu suppose d'extraire le fichier factur-x.xml embarqué dans le PDF, puis d'en analyser le contenu pour alimenter le système comptable. Les plateformes agréées effectuent cette extraction automatiquement. Un logiciel de comptabilité raccordé à une plateforme reçoit les données structurées directement, sans que l'utilisateur n'ait à ouvrir le PDF.

Les erreurs fréquentes à éviter

Plusieurs erreurs reviennent systématiquement chez les entreprises qui se préparent à la réforme. Les connaître à l'avance évite des rejets coûteux et des délais de paiement inutiles.

La première erreur, et la plus répandue, est de croire qu'un PDF signé ou scanné suffit. Un PDF signé électroniquement reste un PDF : il ne contient pas de XML structuré, il n'est pas un conteneur PDF/A-3, et il ne sera pas accepté comme facture électronique conforme par une plateforme agréée. Un PDF scanné est encore moins conforme : il s'agit d'une image, sans aucune donnée structurée exploitable. La signature ou le scan n'ajoutent pas la couche XML qui fait le Factur-X.

La deuxième erreur est de choisir un profil trop bas. Un logiciel qui émet en profil MINIMUM ou BASIC WL produit des fichiers techniquement valides en tant que Factur-X, mais insuffisants pour les échanges B2B dans le cadre de la réforme. Le destinataire ne peut pas intégrer automatiquement la facture dans son logiciel à partir du seul XML, faute de lignes de détail. Viser le profil EN 16931 dès le départ évite une migration ultérieure.

La troisième erreur est de confondre la validité technique et l'acceptation par une plateforme agréée. Un fichier peut passer la validation XSD et échouer au Schematron. Il peut passer EN 16931 et être refusé par les règles françaises additionnelles. La validation doit couvrir les quatre niveaux, pas seulement la structure du fichier.

La quatrième erreur est de négliger la qualité des données sources. Un fichier Factur-X est aussi bon que les données qui l'alimentent. Un SIREN erroné, une adresse de livraison absente, un code de devise mal formaté ou un total HT incohérent avec la somme des lignes entraînent un rejet immédiat. La conformité du fichier commence dans le référentiel client et article du logiciel de gestion, pas dans le générateur de XML.

La cinquième erreur est de croire que l'obligation ne concerne que l'émission. La réception est obligatoire pour toutes les entreprises assujetties à la TVA dès le 1er septembre 2026, quelle que soit leur taille. Ne pas être raccordé à une plateforme agréée à cette date expose à des sanctions, même si l'entreprise n'est pas encore tenue d'émettre.

Produire du Factur-X depuis votre gestion

Le format Factur-X est produit à partir des données de facturation existantes dans votre logiciel de gestion. Ce n'est pas un document que l'on crée séparément : c'est une export structuré de ce que votre outil contient déjà. La qualité du fichier généré dépend donc directement de la qualité de vos données internes.

Le référentiel client est le premier point de contrôle. Un SIREN absent ou erroné, une adresse de facturation incomplète, un numéro de TVA intracommunautaire mal renseigné : chacun de ces manques se traduit par un rejet à la validation ou au moment de la transmission à la plateforme agréée. Le même raisonnement s'applique au référentiel article : un code unité non conforme aux listes de codes officielles, un taux de TVA incohérent avec la catégorie déclarée, une désignation vide entraînent des erreurs Schematron que le générateur de fichier ne peut pas corriger seul.

Djaboo est une solution de gestion compatible avec le format Factur-X, intégrée avec la plateforme agréée Super PDP. Les données de facturation saisies dans Djaboo alimentent directement la génération du fichier structuré, sans ressaisie ni étape manuelle supplémentaire. La chaîne entre la création de la facture dans l'interface et la transmission à la plateforme agréée est continue.