BR-CO-17 est une erreur de cohérence TVA. Elle apparaît quand le montant de TVA déclaré pour une catégorie ne correspond pas au calcul attendu à partir de la base taxable et du taux.
Dans les ERP, la cause est souvent un décalage d’arrondi : calcul ligne par ligne, calcul global, ventilation par catégorie, ou montant ajusté manuellement.
Réponse courte
Pour chaque catégorie TVA, EN16931 attend une cohérence entre :
| Business Term | Sens |
|---|---|
BT-116 | base taxable de la catégorie |
BT-117 | montant TVA de la catégorie |
BT-119 | taux TVA de la catégorie |
La logique attendue est :
BT-117 ≈ BT-116 × BT-119 / 100
Si votre ERP calcule la TVA à un autre niveau d’agrégation, vous pouvez produire un écart d’un centime qui déclenche BR-CO-17.
Exemple simple
Base taxable :
<ram:BasisAmount>99.99</ram:BasisAmount>
<ram:CalculatedAmount>20.01</ram:CalculatedAmount>
<ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>
Calcul attendu :
99.99 × 20 / 100 = 19.998 → 20.00
Le XML déclare 20.01. Le validateur peut déclencher BR-CO-17.
Correction :
<ram:BasisAmount>99.99</ram:BasisAmount>
<ram:CalculatedAmount>20.00</ram:CalculatedAmount>
<ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>
Où se trouve l’erreur dans CII
La ventilation TVA se trouve dans ApplicableTradeTax au niveau du règlement.
XPath simplifié :
rsm:CrossIndustryInvoice
/rsm:SupplyChainTradeTransaction
/ram:ApplicableHeaderTradeSettlement
/ram:ApplicableTradeTax
Champs concernés :
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>20.00</ram:CalculatedAmount>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:BasisAmount>99.99</ram:BasisAmount>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
Les 4 causes les plus fréquentes
1. TVA calculée globalement au lieu d’être ventilée par catégorie
Si une facture contient plusieurs catégories TVA, le total global ne suffit pas. Il faut une ventilation par catégorie avec base, taux et montant TVA cohérents.
Erreur typique :
- lignes à 20% et lignes exonérées ;
- une seule base taxable globale ;
- un seul montant TVA ;
- catégories mal séparées.
2. Arrondi ligne vs arrondi catégorie
Deux stratégies peuvent produire un écart :
Stratégie A : calculer TVA ligne par ligne puis sommer
Stratégie B : sommer les bases puis calculer la TVA sur la catégorie
Selon les montants, A et B peuvent différer d’un centime. Le XML doit rester cohérent avec la stratégie attendue par les règles appliquées et avec les montants déclarés.
3. Remise document mal rattachée à la catégorie TVA
Une remise au niveau document doit être rattachée à une catégorie TVA. Si elle réduit le total HT mais pas la base taxable de la catégorie, BT-116 devient incohérent avec les lignes.
Cela peut déclencher BR-CO-17, mais aussi BR-S-08 ou les équivalents selon la catégorie.
4. Ajustement manuel du total TVA
Certains ERP autorisent une correction manuelle du total TVA pour coller à une facture historique ou à un arrondi commercial. Cette correction doit aussi être répercutée dans la ventilation, sinon le XML devient contradictoire.
Comment diagnostiquer
Pour chaque catégorie TVA :
- Lister les lignes de cette catégorie.
- Additionner les bases HT de ces lignes.
- Ajouter les charges document de même catégorie.
- Soustraire les remises document de même catégorie.
- Comparer au
BT-116. - Calculer
BT-116 × BT-119 / 100. - Comparer au
BT-117.
Table de debug :
| Catégorie | Base attendue | Base XML | Taux | TVA attendue | TVA XML |
|---|---|---|---|---|---|
| S 20% | 99.99 | 99.99 | 20.00 | 20.00 | 20.01 |
| E 0% | 40.00 | 40.00 | 0.00 | 0.00 | 0.00 |
Dans cet exemple, l’erreur est sur le montant TVA de la catégorie S.
Correction côté ERP
La correction durable se fait dans le moteur de calcul ou le mapping XML.
Pseudo-code :
type VatBucket = {
category: string
rate: number
taxableBase: Decimal
}
function computeVatAmount(bucket: VatBucket): Decimal {
return bucket.taxableBase
.mul(bucket.rate)
.div(100)
.toDecimalPlaces(2)
}
Puis le XML doit reprendre exactement ces valeurs :
const vatAmount = computeVatAmount(bucket)
writeCiiApplicableTradeTax({
basisAmount: bucket.taxableBase,
calculatedAmount: vatAmount,
categoryCode: bucket.category,
rateApplicablePercent: bucket.rate,
})
Ne calculez pas CalculatedAmount à partir d’un total global si BasisAmount vient d’une ventilation différente.
Peut-on réparer automatiquement ?
Par prudence, BR-CO-17 est rarement une bonne correction automatique sans contexte. Changer un montant TVA change une valeur financière.
Un moteur peut proposer :
- le montant attendu ;
- la catégorie concernée ;
- l’écart ;
- les lignes impliquées si elles sont lisibles ;
- une suggestion de correction.
Mais l’application automatique doit être réservée à des cas où votre système source confirme la stratégie d’arrondi.
Erreurs liées
- BR-CO-14 — Total TVA = somme des catégories
- BR-CO-15 — Total facture TTC
- BR-S-05 — TVA Standard : taux obligatoire
- Confusion catégorie TVA : S, Z, E, AE, G, K
- Catalogue des erreurs BR-* EN16931
Continuer la lecture
Articles liés
BR-CL-23 : corriger les codes unités UN/ECE dans une facture Factur-X
Pourquoi l'erreur BR-CL-23 apparaît dans un XML CII Factur-X, comment mapper les unités ERP vers les codes UN/ECE Rec 20 et comment éviter les libellés libres.
Lire l’article →Valider EN16931 / Factur-X en pratique : XSD vs Schematron, erreurs BR-*, workflow de debug
Comment fonctionne réellement la validation d'une facture électronique EN16931, pourquoi un XML valide en XSD peut échouer en Schematron, et comment déboguer les erreurs BR-* étape par étape.
Lire l’article →BR-05 — Le code devise de la facture (BT-5) est obligatoire
BR-05 impose la présence d'InvoiceCurrencyCode (BT-5) à l'ApplicableHeaderTradeSettlement. Code ISO 4217 alpha-3 sur 3 lettres.
Lire l’article →Étape suivante recommandée
Vous voulez retrouver la catégorie TVA qui déclenche BR-CO-17 ?
Voici ce que vous allez obtenir :
- Montants de base et TVA extraits
- Catégorie TVA concernée
- Écart d'arrondi visible
- Lien vers les erreurs BR-CO liées