Règles de gestion EN 16931 : ce qui fait vraiment rejeter une facture

Le XML d’une facture peut être irréprochable dans sa forme et faux malgré tout. La validation de schéma contrôle que chaque élément se trouve là où le schéma l’attend et porte le bon type de données ; elle ne dit rien de la cohérence des montants, du bien-fondé d’une exonération ni de la possibilité même d’identifier le vendeur. C’est cet écart que comblent les règles de gestion.

Elles sont la raison pour laquelle la plupart des factures rejetées le sont. Un fichier qui échoue ici s’ouvre parfaitement dans un lecteur PDF, s’analyse sans erreur comme XML — et n’est toujours pas une facture EN 16931 valide.

Ce qu’est réellement une règle de gestion

Chaque règle est une assertion unique sur le contenu d’une facture, écrite en Schematron et publiée aux côtés de la norme. Là où le schéma dit « un élément peut figurer ici », une règle de gestion dit par exemple : le total TTC doit être égal au total HT augmenté du total de TVA. En comptant toutes les catégories de TVA et tous les types de document, on arrive à plusieurs centaines d’assertions de ce genre.

Les règles sont écrites contre le modèle sémantique, non contre le format de fichier : elles parlent de termes métier — BT-112 pour le total TTC, BT-31 pour le numéro de TVA du vendeur — et non de chemins XML. La même règle s’applique donc à l’identique à une facture CII contenue dans un fichier ZUGFeRD et à une facture UBL transmise via Peppol.

Les familles de règles

Le préfixe d’un code indique de quel jeu de règles il provient, et c’est la première chose à établir — car tous les jeux ne s’appliquent pas à tous les fichiers.

Toutes les règles ne s’appliquent pas à votre fichier

C’est là que les rapports de validation sont le plus souvent mal lus, et cela coûte du temps réel.

Un exemple qui apparaît sur chaque fichier : BR-DE-21 exige que l’identifiant de spécification (BT-24) soit un identifiant XRechnung. Un document ZUGFeRD ou Factur-X y déclare par définition un identifiant ZUGFeRD ; la règle ne peut donc jamais passer — et ne doit jamais être comptée comme un échec. Notre panneau de validation la marque comme non applicable au profil et la retire du décompte plutôt que de laisser l’utilisateur s’en inquiéter.

Les profils restreignent eux aussi le jeu de règles. Un fichier MINIMUM ou BASIC WL porte délibérément moins d’informations que la EN 16931 n’en exige et n’est pas mesuré au jeu complet. Ce que contient chaque profil est traité dans les profils Factur-X et ZUGFeRD.

Les échecs qui surviennent vraiment

En pratique, un petit nombre de règles concentre l’essentiel des rejets. Ce sont celles qui reviennent le plus souvent lorsqu’on fait passer dans un validateur de vraies factures de vrais émetteurs allemands et français.

Pourquoi un centime fait rejeter une facture

L’échec le plus fréquent est arithmétique, et ce n’est presque jamais une erreur de calcul. C’est un arrondi appliqué de manière incohérente.

Si les prix unitaires sont multipliés en pleine précision, additionnés, puis seulement arrondis, le total diffère parfois d’un centime des mêmes chiffres arrondis ligne par ligne. Comptablement, les deux démarches se défendent ; une seule correspond à ce que la règle recalcule. BR-CO-* ne se soucie pas de la convention retenue — elle exige seulement que les nombres du document soient cohérents entre eux.

Trois habitudes évitent presque tout :

• Arrondir une fois, à une étape définie, et dériver chaque total des valeurs arrondies plutôt que des valeurs brutes.
• Ne pas mélanger arrondi au niveau unitaire et au niveau ligne dans un même document. Choisissez-en un et appliquez-le partout.
• Ne jamais retoucher le total à la main pour qu’il tombe juste. Cela ne fait que déplacer l’écart, le plus souvent vers la ventilation de TVA.

