L’ouverture d’un fichier Factur-X dans un lecteur PDF révèle une facture parfaitement banale : logo, lignes, totaux, mentions légales. La singularité tient à ce qui ne se voit pas. À l’intérieur du PDF/A-3, un fichier XML structuré nommé factur-x.xml contient les mêmes données dans un format que les logiciels comptables digèrent sans ressaisie.
Standard franco-allemand publié en 2017 par le FNFE-MPE et le FeRD, Factur-X est techniquement identique à ZUGFeRD 2.4 outre-Rhin. Il appartient au socle minimum des trois formats et normes de la facture électronique reconnus par la DGFiP, aux côtés d’UBL et de CII. Sa popularité tient à un compromis qui parle aux PME : un seul fichier, deux lectures.
La dernière version, Factur-X 1.08 / ZUGFeRD 2.4, est entrée en vigueur le 15 janvier 2026, calée sur les ajustements de la norme européenne EN 16931 et sur les besoins de la réforme française. À quelques mois de l’obligation d’émission pour les grandes entreprises, le format n’a plus rien d’expérimental.
Un standard franco-allemand devenu pivot français
Le succès de Factur-X en France ne tient pas au hasard. Le format a été conçu dès le départ pour combler le fossé entre les habitudes des PME, fortement ancrées sur le PDF, et les exigences de structuration imposées par Bruxelles. Avant d’entrer dans la mécanique technique, il faut comprendre d’où vient ce standard.
Une initiative FNFE-MPE et FeRD née en 2017
Le format est publié pour la première fois le 16 octobre 2017, conjointement par le Forum National de la Facture Électronique (FNFE-MPE) et son homologue allemand, le Forum elektronische Rechnung Deutschland (FeRD). Les deux organismes cherchent alors à proposer une implémentation concrète de la norme sémantique européenne EN 16931, publiée la même année. L’idée fondatrice : produire un format qui satisfasse à la fois l’œil humain et les logiciels d’automatisation, sans imposer de rupture brutale aux entreprises habituées au PDF.
L’équivalent allemand porte le nom de ZUGFeRD, acronyme du Zentraler User Guide des Forums elektronische Rechnung Deutschland. À partir de la version 2.1 de ZUGFeRD et de la 1.0 de Factur-X, les deux standards sont techniquement identiques : même conteneur PDF/A-3, même fichier XML CII, mêmes profils. Aujourd’hui, parler de Factur-X 1.08 ou de ZUGFeRD 2.4 désigne strictement la même chose.
Pourquoi Factur-X est devenu le choix par défaut des PME françaises
Trois raisons expliquent l’adoption massive du format en France. Première raison, la continuité : un fichier Factur-X reste un PDF, lisible avec n’importe quel lecteur, imprimable, archivable comme avant. Aucune équipe n’a besoin de réapprendre à manipuler une facture. Deuxième raison, la conformité automatique : le XML embarqué suit la norme EN 16931 et toutes les Plateformes Agréées savent le traiter sans conversion intermédiaire.
Troisième raison, la double lecture : un destinataire dont le logiciel ne sait pas encore extraire le XML peut continuer à lire le PDF, le temps de mettre son système à niveau. À l’inverse, UBL et CII sont des fichiers XML purs : sans logiciel compatible côté réception, ils restent illisibles. Pour une PME qui découvre la facture électronique, ce différentiel de lisibilité a tranché.
Comment fonctionne le format hybride : architecture PDF/A-3 et XML CII
Le terme « hybride » cache une architecture précise, codée par les normes ISO et par le standard européen. Comprendre cette architecture aide à éviter les erreurs courantes qui font rejeter une facture à l’entrée des plateformes : un mauvais conteneur, un XML mal nommé, des métadonnées XMP absentes ou incohérentes.
Le rôle du conteneur PDF/A-3
PDF/A-3 (norme ISO 19005-3) est une variante du PDF spécialement conçue pour l’archivage à long terme. Trois caractéristiques le distinguent d’un PDF ordinaire. D’abord, il garantit que le document restera lisible dans dix ou vingt ans, sans dépendance à des polices ou ressources externes. Ensuite, il interdit tout contenu dynamique : pas de JavaScript, pas de vidéo, pas d’éléments interactifs susceptibles d’évoluer.
Enfin, et c’est sa singularité, il autorise l’incorporation de fichiers annexes de tout type, là où PDF/A-1 et PDF/A-2 l’interdisaient. Cette dernière propriété est ce qui rend Factur-X possible. Le fichier XML structuré n’est pas accolé à la facture par e-mail ni rangé à part dans un dossier : il est embarqué à l’intérieur du PDF, en tant que pièce jointe conforme.
Le fichier factur-x.xml et la syntaxe Cross Industry Invoice
Le fichier embarqué porte un nom strictement codé par le standard : factur-x.xml. Aucune autre dénomination n’est acceptée par les validateurs officiels. Sa syntaxe suit la norme UN/CEFACT Cross Industry Invoice, un schéma XML international conçu pour les échanges commerciaux multisectoriels. Depuis la version 1.08, le standard s’appuie sur la révision D22B du schéma CII, en restant rétrocompatible avec D16B.
Le fichier décrit la facture en plus de 165 champs sémantiques : identité du vendeur et de l’acheteur, dates, références de commande, lignes de produits, montants HT et TTC, codes de TVA, conditions de paiement. Chaque champ porte un identifiant standardisé (BT pour les éléments unitaires, BG pour les groupes), ce qui rend les données universellement interprétables, qu’elles soient produites en France ou en Allemagne. Le format CII existe aussi en version autonome, sans PDF, et constitue alors un format à part entière du socle minimum.
Les métadonnées XMP qui valident l’ensemble
L’ultime brique technique tient dans les métadonnées XMP du PDF. Quatre entrées spécifiques, codées dans le namespace fx: (anciennement zf: avant ZUGFeRD 2.1), déclarent au validateur la nature du document : type (toujours INVOICE), nom du fichier XML attaché, version du standard, et profil de conformité (fx:ConformanceLevel).
Cette dernière entrée est critique. Elle doit correspondre exactement au GuidelineID déclaré à l’intérieur du XML. Une incohérence, par exemple un XMP qui annonce EN 16931 alors que le XML déclare BASIC, provoque le rejet immédiat par les contrôleurs Schematron utilisés par les Plateformes Agréées. La rigueur n’est pas optionnelle.
Un PDF généré par Word, Excel ou un éditeur graphique reste une simple image numérique, même s’il a l’apparence d’une facture. Sans XML embarqué nommé factur-x.xml, sans conteneur PDF/A-3 valide et sans métadonnées XMP fx: conformes, le fichier sera rejeté par les Plateformes Agréées comme non structuré.
Cinq profils de données, du MINIMUM à EXTENDED
Tous les fichiers Factur-X n’embarquent pas le même volume de données structurées. Le standard prévoit cinq profils, organisés par richesse croissante, qui dictent ce que le XML contient et ce que le destinataire pourra automatiser à la réception.
Ce que chaque profil ajoute en termes de champs structurés
Le profil MINIMUM se contente des données de niveau document : identité des parties, montants totaux, TVA. Aucune ligne de facture détaillée. Conçu à l’origine pour Chorus Pro, il a vocation à disparaître dans le cadre de la réforme française. Le profil BASIC WL (Without Lines) ajoute les remises et charges au niveau du document, mais conserve l’absence de lignes structurées. Il est toléré au démarrage de la réforme, puis disparaîtra lui aussi.
Le profil BASIC intègre enfin les lignes de facture, ce qui le rend conforme à EN 16931. Le profil EN 16931 (anciennement nommé COMFORT) déclare l’intégralité des champs obligatoires et conditionnels de la norme européenne, et constitue la cible recommandée pour la plupart des entreprises. Le profil EXTENDED, enfin, ajoute des champs métier au-delà de la norme : remises multi-niveaux, références de transport, incoterms, données douanières.
La version Factur-X 1.08 / ZUGFeRD 2.4 du 15 janvier 2026 introduit la gestion de sous-lignes, indispensable pour facturer des kits, des bundles ou des articles composites. Cette évolution répond directement aux besoins identifiés par l’administration fiscale française et par le Bundesfinanzministerium allemand dans leurs travaux préparatoires de fin 2025.
Le profil français EXTENDED-CTC-FR
La réforme française a engendré une variante spécifique : le profil EXTENDED-CTC-FR, défini par le FNFE-MPE en accompagnement de l’administration fiscale. Il s’agit techniquement d’un sous-ensemble du profil EXTENDED, enrichi de champs additionnels qui adressent des cas d’usage français mal couverts par la norme européenne : auto-facturation, mandats de représentation fiscale, signalement de factures hors champ TVA.
Le profil introduit aussi quelques tolérances métier, notamment une marge d’un centime par ligne dans les contrôles de cohérence des totaux, pour absorber les écarts d’arrondi systémiques. Sa contrepartie allemande s’appelle XRECHNUNG, conçue pour le secteur public outre-Rhin avec ses propres extensions. Les deux variantes coexistent sans interférence.
Quel profil retenir selon votre activité
Pour la grande majorité des PME assujetties à la TVA, le profil EN 16931 constitue le bon compromis. Il garantit la conformité à la norme européenne, l’interopérabilité totale avec les destinataires français comme étrangers, et l’automatisation maximale côté réception. Une facture créée en BASIC peut d’ailleurs se déclarer en EN 16931 sans modification, à condition qu’elle remplisse les exigences du profil supérieur.
Le profil EXTENDED, ou sa variante française EXTENDED-CTC-FR, n’a d’intérêt que pour les entreprises avec des flux logistiques complexes, des opérations multi-devises ou des contraintes douanières spécifiques. Quant aux profils MINIMUM et BASIC WL, ils n’ont plus qu’un statut transitoire et ne tiendront pas la durée de la réforme. Pour entrer dans le détail des champs obligatoires et des cardinalités spécifiques à chaque profil, le guide dédié sur les profils Factur-X de MINIMUM à EXTENDED détaille la cartographie complète.
Pour une PME française qui passe à la facture électronique en 2026 ou 2027, le profil EN 16931 est le réflexe sûr. EXTENDED ou EXTENDED-CTC-FR ne se justifient qu’en présence de besoins métier explicites (logistique, douane, multi-devises). MINIMUM et BASIC WL sont à considérer comme des solutions de transition courte, à abandonner dès que possible.
Place de Factur-X dans le socle minimum face à UBL et CII
La réforme française n’impose pas Factur-X. Elle reconnaît trois formats équivalents qu’on appelle le socle minimum : Factur-X, UBL et CII. Toute Plateforme Agréée doit savoir produire et traiter les trois, et convertir de l’un à l’autre quand l’expéditeur et le destinataire ne s’accordent pas sur le format d’échange.
Trois formats reconnus, une seule norme sémantique
Les trois formats du socle minimum partagent un socle technique unique : la norme européenne EN 16931. Cette norme définit le modèle sémantique des données : quels champs sont obligatoires, quels codes utiliser pour la TVA, quelles règles de calcul s’appliquent aux totaux. Elle ne dicte pas la syntaxe de mise en œuvre, ce qui explique l’existence de plusieurs implémentations.
UBL est un format XML structuré standardisé par OASIS et largement adopté en Europe, particulièrement dans les pays nordiques et au sein du réseau Peppol. CII, porté par l’UN/CEFACT, vise plutôt les échanges intersectoriels internationaux. Factur-X enferme du CII dans un PDF/A-3, ce qui en fait une déclinaison hybride. Du point de vue des données transportées, les trois formats sont strictement équivalents : seule l’enveloppe diffère.
| Format | Type | Lisibilité humaine | Cas d’usage type |
|---|---|---|---|
| Factur-X | Hybride PDF/A-3 + XML CII | Oui (PDF natif) | TPE, PME, transition depuis le PDF |
| UBL | XML pur (OASIS) | Non (sans logiciel) | ERP internationaux, réseau Peppol |
| CII | XML pur (UN/CEFACT) | Non (sans logiciel) | EDI industriel, grands comptes |
Quand préférer un XML pur
Pour les TPE et PME françaises, Factur-X reste le choix par défaut, mais certains contextes appellent un XML pur. Premier cas : les ERP industriels et internationaux travaillent souvent nativement en UBL, en partie pour leur intégration dans le réseau Peppol qui sert de standard d’échange transfrontalier en Europe du Nord. Émettre directement en UBL évite une conversion par la plateforme.
Deuxième cas : les flux EDI massifs, typiques de l’automobile ou de la grande distribution, utilisent historiquement CII pour son alignement avec les pratiques UN/CEFACT. Y intégrer un PDF/A-3 alourdit inutilement le payload sans valeur ajoutée. Hors de ces situations, le surcoût d’un XML pur en termes de lisibilité ne se justifie pas pour la plupart des entreprises françaises.
Implémentation pratique et points d’attention techniques
Concrètement, aucune entreprise n’a à coder son propre générateur Factur-X. La production passe par un logiciel certifié ou par la PA elle-même. Mais quelques pièges techniques expliquent la majorité des rejets et méritent d’être anticipés, en particulier autour de la cohérence entre PDF visible et XML embarqué.
Génération via une Plateforme Agréée ou un logiciel certifié
Trois voies coexistent pour produire une facture Factur-X conforme. La plus courante consiste à utiliser un logiciel de facturation qui intègre nativement la génération du format : Pennylane, Tiime, Sellsy, Indy, EBP, Cegid, parmi d’autres. L’utilisateur saisit sa facture comme avant, et le logiciel produit silencieusement le PDF/A-3 avec son XML embarqué.
La deuxième voie passe par une Plateforme Agréée qui propose la conversion en entrée : l’entreprise envoie un PDF classique et la plateforme le transforme. La fiabilité dépend alors de la qualité de l’OCR. La troisième voie, réservée aux développeurs, s’appuie sur des bibliothèques open source : factur-x en Python, Mustang en Java, ZUGFeRD-csharp en .NET. Pour convertir un PDF existant en facture électronique, la première étape consiste donc à choisir laquelle de ces voies correspond à votre maturité technique.
Les pièges qui font rejeter une facture Factur-X
Quatre erreurs reviennent dans les rejets observés sur les plateformes. La première : l’incohérence entre le profil déclaré dans l’XMP (fx:ConformanceLevel) et le profil annoncé dans le GuidelineID du XML. Les validateurs Schematron sont stricts, un seul écart provoque le rejet. La deuxième : un nom de fichier XML qui n’est pas exactement factur-x.xml reste invisible aux extracteurs.
La troisième erreur tient au PDF source qui n’est pas réellement PDF/A-3 : un PDF classique généré sans intégration des polices ou avec du JavaScript embarqué ne passe pas la validation veraPDF, même si l’œil humain ne voit aucune différence. La quatrième, plus subtile, concerne la désynchronisation entre les données affichées dans le PDF et celles encodées dans le XML. La norme AFNOR XP Z12-012 définit les règles de cohérence formelle entre les deux représentations, et les PA appliquent ces règles à l’entrée.
Avant émission, deux outils gratuits permettent de tester la conformité d’un fichier Factur-X. veraPDF valide la conformité PDF/A-3 du conteneur. Mustang, soutenu par la communauté FeRD, vérifie le XML contre les schémas XSD et les règles Schematron de la norme EN 16931. La plupart des Plateformes Agréées proposent aussi un validateur en interface web.
Atouts de Factur-X : double lecture humaine et machine dans un fichier unique, conformité native à EN 16931, interopérabilité avec ZUGFeRD allemand, transition douce depuis le PDF traditionnel.
Points de vigilance : exigence stricte de conformité PDF/A-3, cohérence indispensable entre métadonnées XMP et XML embarqué, choix du profil aligné sur le besoin réel (EN 16931 dans la plupart des cas).
Questions fréquentes
Une simple facture PDF peut-elle être considérée comme une Factur-X ?
Non. Un PDF généré par un logiciel de bureautique standard est une simple représentation visuelle, sans données structurées exploitables. Pour qu’un fichier soit reconnu comme Factur-X, il doit respecter trois conditions cumulatives : être au format PDF/A-3, embarquer un fichier XML nommé factur-x.xml conforme à la norme EN 16931, et déclarer dans ses métadonnées XMP les quatre champs spécifiques fx: qui identifient le document. Sans cette plomberie complète, le fichier sera rejeté par les Plateformes Agréées comme non conforme.
Factur-X est-il obligatoire avec la réforme 2026 ?
Non, Factur-X n’est pas imposé. La réforme exige que les factures B2B transitent par une Plateforme Agréée dans l’un des trois formats du socle minimum : Factur-X, UBL ou CII. L’entreprise reste libre de choisir. En pratique, la majorité des éditeurs français ont retenu Factur-X comme format par défaut en raison de sa lisibilité humaine. Pour la grande entreprise ou ETI, l’obligation d’émission s’applique au 1er septembre 2026, étendue aux PME et TPE au 1er septembre 2027.
Quel profil Factur-X choisir pour une PME ?
Le profil EN 16931 est le bon choix dans neuf cas sur dix. Il garantit la conformité à la norme européenne, l’interopérabilité avec tout destinataire dans l’UE, et l’automatisation maximale en réception. Le profil BASIC suffit pour démarrer si le logiciel ne génère pas encore l’EN 16931 complet, sachant qu’une facture BASIC peut se déclarer EN 16931 sans modification dans la plupart des cas. Les profils MINIMUM et BASIC WL sont à éviter, sauf période transitoire courte au démarrage de la réforme.
Factur-X et ZUGFeRD désignent-ils le même standard ?
Oui, depuis ZUGFeRD 2.1 et Factur-X 1.0, les deux standards sont techniquement identiques : même conteneur PDF/A-3, même schéma XML CII, mêmes profils, mêmes règles de validation. La dénomination diffère selon le pays. ZUGFeRD est porté par le FeRD allemand, Factur-X par le FNFE-MPE français. La version courante au 15 janvier 2026, Factur-X 1.08 / ZUGFeRD 2.4, harmonise pleinement les deux référentiels et intègre la gestion des sous-lignes pour les factures composites.
Comment vérifier qu’une Factur-X reçue est conforme ?
Trois outils libres permettent de valider un fichier Factur-X. veraPDF teste la conformité du conteneur PDF/A-3. Le validateur Mustang, soutenu par la communauté FeRD, contrôle le XML contre les schémas XSD et les règles Schematron de la norme EN 16931. La plupart des Plateformes Agréées proposent aussi un validateur en interface web pour leurs utilisateurs. Côté entreprise, vérifier la cohérence entre le profil annoncé dans le XMP du PDF et celui déclaré dans le XML évite la majorité des rejets en amont.