Factur-X : le guide technique complet
niveaux, XML, validation, erreurs

Cet article est le guide technique de référence sur le format Factur-X. Il s'adresse aux développeurs, intégrateurs, éditeurs de logiciels et experts-comptables techniques qui doivent comprendre la structure interne d'un fichier Factur-X, choisir le bon profil, valider un XML contre la norme EN 16931, et corriger les erreurs les plus courantes. Si vous cherchez un guide non-technique sur la réforme, commencez par notre guide ultime facturation électronique 2026.

Anatomie d'un Factur-X : PDF/A-3 + XML CII

Un fichier Factur-X est un PDF hybride : un PDF lisible par l'humain qui contient, en pièce jointe intégrée, un fichier XML structuré lisible par la machine. C'est la combinaison des deux qui fait le Factur-X — ni l'un ni l'autre seul ne suffit.

• La couche PDF : un document PDF/A-3 (ISO 19005-3), le seul sous-ensemble de PDF qui autorise les pièces jointes intégrées. Le PDF contient la représentation visuelle de la facture — c'est ce que votre client voit quand il ouvre le fichier.
• La couche XML : un fichier nommé factur-x.xml (ou zugferd-invoice.xml pour ZUGFeRD), embarqué dans le PDF. Ce XML est conforme à la syntaxe UN/CEFACT Cross-Industry Invoice (CII). C'est ce que la PA et l'administration lisent automatiquement.
• Les métadonnées XMP : des métadonnées intégrées au PDF qui déclarent le profil Factur-X utilisé (fx:ConformanceLevel). Elles doivent correspondre au profil déclaré dans le XML — une incohérence provoque un rejet.

Les 5 profils : Minimum → Extended

Factur-X définit 5 profils qui déterminent le niveau de détail du XML. Chaque profil est cumulatif : il inclut les champs du profil inférieur et en ajoute. Chacun a son propre schéma XSD et ses règles Schematron.

Profil	Lignes de facture	Nb de champs	Cas d'usage	GuidelineID
MINIMUM	Non	~25	Strict minimum Chorus Pro. Équivalent OCR. En voie de disparition — ne sera pas accepté à terme.	urn:factur-x.eu:1p0:minimum
BASIC WL	Non	~45	Entête + pied de facture sans lignes. Toléré au démarrage de la réforme. Pas de détail ligne → automatisation limitée.	urn:factur-x.eu:1p0:basicwl
BASIC	Oui	~60	Premier profil avec lignes. Nom article, quantité, prix unitaire, TVA par ligne. Bon compromis pour les TPE.	urn:factur-x.eu:1p0:basic
EN 16931	Oui	~160	Profil complet norme européenne. Remises/charges multi-niveaux, références commande, périodes. Recommandé.	urn:cen.eu:en16931:2017
EXTENDED	Oui	~200+	EN 16931 + données sectorielles (douane, transport, incoterms). Inclut le profil EXTENDED-CTC-FR spécifique France.	urn:cen.eu:en16931:2017#compliant#...

Quel profil choisir ? Arbre de décision

• Votre destinataire a-t-il besoin des lignes de facture ? Si oui → BASIC minimum. Si non (cas rare, flux hybride EDI) → BASIC WL toléré temporairement.
• Avez-vous des remises/charges au niveau document ? Si oui → EN 16931 obligatoire (BASIC ne gère pas les remises/charges document).
• Avez-vous des références de commande, des périodes de facturation, des informations de livraison détaillées ? Si oui → EN 16931.
• Avez-vous des besoins sectoriels (douane, transport, incoterms, sous-lignes) ? Si oui → EXTENDED ou EXTENDED-CTC-FR.
• En cas de doute : choisissez EN 16931. C'est le profil recommandé par la FNFE-MPE et celui qui assure la meilleure interopérabilité avec toutes les PA.

Structure XML CII : l'arbre complet commenté

Le XML Factur-X suit la syntaxe UN/CEFACT Cross-Industry Invoice (CII), version D22B (depuis Factur-X 1.08). Voici l'arbre simplifié avec les nœuds principaux :

Nœud XML	Contenu	BT associés (exemples)
ExchangedDocumentContext	Profil (GuidelineID), identifiant processus	BT-24 (profil), BT-23 (processus)
ExchangedDocument	Numéro de facture, date, type	BT-1 (n° facture), BT-2 (date), BT-3 (type : 380=facture, 381=avoir)
SupplyChainTradeTransaction	Conteneur principal de la transaction	—
├ IncludedSupplyChainTradeLineItem[]	Lignes de facture (à partir du profil BASIC)	BT-126 (ID ligne), BT-129 (qté), BT-131 (montant net), BT-146 (prix), BT-153 (nom article)
├ ApplicableHeaderTradeAgreement	Vendeur, acheteur, références commande	BG-4 (vendeur), BG-7 (acheteur), BT-13 (n° commande)
├ ApplicableHeaderTradeDelivery	Livraison (adresse, date)	BG-13 (adresse livraison), BT-72 (date livraison)
└ ApplicableHeaderTradeSettlement	Paiement, TVA, totaux	BT-81 (moyen paiement), BG-23 (détail TVA), BG-22 (totaux)
├ ApplicableTradeTax[]	Ventilation TVA par catégorie/taux	BT-116 (base HT), BT-117 (montant TVA), BT-118 (taux), BT-151 (catégorie)
└ SpecifiedTradeSettlement HeaderMonetarySummation	Totaux de la facture	BT-106 (total HT lignes), BT-109 (total HT), BT-110 (total TVA), BT-112 (total TTC), BT-115 (montant à payer)

