La structure XML d’une facture Factur-X : champs et groupes

La page visible d’une facture Factur-X est pour les humains. Le XML embarqué est pour les logiciels — et un logiciel ne lit pas un en-tête, il lit des champs aux noms fixes, à des places fixes. Cette page montre quels champs existent, où ils se trouvent et lesquels décident réellement de l’acceptation ou du rejet.

Le XML suit la syntaxe UN/CEFACT Cross Industry Invoice (CII), l’une des deux que reconnaît l’EN 16931. L’autre est UBL, répandue dans le réseau Peppol. Elles disent la même chose ; elles l’écrivent seulement autrement.

Les trois blocs

• ExchangedDocumentContext — selon quelle spécification le document est construit. L’identifiant de profil BT-24 est ici (voir Profils), et nulle part ailleurs. Le destinataire le lit en premier, car il détermine le corpus de règles qu’il appliquera.
• ExchangedDocument — l’identité de la facture : numéro BT-1, code type BT-3, date d’émission BT-2 et textes libres.
• SupplyChainTradeTransaction — tout le reste, en trois groupes : TradeAgreement (qui avec qui, sous quelles références), TradeDelivery (quoi, quand, où) et TradeSettlement (paiement, TVA, totaux).

Chaque ligne de facture est un IncludedSupplyChainTradeLineItem dans la transaction — et répète le même découpage en miniature : accord sur le prix, quantité livrée, règlement de la ligne.

Pourquoi les champs s’appellent BT et BG

La norme décrit d’abord le sens, ensuite l’écriture. Un BT (Business Term) est un champ ; un BG (Business Group) est un groupe de champs liés. « Nom du vendeur », c’est BT-27, que le document soit écrit en CII ou en UBL — les éléments XML diffèrent, le champ est le même.

En pratique : lorsqu’un rapport de contrôle signale BT-31, vous n’avez pas besoin de connaître le chemin XML. Vous avez besoin de savoir quelle information manque — ici, le numéro de TVA du vendeur. Les codes de règle qui pointent vers ces champs sont détaillés dans Règles de gestion.

Ce que toute facture doit porter

La norme exige les champs suivants sans exception. S’il en manque un, le contrôle signale une règle BR-* et le document est invalide.

Ce qui frappe, c’est ce qui n’y figure pas : le numéro de TVA. Il n’est pas toujours obligatoire — mais dès que vous faites apparaître de la TVA ou appliquez l’autoliquidation, BR-CO-09 l’exige, préfixe pays compris.

Les données du vendeur : l’en-tête devenu champs

Sur papier, le vendeur est ce qui figure en haut à gauche. Dans le XML, ce sont des champs nommés, et le logiciel du destinataire lit ceux-là, pas votre mise en page.

• BT-27 — nom du vendeur. Le nom juridique, pas la marque du logo.
• BG-5 — adresse postale, avec code pays. Sans lui, la facture ne passe pas.
• BT-31 — numéro de TVA, avec son préfixe (FR…, DE…).
• BT-32 — identifiant fiscal, lorsqu’il est utilisé à la place.

Une faute de frappe dans BT-31 est la plus coûteuse des erreurs bon marché : elle ne se voit pas à la création, elle se répète sur chaque facture de l’année et n’apparaît que le jour où un destinataire vérifie le numéro. D’où l’intérêt de ranger ces données une fois dans le profil de l’entreprise plutôt que de les ressaisir.

Référence acheteur et numéro de commande : les champs qui décident du paiement

Une facture arithmétiquement irréprochable peut revenir pour une raison sans rapport avec les montants : le destinataire ne parvient pas à la rattacher à un service, à un contrat ou à une commande.

• BT-10 — référence acheteur. Un identifiant que le client communique à l’avance. Chez les acheteurs publics allemands, c’est la Leitweg-ID, et la règle nationale BR-DE-15 rend le champ obligatoire.
• BT-13 — référence de commande. Le numéro de commande du client, avec lequel son système rapproche automatiquement facture et commande.

Les grands donneurs d’ordre privés fonctionnent désormais pareil : pas de référence, pas de comptabilisation automatique. Demandez les deux à la commande, pas au moment de la relance.

Date de livraison et période de facturation : deux choses différentes

Une facture porte au moins deux dates de sens différent, et les confondre est l’une des sources d’ennuis les plus discrètes.

Pour une facturation récurrente, la période indique en outre au destinataire ce qu’il paie sans lire le libellé des lignes — et BR-29 veille à ce que la date de début ne soit pas postérieure à la date de fin.

Les lignes : quantité, unité, prix

Une ligne porte quatre éléments solidaires :

• BT-129 — la quantité ;
• BT-130 — le code de l’unité de mesure ;
• BT-146 — le prix unitaire net ;
• BT-131 — le montant net de la ligne.

L’unité n’est pas du texte libre. « pce », « lot » ou « h » ne suffisent pas — il faut un code de la liste UN/ECE Recommandation 20, pour que les deux systèmes entendent la même chose.

Remises, majorations et frais de port