Erreurs et avertissements ne sont pas la même chose

Un rapport mêle deux sévérités, et les confondre coûte de l’effort dans les deux sens. Un constat bloquant signifie que le document est invalide : il sera rejeté. Un avertissement signale quelque chose d’inhabituel mais admis — un champ recommandé laissé vide, une valeur légale mais rarement utilisée, ou une règle d’une CIUS nationale qui ne s’applique pas à votre document.

Les avertissements méritent une lecture, car un destinataire peut exiger plus que la norme. Ils ne méritent pas d’être ramenés à zéro.

Corriger la cause, pas le fichier

Quand une règle échoue, le message pointe un élément du XML. La tentation est de modifier cet élément et de relancer le contrôle. Il faut y résister : dans une facture hybride, la page PDF et le XML incorporé sont censés dire la même chose, et un XML retouché à la main ne correspond plus à la page qui l’accompagne. Cette contradiction est pire que l’erreur d’origine et bien plus difficile à repérer ensuite.

Corrigez les données dans le système qui a produit la facture — le numéro de TVA dans le profil de l’entreprise, l’étape d’arrondi dans l’outil de facturation, la ligne manquante — puis régénérez le document. La marche à suivre complète figure dans comment vérifier une facture.

Contre quel jeu de règles votre fichier a-t-il été mesuré ?

Trois numéros de version se croisent dans un même contrôle, et ils ne désignent pas la même chose :

• La version du format. Factur-X 1.09.2 / ZUGFeRD 2.5.2, publiée le 4 août 2026 et applicable à partir du 1^er septembre 2026 — un corrigendum à la version 2.5 de juin 2026 qui a resserré cohérence, arrondis, ventilation de TVA et règles de validation, principalement dans le profil EXTENDED.
• La version du jeu de règles. Les artefacts Schematron sont versionnés séparément — EN 16931 Schematron v1.3.16 est le jeu correspondant à la version corrigée 2.5.2.
• La version du validateur. Indépendante des deux autres. Mustang, le validateur open source sur lequel s’appuie l’essentiel du secteur, en est à 2.26.0.

Une précision rarement faite : la norme sémantique elle-même a été révisée. Le CEN a approuvé EN 16931-1:2026 en février 2026 et l’a publiée en mai 2026, retirant l’édition de 2017. Les outils n’ont pas encore suivi — les jeux Schematron actuels encodent toujours la sémantique de 2017, et la prise en charge de la nouvelle révision est attendue avec la version prévue à l’automne 2026. Quiconque affirme aujourd’hui valider contre la révision 2026 mérite qu’on lui demande ce qu’il entend exactement par là.

Répertoire des codes : les règles une par une

À partir d'ici, chaque règle est traitée séparément : ce qu'elle contrôle, comment elle échoue en pratique et ce qu'il faut corriger. Chaque entrée possède son propre ancrage — #BR-CO-15, par exemple, mène directement au bon endroit : vous pouvez coller le code de votre rapport à la suite de l'adresse de cette page.

Tous les montants des exemples proviennent d'une même facture, afin que les calculs s'emboîtent :

Totaux et arrondis

Cette famille provoque la majorité des rejets, et presque toujours pour un centime. Les règles forment une chaîne : BT-106 → BT-109 → BT-110 → BT-112 → BT-115. Si un maillon casse, les règles suivantes signalent une erreur à leur tour — corrigez la première, pas toutes.

BR-CO-10 — somme des lignes

Somme des montants nets des lignes (BT-106) = Σ montant net de la ligne (BT-131).

Dans l'exemple, BT-106 doit valoir exactement 747,00 + 120,50 = 867,50. L'échec vient le plus souvent d'un montant de ligne issu de quantité × prix unitaire qui tombe à plus de deux décimales, le logiciel n'arrondissant qu'au total : 3 × 82,99 font 248,97, pas 249,00. Arrondissez chaque ligne d'abord, additionnez ensuite — jamais l'inverse.

