Technique

Erreur BT-84 EN16931 : compte bancaire — IBANID vs ProprietaryID — BR-50 BR-61

3 min de lecture Par FacturX API

BT-84 (Payment account identifier) en CII utilise ram:IBANID ou ram:ProprietaryID, jamais schemeID. BR-50 et BR-61 contrôlent la présence conditionnelle de BT-84.

En bref

  • BT-84 (Payment account identifier) en CII n’utilise PAS schemeID — il passe par ram:IBANID ou ram:ProprietaryID.
  • Règle BR-50 : BT-84 est obligatoire dès lors qu’un bloc BG-17 (Credit Transfer) est présent dans la facture.
  • Règle BR-61 : BT-84 est obligatoire quand BT-81 (Payment means type code) vaut 30 (virement), 58 (SEPA credit transfer) ou 42 (virement local).
  • Si c’est un IBAN (CC + 2 chiffres contrôle + BBAN selon ISO 13616) : utiliser <ram:IBANID>. Sinon : <ram:ProprietaryID>.
  • Réparable automatiquement par /repair quand le format du compte est reconnaissable.

Ce que l’erreur veut dire

En CII (Factur-X), BT-84 s’expose dans PayeePartyCreditorFinancialAccount via deux éléments distincts : ram:IBANID (pour un IBAN ISO 13616 valide) ou ram:ProprietaryID (pour les comptes non-IBAN : comptes US avec ABA/routing, BBAN brut de certaines juridictions, etc.). Ces deux éléments ont chacun une cardinalité 0..1 — ils ne sont pas strictement exclusifs au niveau du schéma XML, mais leur cumul n’a pas de sens sémantique et doit être évité. Les règles EN16931 associées sont BR-50 (présence obligatoire de BT-84 dès qu’un BG-17 Credit Transfer est présent) et BR-61 (présence obligatoire de BT-84 quand BT-81 vaut 30, 58 ou 42). Attention : il ne faut PAS tenter d’exposer l’IBAN via GlobalID avec schemeID="IBAN" — ce mécanisme est destiné aux identifiants d’organisation (BT-29, BT-30), pas aux comptes bancaires.

Quand cette erreur arrive

Survient quand : (a) IBAN placé à tort dans GlobalID avec schemeID="IBAN" au lieu de IBANID (confusion fréquente en migration UBL → CII) ; (b) compte bancaire omis alors qu’un PaymentMeansTypeCode vaut 30 / 58 / 42 → viole BR-61 ; (c) IBAN mal formé (espaces tous les 4 caractères, tirets, clé MOD-97 invalide) ; (d) compte non-IBAN (US, certains comptes canadiens) placé dans IBANID au lieu de ProprietaryID.

Exemple XML qui déclenche l’erreur

<ram:PayeePartyCreditorFinancialAccount>
  <ram:GlobalID schemeID="IBAN">FR76 3000 4000 0312 3456 7890 143</ram:GlobalID>  <!-- ❌ mauvais élément + espaces -->
</ram:PayeePartyCreditorFinancialAccount>

Exemple XML corrigé

<ram:PayeePartyCreditorFinancialAccount>
  <ram:IBANID>FR7630004000031234567890143</ram:IBANID>
</ram:PayeePartyCreditorFinancialAccount>

Correction manuelle

Exposer l’IBAN via <ram:IBANID> sans espaces ni séparateurs : iban.replace(/\s/g, '').toUpperCase(), puis valider la clé MOD-97. Pour un compte hors zone IBAN (US, certains comptes hors SEPA), utiliser <ram:ProprietaryID>. Ne pas cumuler IBANID et ProprietaryID dans le même PayeePartyCreditorFinancialAccount — un seul des deux, selon la nature du compte. Si le document déclare un virement (BT-81 = 30/58/42) ou un bloc BG-17, la présence de BT-84 est obligatoire (BR-50 / BR-61).

Réparable automatiquement par /repair ?

Oui, sous conditions — l’endpoint /repair corrige automatiquement cette erreur quand les données structurées sont récupérables. Dans les cas ambigus, une décision humaine reste nécessaire.

Et maintenant ?

Réparer mon Factur-X →

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

Voir aussi

#en16931 #schematron #factur-x #erreurs #validation