Anatomie d'une facture Factur-X : disséquer le fichier

Votre logiciel génère un Factur-X, vous l'envoyez à la plateforme agréée, et il revient rejeté avec pour seul message : "fichier non conforme". Aucune ligne incriminée, aucun champ manquant identifié. Ce scénario est remonté en production lors des tests en sandbox de PA - et il a presque toujours la même cause racine : une incompréhension de ce que contient réellement le fichier. Cet article ouvre un Factur-X couche par couche, mappe les 4 nouvelles mentions B2B sur leurs balises XML exactes, et donne le workflow de validation local qui évite les aller-retours en production.

Ce qu'est vraiment un fichier Factur-X (et ce qu'il n'est pas)#

Un fichier Factur-X n'est pas un PDF avec des données en marge, ni un PDF enrichi de métadonnées. C'est la combinaison de deux couches indissociables : un PDF conforme à la norme PDF/A-3 (ISO 19005-3) et un fichier XML embarqué en pièce jointe, suivant la syntaxe CII (Cross Industry Invoice). Supprimer ou altérer l'une des deux couches invalide le tout. La lisibilité humaine du PDF ne sauve pas un XML malformé, et un XML parfait embarqué dans un PDF non conforme PDF/A-3 sera rejeté en amont.

Il est important de rappeler que Factur-X n'est pas le format unique imposé par la réforme de la facturation électronique. UBL 2.1 et CII standalone sont également acceptés par les plateformes agréées immatriculées. Factur-X a l'avantage de produire un document lisible par l'humain et traitable automatiquement, ce qui explique son adoption dominante en France - mais le choix du format reste une décision technique à valider avec votre PA.

Les six profils : du MINIMUM au EN 16931 complet#

La spécification Factur-X v1.0.07 de la FNFE-MPE définit six profils de complexité croissante. Le profil MINIMUM ne contient que 7 champs obligatoires : il est conçu pour les flux entre donneurs d'ordre et sous-traitants sans TVA récupérable, typiquement dans des chaînes de sous-traitance. À l'autre extrémité, le profil EN 16931 couvre l'intégralité des 65 éléments sémantiques de la norme européenne.

Choisir un profil trop bas pour un flux B2B interentreprises taxable est une erreur fréquente en production. Un profil BASIC WL, par exemple, n'inclut pas les lignes de facture détaillées : acceptable pour certains cas, mais insuffisant dès qu'un acheteur a besoin de réconcilier les lignes dans son ERP. Le profil déclaré dans l'en-tête XML (balise ram:GuidelineSpecifiedDocumentContextParameter) doit correspondre exactement aux données présentes - toute divergence déclenche une erreur BR-xx.

Couche 1 : les contraintes PDF/A-3 (ISO 19005-3)#

Le standard PDF/A-3 est un profil d'archivage du PDF conçu pour la conservation à long terme. Il interdit explicitement les ressources externes (polices non embarquées, images référencées par URL), les scripts JavaScript, et certaines formes de chiffrement. Une violation de ces contraintes invalide l'enveloppe avant même que la plateforme agréée ne lise le XML embarqué - le fichier est rejeté à l'ingestion.

Le point technique le plus souvent omis concerne la déclaration de la pièce jointe XML dans le dictionnaire du fichier PDF. La pièce jointe doit être déclarée avec la relation AFRelationship='Data' dans le dictionnaire d'attachement. Les exports PDF génériques (bibliothèques non spécialisées, impressions virtuelles) ne renseignent pas cette métadonnée, produisant un PDF/A-3 techniquement valide mais non reconnu comme Factur-X par les PA.

L'outil de référence pour auditer cette couche est veraPDF, un validateur open source qui vérifie la conformité PDF/A-3 indépendamment du contenu CII. Son intégration dans un pipeline CI/CD en amont de l'envoi à la PA couvre les violations de couche 1 avant qu'elles n'atteignent la production.

Couche 2 : la structure XML CII et les balises à risque#

Le XML CII embarqué s'organise en blocs fonctionnels hiérarchiques. Au premier niveau : ExchangedDocumentContext (profil et contexte) et SupplyChainTradeTransaction (la transaction commerciale elle-même). Ce dernier se décompose en trois sous-blocs : ApplicableHeaderTradeAgreement (parties et références), ApplicableHeaderTradeDelivery (livraison) et ApplicableHeaderTradeSettlement (règlement et TVA). Les lignes de facture sont portées par IncludedSupplyChainTradeLineItem, répété autant de fois que nécessaire.

Les erreurs de placement - balise syntaxiquement correcte mais insérée dans le mauvais bloc parent - sont invisibles à l'oeil et ne génèrent aucune alerte dans un éditeur XML générique. La norme EN 16931-3 (CEN / AFNOR) définit l'arborescence exacte avec ses règles de cardinalité. Une balise ram:TaxTotalAmount placée dans ApplicableHeaderTradeAgreement au lieu de ApplicableHeaderTradeSettlement produit une erreur BR-CO-15 sans que le contenu soit en cause.

Mapper les 4 nouvelles mentions B2B 2026 sur les balises CII#