BR-CO-13 — total hors taxes

Total hors TVA (BT-109) = Σ montants nets des lignes (BT-131) − remises au niveau du document (BT-107) + frais au niveau du document (BT-108).

867,50 − 17,50 + 0,00 = 850,00. Cause la plus fréquente : une remise déjà intégrée dans les prix des lignes et déclarée en plus au niveau du document, donc déduite deux fois. Une remise se place soit dans les lignes, soit au niveau du document, jamais dans les deux.

BR-CO-14 — total de TVA

Montant total de TVA (BT-110) = Σ montant de TVA par catégorie (BT-117).

Avec un seul taux, c'est trivial. Les erreurs commencent dès que deux taux coexistent : 20 % et 5,5 % produisent deux lignes dans la ventilation de TVA, et BT-110 doit être la somme des deux — pas le montant de la plus grosse ligne, ni la taxe calculée sur le total général.

BR-CO-15 — total TTC

Total TTC (BT-112) = total hors TVA (BT-109) + montant total de TVA (BT-110).

850,00 + 161,50 = 1011,50. C'est le code que l'on rencontre le plus souvent, et derrière lui il n'y a presque jamais une erreur de calcul mais un arrondi : l'application travaille en interne avec 849,995, écrit 850,00 dans le XML et calcule la taxe sur la valeur non arrondie. Un centime d'écart, et la facture est invalide. Ce qui est écrit dans le XML doit être la base réelle de la facture.

BR-CO-16 — montant dû

Montant dû (BT-115) = total TTC (BT-112) − montant déjà payé (BT-113) + montant d'arrondi (BT-114).

1011,50 − 200,00 = 811,50. Erreur typique sur les factures d'acompte : l'acompte figure dans le texte libre des conditions de paiement au lieu de BT-113, et le montant dû ne correspond alors à rien. Ce que le destinataire doit virer se met dans un champ, pas dans une phrase.

BR-CO-17 — taxe par catégorie

Montant de TVA par catégorie (BT-117) = base d'imposition (BT-116) × taux (BT-119) / 100, arrondi à deux décimales.

850,00 × 19 / 100 = 161,50. L'arrondi fait partie de la règle — arrondi commercial à deux décimales, pas troncature. Réduire 161,495 à 161,49 fait échouer la facture.

BR-DEC-* — deux décimales au maximum

Par exemple BR-DEC-12 pour le total hors TVA (BT-109), BR-DEC-14 pour le total TTC (BT-112), BR-DEC-19 pour la base d'imposition (BT-116).

Plus de vingt règles de cette famille disent la même chose à propos d'un champ monétaire chacune : au-delà de deux décimales, c'est refusé. Un seul 850.0000 issu d'un export de base de données suffit. À ne pas confondre avec les champs de quantité et de prix unitaire, où davantage de décimales sont admises — d'où le fait que seuls les champs de totaux sont touchés.

TVA par catégorie

Chaque ligne porte un code de catégorie de TVA, et chacun de ces codes possède sa propre famille de règles. La famille que vous voyez dans votre rapport vous dit donc déjà quelle catégorie a été utilisée : S taux normal, Z taux zéro, E exonéré, AE autoliquidation, K livraison intracommunautaire, G exportation, O hors champ.

BR-S-01 — catégorie absente de la ventilation

Si la facture contient une ligne, une remise ou des frais avec la catégorie « Standard rated », la ventilation de TVA doit contenir au moins une ligne de la même catégorie.

La ligne dit « 20 % », mais la ventilation de TVA en tête de facture ignore cette catégorie. Cela survient régulièrement lorsqu'une ligne est ajoutée après coup sans recalcul de la ventilation. La même règle existe dans chaque famille : BR-Z-01, BR-E-01, BR-AE-01 et ainsi de suite.

BR-S-02 — pas de numéro fiscal au taux normal

