Erreur BR-CO-15 dans un Factur-X : comment la corriger

Sur les factures électroniques au format Factur-X, une règle de coherence revient plus souvent que toutes les autres dans les rapports d'erreur : BR-CO-15. Elle compare la somme des montants nets de ligne au total HT du document. Quand le validateur la signale, le problème est presque toujours un arrondi de centime côté émetteur, rarement une donnee manquante. Cet article explique ce que dit exactement la règle, pourquoi elle saute si facilement, comment notre validateur l'affiche, et la procédure pour la corriger sans toucher au reste de la facture.

Ce que dit la règle exactement

BR-CO-15 fait partie des business rules de la norme européenne EN 16931, reprises telles quelles dans le profil EN 16931 de Factur-X (ainsi que dans les profils EXTENDED et BASIC, avec quelques nuances). Sa formulation officielle, publiee par le CEN, est la suivante : Invoice total amount without VAT (BT-109) = ∑Invoice line net amount (BT-131) + Sum of charges on document level (BT-108) − Sum of allowances on document level (BT-107).

En pratique, cela signifie que le total HT déclaré au niveau du document doit être egal, au centime près, a la somme des montants nets de chaque ligne, ajustee des remises et majorations globales eventuelles. Le validateur applique une tolerance de0,01 EUR pour absorber l'arrondi final, mais pas davantage.

Les codes de champ impliques :

Une règle voisine, BR-CO-10, exige que BT-106 soit rigoureusement egale a la somme des BT-131. Autrement dit, BR-CO-10 vérifié la construction de BT-106, et BR-CO-15 vérifié la coherence entre BT-106, les ajustements document et BT-109. Les deux sautent souvent ensemble, mais la cause racine se trouve presque toujours dans la ligne.

Pourquoi elle saute le plus souvent

Trois causes concentrent la grande majorite des occurrences observees sur les factures émises au profil EN 16931 et BASIC.

Arrondi flottant côté émetteur

Le scenario classique : un ERP calcule le montant net de ligne en interne avec deux decimales, puis recalcule le total HT a partir des mêmes lignes mais en utilisant les montants avant arrondi. La différence entre les deux méthodes est de l'ordre de quelques centimes sur une facture a plusieurs lignes. Exemple concret :

Si l'ERP injecte dans BT-109 la somme des montants theoriques arrondie une seule fois (81,94), alors que la somme des BT-131 exportes vaut 81,95, l'ecart d'un centime déclenché BR-CO-15. La règle est intransigeante : le total document doit reconcilier la somme des valeurs effectivement publiees, pas la somme des calculs internes a précision plus elevee.

Lignes oubliees ou dupliquees

Plus rare mais plus grave : une ligne présente dans l'export PDF (la représentation visuelle) est absente du XML embarque, ou inversement. L'ecart est alors significatif, souvent supérieur a quelques dizaines d'euros. La cause est generalement un filtre applique a l'export XML (lignes a quantite nulle, frais techniques, lignes de remise traitees comme une ligne negative dans le PDF mais comme un AllowanceChargedocument dans le XML). Notre extracteur permet de comparer le XML embarque a la représentation PDF en quelques secondes.

Devise inconsistante ou conversion implicite

Si la facture est libellee en une devise (EUR) mais que certaines lignes contiennent un attribut currencyID différent, le calcul total côté validateur agrege des montants heterogenes et echoue. Ce cas est rare en France mais classique sur les factures intra-UE ou export. Le diagnostic est immediat : BT-5 (devise du document) et chaque montant doivent être coherents. BR-CO-15 ne convertit aucune devise.

Comment notre validateur l'affiche

Quand le pipeline détecté une violation de BR-CO-15, le rapport renvoye par /valider contient une entree de la forme suivante, normalisée quel que soit le profil :

{
  "code": "BR-CO-15",
  "severity": "error",
  "field": "BT-109",
  "expected": 81.94,
  "actual": 81.95,
  "delta": 0.01,
  "tolerance": 0.01,
  "message": "Sum of BT-131 (81.95) does not match BT-109 (81.94) within tolerance"
}

