Erreur BR-CO-16 EN16931 : BT-115 ≠ BT-112 − BT-113 + BT-114 — acomptes, arrondis

En bref

• BR-CO-16 contrôle que BT-115 (Amount due for payment) = BT-112 − BT-113 + BT-114.
• BT-113 (TotalPrepaidAmount, acomptes) et BT-114 (RoundingAmount, arrondi) ont une cardinalité 0..1 — optionnels.
• Erreur classique : l’ERP déduit l’acompte du total mais ne l’expose pas dans BT-113.
• Si ces deux champs sont absents, l’égalité devient simplement BT-115 = BT-112.
• Corrigez les montants à partir des données métier dans l’ERP ; /repair ne recalcule pas les totaux.

Ce que l’erreur veut dire

BR-CO-16 (Schematron EN16931, aligné Peppol) impose que DuePayableAmount (BT-115, montant à payer) soit strictement égal à GrandTotalAmount (BT-112) moins TotalPrepaidAmount (BT-113) plus RoundingAmount (BT-114). BT-113 et BT-114 ont une cardinalité 0..1 — ils ne sont PAS obligatoires. S’ils sont absents, l’égalité se réduit à BT-115 = BT-112.

Quand cette erreur arrive

Survient quand : (a) un acompte est appliqué mais TotalPrepaidAmount reste vide ; (b) RoundingAmount ajuste le total mais n’est pas reflété dans BT-115 ; (c) BT-115 est absent alors qu’il est obligatoire (règle BR-15) ; (d) arithmétique simple mal propagée entre l’ERP et l’export XML.

Exemple XML qui déclenche l’erreur

Fragments pédagogiques du bloc de totaux CII : ils illustrent cette égalité et ne constituent pas une facture complète validée.

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>
  <ram:DuePayableAmount>1000.00</ram:DuePayableAmount>  <!-- ❌ acompte non déclaré -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Exemple XML corrigé

Dans cet exemple, les données comptables confirment un paiement déjà reçu de 200,00 EUR. La différence entre TTC et montant dû ne suffit pas à prouver qu’un paiement a eu lieu.

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>
  <ram:TotalPrepaidAmount>200.00</ram:TotalPrepaidAmount>
  <ram:DuePayableAmount>1000.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Correction manuelle

Lorsque le montant déjà payé est porté en BT-113, renseignez <ram:TotalPrepaidAmount> à partir des paiements réellement reçus et calculez DuePayableAmount selon la formule. Ne déduisez pas une seconde fois un acompte déjà repris dans les lignes ; une retenue non réglée ne constitue pas un paiement reçu. Si aucun acompte ni arrondi de paiement, BT-115 = BT-112 — ne pas ajouter des TotalPrepaidAmount=0.00 et RoundingAmount=0.00 artificiels (ils sont optionnels).

Réparable automatiquement par /repair ?

Pas par recalcul du montant dû. Le contrat public de /repair couvre des corrections déterministes de format ; il ne recalcule ni TVA ni totaux métier et n’invente pas de paiement reçu. Corrigez l’export à partir de l’ERP, puis validez le document régénéré. Le contrôle documentaire ne garantit pas l’acceptation par une PA.

Et maintenant ?

Pour le calcul, le binding CII EN16931 emploie RoundingAmount pour BT-114. Le nom UBL correspondant est PayableRoundingAmount : ne mélangez pas les deux syntaxes. Pour les capacités produit, consultez le contrat public de l’API.

Pour diagnostiquer votre facture :

Après correction dans le système source, contrôler le XML sans le modifier :

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@./facture.xml"

Voir aussi

• Catalogue complet des erreurs BR-* EN16931
• Comprendre les messages Schematron EN16931
• Corriger automatiquement les erreurs réparables
• Erreur BR-15 — Montant à payer (BT-115) obligatoire