Une facture comportant une ligne « Standard rated » doit porter le numéro de TVA du vendeur (BT-31), son identifiant fiscal (BT-32) et/ou celui d'un représentant fiscal (BT-63).

Qui facture de la TVA doit dire sous quel numéro. Fréquent chez les micro-entreprises qui choisissent par erreur le taux normal au lieu de la catégorie E — la facture est alors fausse non seulement sur la forme, mais aussi fiscalement.

BR-S-08 — base d'imposition par taux

Pour chaque taux : base d'imposition (BT-116) = Σ montants nets des lignes à ce taux + frais − remises à ce taux.

Le cas classique à deux taux : une remise au niveau du document est affectée en totalité à la ligne 20 % alors qu'elle devrait être répartie proportionnellement entre 20 % et 5,5 %. Une remise au niveau du document porte elle-même une catégorie — elle doit être renseignée, et en cas de taux mixtes, il faut la ventiler.

BR-S-09 — taxe par taux

Le montant de taxe de la ligne de ventilation (BT-117) doit être égal à la base (BT-116) multipliée par le taux (BT-119).

Presque identique à BR-CO-17, mais au niveau de la ligne. Si vous voyez les deux, la faute se trouve dans cette ligne.

BR-Z-01 et BR-Z-08 — taux zéro

Exactement une ligne « Zero rated », dont la base doit être égale à la somme des lignes à taux zéro.

Taux zéro signifie : imposable à 0 %. À ne pas confondre avec exonéré (E), ni avec « hors champ » (O). Cette confusion est la première raison d'apparition de cette famille.

BR-E-10 — exonération sans motif

Une ligne « Exempt from VAT » doit porter un motif d'exonération — sous forme de code (BT-121) ou de texte (BT-120).

Vous pouvez facturer sans TVA, mais vous devez indiquer pourquoi. Un champ vide ne suffit pas, un tiret non plus. Pour la franchise en base de TVA, la mention correspondante se place ici.

BR-AE-10 — autoliquidation sans mention

Une ligne « Reverse charge » doit porter un motif signifiant autoliquidation — code (BT-121) ou texte (BT-120).

La mention du transfert de la dette fiscale au preneur n'est pas une politesse, c'est une mention obligatoire. Elle peut être rédigée dans votre langue, mais elle doit exister. S'il manque en plus le numéro de TVA de l'acheteur, vous verrez également BR-AE-02 ou BR-AE-03.

BR-AE-08 et BR-E-08 — base d'imposition à 0 %

Même sans taxe, la base de la ligne doit être égale à la somme des lignes concernées.

Le montant de taxe vaut ici 0,00 — la base, non. Mettre les deux champs à zéro fait échouer la facture : la somme des lignes va telle quelle dans BT-116.

BR-IC-11 — livraison intracommunautaire sans date

Avec la catégorie « Intra-community supply », ni la date de livraison effective (BT-72) ni la période de facturation (BG-14) ne peuvent être vides.

Sur une livraison exonérée vers un autre pays de l'UE, le destinataire doit savoir quand la livraison a eu lieu — la date de facture ne suffit pas. L'un des deux champs suffit.

BR-O-11 — « hors champ » ne se mélange à rien

Une facture contenant une ligne de ventilation « Not subject to VAT » ne doit contenir aucune autre ligne de ventilation.

Cette catégorie exclut toutes les autres : une facture est soit entièrement hors champ, soit pas du tout. Cela arrive quand un poste refacturé à l'identique — un débours, une taxe avancée — est marqué O alors que le reste est taxé normalement. De tels postes ne relèvent pas de la même facture.

Mentions obligatoires

Ces règles attrapent les fichiers où il manque simplement quelque chose. Elles sont rares quand la facture sort d'un logiciel, fréquentes quand le XML a été écrit à la main ou à partir d'un modèle.

BR-01 — identifiant de spécification

Une facture doit comporter un Specification identifier (BT-24).