Validation : XSD vs Schematron (les 2 passes)

La validation d'un Factur-X n'est pas un processus unique — c'est une chaîne de deux passes indépendantes, chacune avec sa propre logique.

Passe 1 : XSD (structure)

Le XML Schema Definition (XSD) vérifie que le document est bien formé : balises correctement nommées, types de données respectés, structure arborescente conforme au modèle CII. Un fichier XSD-valide peut être parsé sans erreur — mais cela ne garantit pas qu'il est sémantiquement correct.

Passe 2 : Schematron (règles métier)

Le Schematron exprime des règles métier sous forme d'assertions XPath. C'est là que les vraies vérifications ont lieu : cohérence arithmétique (total HT = somme des lignes), présence conditionnelle des champs (SIREN obligatoire si client français), codes valides (devise ISO 4217, code TVA UNTDID 5305).

Les règles Schematron sont nommées BR-* (Business Rule). Les plus critiques : BR-CO-* (cohérence calculs), BR-S-* (TVA), BR-CL-* (listes de codes). Un validateur sérieux distingue les erreurs fatales (flag="fatal") des avertissements (flag="warning").

Les 10 erreurs BR-* les plus fréquentes (et comment les corriger)

Erreur	Champ	Cause	Correction
BR-16	BT-106	Total HT ≠ somme des montants nets des lignes	Vérifier les remises/charges document (BG-20, BG-21) et les arrondis par ligne
BR-CO-10	BT-110	Total TVA ≠ somme des montants TVA par catégorie	Recalculer la ventilation TVA. Attention aux arrondis multi-taux
BR-CO-15	BT-112	Total TTC ≠ total HT + total TVA	Vérifier BT-109 + BT-110 = BT-112. Arrondi au centime près
BR-01	BT-24	GuidelineID manquant ou incorrect	Vérifier l'URN du profil dans ExchangedDocumentContext
BR-02	BT-1	Numéro de facture vide	Certains ERP génèrent le XML avant attribution du numéro — retarder la génération
BR-08	BG-25	Aucune ligne de facture (profils BASIC+)	Ajouter au moins une IncludedSupplyChainTradeLineItem
BR-CL-04	BT-5	Code devise absent ou non ISO 4217	Utiliser « EUR » (pas « €» ni « Euros »)
BR-S-08	BT-118	Taux TVA incohérent avec la catégorie déclarée	Si catégorie « S » (standard), le taux doit être > 0. Si « E » (exonéré), taux = 0
BR-CL-01	BT-3	Code type document invalide	380 = facture, 381 = avoir, 384 = facture rectificative, 389 = auto-facture
BR-CO-09	BT-81	Code moyen de paiement absent ou invalide	Utiliser les codes UNTDID 4461 : 30 = virement, 58 = prélèvement SEPA, 48 = carte

Pour valider vos factures avant envoi et détecter ces erreurs, utilisez notre validateur gratuit.

PDF/A-3 : la couche conteneur (et ses pièges)

Le conteneur PDF doit respecter la norme PDF/A-3 (ISO 19005-3). C'est le seul sous-ensemble de PDF qui autorise les pièces jointes arbitraires — condition indispensable pour embarquer le XML.

• Pas de chiffrement : un PDF/A-3 ne peut pas être protégé par mot de passe
• Polices incorporées : toutes les polices utilisées doivent être embarquées dans le fichier (pas de dépendance externe)
• Pas de JavaScript : les scripts actifs sont interdits en PDF/A
• Métadonnées XMP obligatoires : le fx:ConformanceLevel doit correspondre au profil déclaré dans le GuidelineID du XML. Une incohérence = rejet
• Le fichier XML doit être nommé factur-x.xml et déclaré comme pièce jointe dans le catalogue PDF avec la relation Data ou Alternative

Factur-X vs ZUGFeRD : même format, deux noms

Factur-X et ZUGFeRD sont le même format technique. Factur-X est le nom français, ZUGFeRD est le nom allemand. Les deux sont développés conjointement par la FNFE-MPE (France) et le FeRD (Allemagne) depuis 2017.

• Factur-X 1.08 = ZUGFeRD 2.4 (version actuelle, janvier 2026)
• Même spécification technique : même XML CII, mêmes profils, mêmes règles de validation
• Seule différence : le nom du fichier XML intégré (factur-x.xml en France, zugferd-invoice.xml en Allemagne). Les validateurs acceptent les deux.
• Interopérabilité totale : une facture Factur-X émise en France est lisible en Allemagne (et inversement) sans conversion

Si vous travaillez avec des clients allemands, autrichiens ou suisses, vous utilisez déjà le même format qu'eux — juste sous un nom différent.

Version 1.08 (janvier 2026) : ce qui change

La version 1.08, en vigueur depuis le 15 janvier 2026, apporte des évolutions importantes :

• Base CII D22B : migration de D16B vers D22B (rétrocompatible). Plus de champs disponibles, meilleure gestion des sous-lignes.
• Sous-lignes : gestion des lignes de sous-total, articles composites (kits/bundles). Essentiel pour la réforme française (factures de situation BTP, forfaits avec détail).
• Nouveaux XSD et Schematron : 5 jeux de schémas mis à jour (un par profil). Les anciens schémas ne valident pas correctement les factures 1.08.
• Alignement avec les artefacts de validation EN16931 : les règles Schematron sont synchronisées avec la dernière version de la norme européenne.
• Rétrocompatibilité : les factures générées en 1.07 / ZUGFeRD 2.3 restent valides sous les schémas 1.08.

Questions fréquentes