Quelques précisions sur la lecture du rapport :

• severity est toujours error pour BR-CO-15. La règle n'a pas de variante warning dans la norme EN 16931.
• delta exprime l'ecart absolu observe en EUR. Au-dessus de 0,01 la violation est levee. Un delta supérieur a 1 EUR pointe presque toujours vers une ligne manquante, pas vers un arrondi.
• field indique le champ porteur de l'erreur (BT-109 pour BR-CO-15), ce qui aide a localiser le nœud XML a corriger. Le validateur signale en parallele le nœud parent ApplicableHeaderTradeSettlement.

Si BR-CO-10 est egalement levee, traitez-la en premier : reconcilier les BT-131avec BT-106 resout souvent BR-CO-15 par effet de bord.

Etapes pour fixer côté émetteur

La correction se fait dans le système qui généré le XML, pas dans le PDF visuel. Les pages de notre générateur appliquent les règles ci-dessous par defaut ; si vous emettez via un ERP tiers, voici la procédure recommandée.

1. Arrondir au plus tôt, une seule fois par ligne. Calculer le net de ligne avec la formule round(quantite × prix_unitaire − remise_ligne, 2)en arrondi commercial (HALF_UP). Stocker cette valeur dans BT-131 et l'utiliser pour tous les calculs en aval.
2. Construire BT-106 par sommation simple.BT-106 = somme(BT-131). Aucune arithmetique flottante intermédiaire, aucune requalification.
3. Appliquer remises et majorations au niveau document.BT-109 = BT-106 + BT-108 − BT-107. Ces deux derniers sont eux-mêmes arrondis a deux decimales avant injection.
4. Vérifier la coherence des arrondis de TVA. BR-CO-15 ne couvre que le total HT, mais une violation de BR-CO-13 (total TTC) suit souvent. RecalculerBT-112 a partir de BT-109 et BT-110, pas via une troisième méthode.
5. Republier et revalider. Un nouveau passage dans le validateur doit renvoyer un rapport vide pour la catégorie totaux. Si BR-CO-15 reapparait, l'ERP conserve un calcul parallele non aligne.

Pour les émetteurs qui generent leurs Factur-X via une bibliothèque, il est utile de vérifier que la classe responsable du SpecifiedTradeSettlementHeaderMonetarySummationutilisé les valeurs déjà arrondies des lignes, et non un recalcul. C'est la source la plus fréquente d'ecarts d'un centime dans les profils EN 16931 et BASIC.

Règles cousines : BR-CO-10, BR-CO-13, BR-CO-16, BR-CO-17

BR-CO-15 fait partie d'une famille de règles arithmetiques qui s'enchainent. Un rapport propre suppose qu'elles soient toutes vertes.

Si BR-CO-15 saute isolement, le problème est un arrondi. Si elle saute avec BR-CO-16, le problème est un acompte mal déclaré. Si elle saute avec BR-CO-17, le problème est une repartition des taux de TVA incorrecte. Le validateur affiche ces dependances dans l'ordre canonique, ce qui permet de remonter au champ source en quelques minutes.

Ce qu'il faut retenir

• BR-CO-15 vérifié que BT-109 = somme des BT-131 + BT-108 − BT-107, avec une tolerance de 0,01 EUR.
• Cause numéro un : un ERP qui recalcule le total a partir de montants non arrondis. La parade est d'arrondir une seule fois, au niveau ligne, et de sommer ensuite.
• Un delta supérieur a 1 EUR n'est pas un problème d'arrondi : cherchez une ligne manquante ou un AllowanceCharge mal classe.
• BR-CO-10, BR-CO-13, BR-CO-16 et BR-CO-17 forment la même famille : traitez-les ensemble.

Pour comprendre comment le profil de la facture influe sur les champs disponibles côté totaux, voir le profil MINIMUM et ses 18 champs et les différences entre profils Factur-X. Si vous redigez des Factur-X de zero, le générateur applique les règles d'arrondi de l'EN 16931 par defaut, sans configuration.