C'est la chaîne qui indique selon quel profil le fichier a été construit — urn:cen.eu:en16931:2017 par exemple. Sans elle, le validateur ne sait pas contre quoi contrôler et le destinataire ne sait pas ce qu'il a reçu. En pratique, elle ne manque que dans un XML écrit à la main.

BR-02 à BR-05 — numéro, date, type, devise

Numéro de facture (BT-1), date d'émission (BT-2), code de type de facture (BT-3) et code devise (BT-5) doivent être présents.

Quatre règles distinctes pour quatre champs d'en-tête. Le type est un code de la liste UNTDID 1001 — 380 pour une facture ordinaire, 381 pour un avoir ; un texte libre à cet endroit déclenche en plus un message BR-CL-*.

BR-06 à BR-09 — vendeur et acheteur

Nom du vendeur (BT-27), nom de l'acheteur (BT-44), adresse postale du vendeur (BG-5) et, à l'intérieur, le code pays (BT-40).

BR-09 est le plus fréquent des quatre : la rue et la ville sont renseignées, le code pays non. Il doit s'agir d'un code ISO 3166-1 à deux lettres — FR, pas France.

BR-16 — aucune ligne

Une facture doit comporter au moins une ligne (BG-25).

Cela se produit quand la facture ne contient que des totaux — par exemple dans un fichier généré depuis un PDF dont le tableau des lignes n'a pas été reconnu. Une ligne globale portant le montant total vaut mieux qu'aucune.

BR-CO-09 — préfixe pays du numéro de TVA

Le numéro de TVA du vendeur (BT-31), celui du représentant fiscal (BT-63) et celui de l'acheteur (BT-48) doivent commencer par un code pays ISO 3166-1 alpha-2. La Grèce peut en outre utiliser EL.

123456789 devient FR12123456789. Cas de loin le plus courant : le numéro figure sans préfixe dans les données de base parce qu'il y est tenu ainsi depuis des années. Les espaces et les points n'y ont pas leur place non plus.

BR-CO-26 — vendeur non identifiable

Pour que l'acheteur puisse identifier automatiquement le fournisseur, l'identifiant du vendeur (BT-29), son identifiant d'immatriculation légale (BT-30) et/ou son numéro de TVA (BT-31) doivent être présents.

Au moins l'un des trois, pas tous. Déclencheur le plus courant sur les factures tierces converties : le PDF affiche un identifiant fiscal national dans un format qui n'est pas un numéro de TVA, si bien qu'il n'atterrit dans aucun des trois champs. Mieux vaut alors renseigner le numéro d'immatriculation que laisser les trois vides.

L'extension allemande (BR-DE-*)

Les règles BR-DE-* ne viennent pas de l'EN 16931 elle-même mais de XRechnung, le CIUS allemand. Elles exigent des mentions que la norme laisse facultatives. Important pour lire votre rapport : une facture ZUGFeRD qui ne prétend pas être une XRechnung n'a pas à les respecter — le validateur les signale quand même, parce qu'il applique tous les jeux de règles qu'il connaît. Il en va exactement de même des règles françaises BR-FR-* pour une facture qui n'est pas émise selon le profil français.

BR-DE-1 — pas d'instructions de paiement

Une facture doit contenir des PAYMENT INSTRUCTIONS (BG-16).

Pas de moyen de paiement, pas de XRechnung. Pour un virement, cela suppose l'IBAN et le code du moyen de paiement ; pour un prélèvement ou un paiement comptant, le code correspondant.

BR-DE-2, BR-DE-5 à BR-DE-7 — coordonnées de contact

Le groupe SELLER CONTACT (BG-6) doit être transmis, et à l'intérieur le point de contact (BT-41), le numéro de téléphone (BT-42) et l'adresse e-mail (BT-43).

Quatre règles, un seul bloc. Une adresse générique du type facturation@… convient, un nom de service également — il suffit que ce soit rempli. Si le bloc manque entièrement, les quatre messages apparaissent d'un coup.

