Derrière le mot « facture électronique », l’image qui s’impose reste celle d’un PDF envoyé par e-mail. La réforme dit l’inverse. À compter du 1ᵉʳ septembre 2026, toute entreprise assujettie à la TVA devra recevoir ses factures sous forme de données XML structurées, transmises par une plateforme agréée. Le PDF devient une couche de confort visuel : juridiquement, la facture, c’est le fichier de données.
Ce basculement repose sur un langage que peu de dirigeants connaissent et qu’aucun n’aura pourtant à écrire : le XML, pour eXtensible Markup Language. Il range chaque information de la facture dans une balise dédiée, lisible par les machines. Les formats et normes de la facture électronique reposent tous sur ce socle, de Factur-X à UBL en passant par CII.
Comprendre sa logique n’a toutefois rien d’un exercice théorique. C’est elle qui explique pourquoi une facture peut être rejetée avant même d’atteindre son destinataire, ce qu’il faut archiver pendant dix ans, et sur quels critères choisir son outil de facturation.
Ce que le XML change par rapport à un PDF
Un PDF montre une facture. Un XML la décrit. La nuance paraît mince, elle conditionne pourtant toute l’architecture de la réforme : seul un fichier décrit champ par champ se traite sans intervention humaine.
Des balises que les machines lisent sans vous
Dans un fichier XML, chaque donnée vit entre une balise ouvrante et une balise fermante : le montant hors taxes dans la sienne, le taux de TVA dans une autre, le SIREN du vendeur, la date d’échéance, chaque ligne de prestation. Un logiciel comptable y pioche directement, sans reconnaissance optique ni ressaisie. Sur un PDF classique, ces mêmes informations restent des pixels : l’œil humain les comprend, la machine les devine au mieux.
La conséquence est mesurable : zéro erreur de retranscription, des écritures comptables générées à la réception, un bon à payer déclenché sur la date d’échéance lue dans le fichier. C’est aussi pourquoi convertir un PDF en facture électronique ne se résume jamais à renommer un fichier : il faut reconstruire la donnée structurée derrière l’image.
Des données structurées bien avant le XML
L’idée n’est pas neuve. Depuis les années 1980, la grande distribution et l’automobile échangent des factures en données structurées via l’EDI, ancêtre et complément des plateformes agréées. Le standard EDIFACT y fait circuler des millions de documents par an, sans le moindre PDF.
Le XML reprend ce principe en le rendant accessible. Là où un flux EDI exigeait des mois d’intégration et un budget de grand compte, un fichier XML s’ouvre dans un simple éditeur de texte et se valide avec des outils gratuits. La réforme de 2026 généralise ainsi à 10 millions d’entreprises ce que l’EDI réservait à quelques milliers. EDIFACT reste d’ailleurs toléré entre partenaires déjà équipés, au titre de l’interopérabilité.
Pendant la montée en charge, et jusqu’à fin 2027, les plateformes agréées peuvent prendre en charge la conversion d’un PDF déposé en format structuré conforme. Une souplesse transitoire : à terme, la donnée doit naître structurée dans votre outil.
EN 16931, la grammaire imposée du XML de facture
Un XML écrit librement ne vaut rien : si chacun nomme ses balises à sa façon, aucune machine ne comprend personne. La Commission européenne a donc imposé une sémantique commune, publiée par le CEN en 2017 sous la référence EN 16931, en application de la directive 2014/55/UE.
164 données métiers numérotées
La norme européenne EN 16931 définit chaque information possible d’une facture sous un identifiant unique : BT-1 pour le numéro de facture, BT-2 pour la date d’émission, BT-30 pour le SIREN du vendeur. Ces champs se regroupent en 31 familles, les Business Groups, comme le BG-25 qui porte les lignes de facture.
Chaque champ possède en outre une cardinalité : « 1..1 » signifie présence obligatoire, « 0..1 » présence facultative. Par ailleurs, 126 règles de gestion verrouillent la cohérence de l’ensemble : totaux qui doivent se recouper, décimales autorisées, codes admis. Côté français, la norme AFNOR XP Z12-012 décline cette grammaire en profils opérationnels pour les plateformes agréées.
La numérotation court de BT-1 à BT-165, mais on ne compte que 164 champs : le BT-4 n’existe pas dans la version de base de la norme. Le cadre français a fini par réutiliser cet identifiant vacant pour coder le type de transaction.
Les extensions françaises EXT-FR-FE
La norme européenne ignore certaines obligations du droit français. L’administration l’a donc complétée par des extensions au préfixe EXT-FR-FE. Elles ajoutent notamment la mention de franchise en base de TVA de l’article 293 B du CGI, les pénalités de retard avec l’indemnité forfaitaire de recouvrement de 40 €, ou encore le couple SIREN/SIRET propre au référentiel national.
Ces ajouts ne sont pas décoratifs : une facture B2B française sans ces champs échoue aux contrôles, même si elle respecte la norme européenne de base. La norme AFNOR XP Z12-014 et ses cas d’usage documentent ces situations concrètes, tandis que le profil EXTENDED-CTC-FR porte les enrichissements les plus complets du dispositif français.
Trois syntaxes XML pour une même norme
EN 16931 dit ce qu’une facture doit contenir, pas comment l’encoder. Le socle français retient donc trois syntaxes, toutes adossées au XML, que chaque plateforme agréée doit savoir émettre et recevoir.
Factur-X, le XML caché dans un PDF
Factur-X, le format hybride PDF+XML, glisse un fichier nommé factur-x.xml à l’intérieur d’un PDF/A-3. L’humain ouvre un PDF ordinaire, la machine lit le XML embarqué. Ce standard franco-allemand, identique au ZUGFeRD allemand, circule sur Chorus Pro depuis 2018.
Sa souplesse tient à ses cinq profils, du MINIMUM et ses 18 données jusqu’à EXTENDED, en passant par le profil EN 16931 qui couvre l’intégralité du noyau sémantique. Une TPE peut ainsi démarrer léger, puis enrichir son XML sans changer de format. C’est la syntaxe recommandée pour la quasi-totalité des PME françaises.
UBL et CII, le XML à l’état pur
Les deux autres syntaxes se passent de PDF. UBL, Universal Business Language, est maintenu par le consortium OASIS et normalisé ISO/IEC 19845 : c’est la langue du réseau Peppol et des échanges internationaux. De son côté, CII, Cross Industry Invoice, émane de l’UN/CEFACT et aligne plus de 2 000 champs possibles, ce qui en fait le choix des flux industriels issus de l’EDI.
| Syntaxe | Lisible sans logiciel | Porté par | Usage privilégié |
|---|---|---|---|
| Factur-X | Oui (PDF intégré) | FNFE-MPE · FeRD | TPE et PME françaises |
| UBL | Non (XML pur) | OASIS · ISO/IEC 19845 | International, réseau Peppol |
| CII | Non (XML pur) | UN/CEFACT | Grands comptes, flux EDI |
Le choix n’engage d’ailleurs que l’émetteur : les trois syntaxes transportent la même sémantique EN 16931, et les plateformes savent passer de l’une à l’autre. Autrement dit, votre client en CII lira sans difficulté votre Factur-X.
Qui écrit le XML, et qui le contrôle
La bonne nouvelle tient en une phrase : personne ne rédige de XML à la main. La contrepartie aussi : chaque fichier subit une batterie de contrôles automatiques avant d’exister légalement.
Votre logiciel génère, vous saisissez seulement les données
En pratique, vous renseignez client, lignes et montants dans votre outil de facturation, comme avant. Le logiciel mappe ensuite chaque donnée vers la balise EN 16931 correspondante, assemble le fichier et le transmet. Fin mai 2026, 134 plateformes agréées immatriculées par la DGFiP assuraient ce relais, et plus de 500 000 entreprises avaient déjà déclaré leur adresse de réception.
Pour les systèmes d’information maison, le dialogue passe par une API de facture électronique exposée par la plateforme. Afin d’éviter 134 dialectes incompatibles, la norme AFNOR XP Z12-013 standardise précisément cette interface entre l’entreprise et sa plateforme agréée.
Schematron, le gendarme du fichier
Avant transmission, chaque XML passe deux couches de validation. Le schéma vérifie d’abord la structure : balises présentes, types respectés. Ensuite, Schematron, les règles de validation des factures électroniques, contrôle la cohérence métier : un champ optionnel devient obligatoire selon le contexte fiscal, les totaux doivent se recalculer juste.
Les rejets portent des codes explicites : REJ_SEMAN pour une faute sémantique, REJ_COH pour une incohérence, REJ_UNI pour un doublon. Le fichier validé voyage ensuite via les protocoles d’échange EDI, AS2, SFTP et AS4, puis son cycle de vie remonte à l’administration à travers quatre statuts obligatoires : déposée, rejetée, refusée, encaissée.
La facture est alors réputée non émise, avec le retard de paiement qui s’ensuit. Avant de renvoyer le même fichier, lisez le rapport de rejet : le code indique précisément la donnée fautive.
Après l’envoi : ce que vaut un XML dans le temps
La vie du fichier ne s’arrête pas à la transmission. Désormais, l’original de la facture, c’est la donnée structurée elle-même : c’est elle qui fait foi en cas de contrôle, pas son rendu visuel.
Le fichier fait foi
Le Code général des impôts exige trois garanties : authenticité de l’origine, intégrité du contenu, lisibilité. La valeur probante de la facture électronique s’obtient historiquement par la signature électronique qualifiée ou par la piste d’audit fiable, cette documentation interne qui relie chaque facture à sa livraison réelle.
Le format structuré transmis par plateforme agréée devient la troisième voie, appelée à dominer : le contrôle de conformité et l’horodatage interviennent dès l’émission, ce qui sécurise la chaîne sans formalisme supplémentaire côté entreprise.
Archiver le fichier structuré, pas son impression
Conserver une copie écran ou un export imprimé ne suffit plus : l’archivage à valeur probante porte sur le fichier d’origine, XML ou Factur-X complet, avec ses métadonnées. En France, la norme NF Z42-013 encadre les systèmes capables de garantir cette intégrité dans la durée.
Concrètement, la plupart des plateformes intègrent un coffre-fort numérique qui scelle chaque fichier, journalise les accès et restitue la facture identique des années plus tard. Vérifiez ce point au moment de choisir votre outil : un archivage non conforme ruine la valeur probante de fichiers pourtant parfaitement émis.
Ce que le XML est : le support légal de la facture électronique, structuré selon les 164 données métiers de la norme EN 16931, décliné en trois syntaxes (Factur-X, UBL, CII).
Ce qu’il n’est pas : un langage à apprendre. Votre logiciel le génère, Schematron le contrôle, la plateforme agréée le transmet et l’archive.
Le point de vigilance : l’original à conserver est le fichier structuré lui-même, pendant dix ans, dans un système qui garantit son intégrité.
Reste la question pratique : quel outil prend tout cela en charge sans transformer votre facturation en projet informatique ?
Questions fréquentes
Faut-il savoir lire le XML pour vérifier une facture reçue ?
Non. Votre logiciel ou votre plateforme restitue automatiquement une version lisible des données reçues, et un fichier Factur-X s’ouvre comme n’importe quel PDF. Le contrôle humain porte sur le fond, montants, prestations, échéance, jamais sur les balises. Si un détail vous intrigue, l’outil affiche la donnée structurée correspondante en clair.
Peut-on encore envoyer ses factures en PDF par e-mail après septembre 2026 ?
Entre entreprises françaises assujetties à la TVA, non : la transmission passe obligatoirement par une plateforme agréée, au format structuré. L’e-mail reste en revanche possible vers les particuliers et les clients étrangers, ces flux relevant alors de l’e-reporting. Beaucoup d’entreprises continueront d’ailleurs d’adresser une copie PDF par courtoisie, sans valeur légale.
Peut-on ouvrir et modifier un fichier XML de facture ?
Techniquement oui, un éditeur de texte suffit. Juridiquement, c’est destructeur : toute modification après émission rompt l’intégrité du document, fait échouer les contrôles d’empreinte et expose l’entreprise en cas de vérification fiscale. Une erreur se corrige par une facture rectificative ou un avoir, jamais en retouchant le fichier d’origine.
Combien de temps faut-il conserver le fichier XML d’une facture ?
Six ans au titre du droit fiscal, dix ans au titre du Code de commerce : c’est cette seconde durée qui sert de référence en pratique. La conservation porte sur le fichier dans son format d’origine, accompagné des éléments qui prouvent son intégrité, horodatage et empreinte notamment.
Le XML de facture est-il le même partout en Europe ?
Le socle sémantique EN 16931 est commun à toute l’Union, imposé par la directive 2014/55/UE. Chaque État y ajoute toutefois ses déclinaisons : XRechnung en Allemagne, FatturaPA en Italie, extensions EXT-FR-FE en France. Une facture conforme au noyau européen circule donc partout, mais les mentions nationales du pays de destination peuvent s’ajouter.