Les 4 nouvelles mentions obligatoires B2B 2026 s'ajoutent aux 13 mentions classiques et se mappent sur des balises CII précises. Le SIRET de l'acheteur se place dans ram:BuyerTradeParty / ram:ID avec l'attribut schemeID="0002" - l'absence de cet attribut ou une valeur incorrecte (par exemple schemeID="SIRET") est la cause numéro 1 de rejet silencieux signalé par les PA en production. L'adresse de livraison se déclare dans ram:ApplicableHeaderTradeDelivery / ram:ShipToTradeParty / ram:PostalTradeAddress.

La nature de l'opération (vente de biens, prestation de services, ou mixte) fait l'objet d'un mapping spécifique dans la CII - la balise exacte et les valeurs de code admises sont à vérifier dans les Spécifications externes des flux DGFiP v2.3, qui précisent les extensions nationales applicables au-delà de la norme EN 16931 de base. L'option de paiement de la TVA sur les débits - mention applicable uniquement aux assujettis ayant opté pour ce régime - se traduit par la valeur "72" dans ram:ApplicableTradeTax / ram:DueDateTypeCode au niveau header. Ces quatre mappings sont documentés dans les Spécifications externes des flux DGFiP v2.3.

Valider avec Mustang Project : lire les codes BR-xx et RG-FA-xxx#

Mustang Project est une librairie Java open source qui implémente le moteur de validation EN 16931-3. Plusieurs plateformes agréées l'utilisent en coulisse pour leur validation sémantique. L'intégrer localement - via son interface CLI ou son API Maven - permet de reproduire les contrôles de la PA avant l'envoi, et d'obtenir des codes d'erreur exploitables plutôt qu'un message générique "fichier non conforme".

Les codes BR-xx (BR-01, BR-CO-15, BR-S-08...) sont définis dans EN 16931-3 et identifient la règle sémantique violée avec sa localisation XPath. Les codes RG-FA-xxx sont les règles de gestion spécifiques DGFiP, publiées dans les Spécifications externes des flux v2.3 et implémentées en surcouche par les PA françaises. Une erreur RG-FA-xxx sans code BR-xx associé indique généralement une violation d'une règle française qui n'existe pas dans la norme européenne de base - typiquement une des 4 mentions B2B 2026.

Le workflow de validation en trois niveaux couvre la grande majorité des causes de rejet en production : veraPDF d'abord (conformité PDF/A-3), Mustang CLI ensuite (validation sémantique CII), puis un test d'envoi en sandbox de la PA cible. Ces trois niveaux sont indépendants et complémentaires - passer les deux premiers ne garantit pas le passage du troisième si la PA applique des règles RG-FA-xxx non encore documentées publiquement. Consultez la checklist de préparation pour septembre 2026 pour intégrer ces étapes dans votre processus de release.

Checklist de production : 10 points de contrôle avant envoi à la PA#

Avant d'envoyer un flux Factur-X en production, vérifiez ces 10 points dans l'ordre :

1. Nom du fichier XML - vérifier que la pièce jointe s'appelle exactement "factur-x.xml" (casse comprise) dans le code de génération, pas seulement dans l'affichage.
2. Profil déclaré vs données présentes - la valeur de ram:GuidelineSpecifiedDocumentContextParameter doit correspondre au profil réellement produit.
3. AFRelationship='Data' - vérifier dans le dictionnaire PDF que la pièce jointe XML est correctement déclarée avec cette relation.
4. Conformité PDF/A-3 - passer veraPDF sur le fichier généré ; aucune erreur de niveau "fail" ne doit subsister.
5. schemeID SIRET acheteur - vérifier que ram:BuyerTradeParty / ram:ID porte l'attribut schemeID="0002" avec un SIRET à 14 chiffres valide.
6. Balises des 4 mentions 2026 - contrôler la présence et le placement de ShipToTradeParty, du mapping nature d'opération (balises à confirmer dans les Spécifications DGFiP v2.3), et DueDateTypeCode si applicable.
7. Règles BR-CO (cohérence) - passer Mustang CLI ; les erreurs BR-CO indiquent des incohérences de calcul (totaux TVA, montants ligne vs header).
8. Règles RG-FA-xxx - si la PA fournit un validateur sandbox, l'utiliser systématiquement après Mustang.
9. Conservation - s'assurer que le système d'archivage conserve les fichiers 10 ans (Code de commerce, art. L123-22), avec horodatage et intégrité garantie.
10. Logiciel de génération - tous les logiciels ne génèrent pas un Factur-X valide nativement ; un comparatif des logiciels conformes à la réforme 2026 permet d'identifier les solutions validées en production.

Le choix du logiciel ou de l'ERP est une variable critique souvent sous-estimée. Certains outils génèrent un fichier qui passe les contrôles visuels mais échouent sur les règles RG-FA-xxx. Pour les volumes importants, l'intégration d'une suite de tests automatisés en amont du flux PA n'est pas optionnelle - c'est ce qui distingue une mise en production réussie d'une coupure de flux à J+1. Voir aussi notre guide sur les sanctions liées à la facturation électronique 2026 pour mesurer l'enjeu financier d'un taux de rejet non maîtrisé.

Pour aller plus loin#

• Factur-X, UBL, CII : choisir le bon format selon votre flux
• Préparer la réforme de la facturation électronique : guide complet 2026
• Comparatif des logiciels de facturation conformes à la réforme 2026