BR-DE-14 — taux de TVA manquant

L'élément VAT category rate (BT-119) doit être transmis.

L'EN 16931 autorise à omettre le taux pour certaines catégories ; XRechnung non. Sur les lignes exonérées, il faut inscrire explicitement 0, et non rien.

BR-DE-15 — référence acheteur manquante

L'élément Buyer reference (BT-10) doit être transmis.

Dans les marchés publics allemands, il s'agit du Leitweg-ID : l'identifiant de routage grâce auquel le portail de réception reconnaît à quel service la facture est destinée. Il figure dans la commande ou le contrat ; il ne s'invente pas, et sans lui la facture n'est pas distribuée. Dans le privé, n'importe quelle référence acheteur convient.

BR-DE-16 — identification fiscale pour presque toutes les catégories

Si les codes de taxe S, Z, E, AE, K, G, L ou M sont utilisés, au moins l'un des éléments numéro de TVA du vendeur (BT-31), identifiant fiscal (BT-32) ou SELLER TAX REPRESENTATIVE PARTY (BG-11) doit être transmis.

Le durcissement allemand de BR-S-02 : la règle ne vaut pas seulement pour le taux normal, mais pour pratiquement toutes les catégories.

BR-DE-17 — type de facture non autorisé

Pour Invoice type code (BT-3), seuls 326 (facture partielle), 380 (facture), 384 (facture rectificative), 389 (autofacturation) et 381 (avoir) sont admis.

La liste UNTDID compte des dizaines de valeurs ; XRechnung en autorise cinq. Marquer une facture pro forma 325 échoue ici.

BR-DE-18 — escompte au mauvais format

L'escompte doit suivre un motif fixe dans Payment terms (BT-20) : #SKONTO#TAGE=n#PROZENT=n.nn#.

La seule règle qui impose une syntaxe à un champ de texte libre. « 2 % d'escompte sous 14 jours » se lit très bien et reste invalide — le destinataire doit pouvoir l'exploiter automatiquement.

BR-DE-19 — IBAN invraisemblable

Si le moyen de paiement est le virement SEPA (code 58), Payment account identifier (BT-84) doit contenir un IBAN correct.

Longueur, code pays et clé de contrôle sont vérifiés. En pratique, l'échec vient le plus souvent des espaces : FR14 2004 1010 0505 0001 3M02 606 est juste pour un humain et faux pour le contrôle — le XML attend l'IBAN sans séparateurs. BR-DE-20 dit la même chose du prélèvement (code 59).

BR-DE-21 — le message que presque tout le monde voit

L'élément Specification identifier (BT-24) doit correspondre syntaxiquement à l'identifiant du standard XRechnung.

Ce message apparaît sur chaque facture ZUGFeRD et Factur-X valide, et il n'y constitue pas une erreur. Il dit simplement : « ce n'est pas une XRechnung. » Ce qui est exact — et exactement ce que vous voulez si vous émettez du Factur-X. Retranchez ce message avant de juger votre rapport ; notre propre rapport le fait déjà pour vous.

BR-DE-26 — rectification sans référence

Si le type de facture 384 (facture rectificative) est utilisé, au moins une PRECEDING INVOICE REFERENCE (BG-3) doit être présente.

Une rectification qui ne dit pas ce qu'elle rectifie n'est pas rattachable. Le numéro et la date de la facture d'origine se mettent dans BG-3, pas dans un texte libre.

Lire son propre rapport

Le plus rapide pour comprendre une règle est de la voir se déclencher sur un fichier que l’on connaît. Déposez une facture dans notre validateur — gratuit et sans limite de nombre, il exécute les jeux Schematron décrits ici et renvoie chaque constat avec son code de règle, sa sévérité et son emplacement. Ce qui se passe à chacune des trois couches est décrit dans comment fonctionne la validation.