Une ligne « moins 10 % » est lisible par un humain et dénuée de sens pour un logiciel. La norme a ses propres emplacements : BG-20 pour les remises au niveau document et BG-21 pour les majorations, ainsi que leurs équivalents sur chaque ligne.

Chaque remise et chaque majoration porte trois choses :

• un montant — BT-92 pour la remise, BT-99 pour la majoration ;
• un motif, en clair ou sous forme de code (BT-98 et BT-105), pour que le destinataire comptabilise correctement ;
• une catégorie et un taux de TVA, car une remise réduit la base imposable et suit le même traitement.

Le port, l’emballage et les majorations de paiement relèvent également de là, et non du prix unitaire. Ainsi présentés, ils passent les contrôles d’arrondi du destinataire ; noyés dans le prix unitaire, ils produisent des écarts BR-CO-* que personne ne saura ensuite expliquer.

Conditions de paiement

« Payable sous 14 jours » est une phrase. Dans une facture structurée, cela devient :

• BT-9 — la date d’échéance, comme date réelle et non comme description ;
• BT-20 — les conditions de paiement en texte, escompte compris ;
• BG-16 — l’instruction de paiement : moyen de paiement, IBAN, titulaire du compte.

L’objectif : le système du destinataire planifie le paiement sans lire de texte libre. Une échéance rédigée en phrase plutôt qu’en date signifie, en pratique, que votre facture atterrit dans la file où quelqu’un la traite à la main.

Plus d’une devise

Lorsque la facture est émise dans une devise et la TVA déclarée dans une autre, la norme veut les deux explicitement, plutôt qu’une hypothèse :

• BT-5 — la devise de la facture ;
• BT-6 — la devise de comptabilisation de la TVA, si elle diffère ;
• le taux de conversion à la date d’émission.

L’absence de ces champs est une cause fréquente de rejet des factures transfrontalières — et une cause qui ne se voit pas dans les montants.

Un avoir n’est pas une facture avec un moins

C’est l’erreur qu’apportent les comptables venus du PDF simple. Dans la norme, l’avoir est un type de document à part entière, piloté par BT-3 :

• 380 — facture ;
• 381 — avoir.

Les montants y sont positifs ; le sens vient du code type. S’y ajoute la référence au document corrigé — BG-3 portant le numéro de la facture précédente (BT-25), ce que vérifie BR-55. Une « facture à montants négatifs » ne passe pas le contrôle et n’est pas non plus comptabilisable par le destinataire.

Questions fréquentes

Dois-je savoir écrire le XML à la main ?

Non. Vous devez savoir lire ce que dit un rapport de contrôle — c’est autre chose. Un rapport nomme le code de règle et le champ ; de là, le chemin mène vers le système qui a produit la facture, pas vers un éditeur XML.

Où trouver le profil dans le fichier ?

Dans l’élément GuidelineSpecifiedDocumentContextParameter du premier bloc, c’est-à-dire BT-24. La signification des URN est détaillée dans Profils.

CII est-il meilleur qu’UBL ?

Non, c’est une autre écriture du même modèle. ZUGFeRD et Factur-X utilisent CII, Peppol surtout UBL. Si quelqu’un impose UBL, c’est une question de réseau de réception, pas de qualité des données.

Puis-je ajouter mes propres champs ?

Uniquement via le profil EXTENDED, et même alors ils ne sont compris que par un logiciel qui les connaît. Tout ce que la norme modélise a sa place dans ses propres champs — c’est là qu’on le lit.

Pourquoi le contrôle conteste-t-il un total alors que la page est juste ?

Parce qu’il additionne les champs, pas la page. La cause la plus fréquente : des remises enfouies dans le prix unitaire au lieu d’être déclarées en BG-20. Les familles de règles concernées sont dans Règles de gestion.

Le XML doit-il correspondre à la page visible ?

Oui, et en cas de divergence c’est le XML qui fait foi. La circulaire du ministère allemand des Finances du 15 octobre 2025 le précise pour les formats hybrides : la partie structurée prévaut, et un écart met en risque la déduction de TVA.

Comment regarder le XML d’une facture reçue ?

Le plus simple est de la contrôler — le rapport montre le profil, les champs et les constats. La marche à suivre est détaillée dans Contrôler une facture.

En résumé

• Trois blocs, et presque tout tient dans le troisième — totaux et TVA sont tout en bas, dans le règlement.
• BT est un champ, BG un groupe. Le numéro est indépendant de la syntaxe : BT-27 est le même nom de vendeur en CII et en UBL.
• Douze champs sont obligatoires sans exception, et le numéro de TVA s’y ajoute dès qu’on fait apparaître de la taxe.
• BT-10 et BT-13 décident du paiement, pas de la validité — chez l’acheteur public allemand, BR-DE-15 en fait une obligation.
• Les unités sont des codes de l’UN/ECE Rec 20, pas du texte libre.
• Les remises vont dans BG-20, pas dans le prix unitaire — sinon les totaux ne tombent pas juste.
• Un avoir porte le code type 381, des montants positifs et une référence à la facture d’origine.

Voir le XML derrière vos propres factures sans avoir à le construire ? Créez un compte gratuit — ou contrôlez un fichier existant sans inscription et suivez la structure sur un document à vous.