Réconcilier des paiements multi-pays. 7 chapitres et un QCM final.

Chapitre 1. Un pivot unique, deux relevés : camt.053 et BAI2.

Une entreprise présente dans dix pays ne reçoit pas dix relevés comparables. Elle reçoit du XML ISO 20022 de sa banque allemande, du BAI2 de sa banque américaine, du CNAB 240 de sa banque brésilienne, du CFONB120 de sa banque française. Quatre grammaires pour dire qu'un compte a été crédité. La tentation est d'écrire un moteur de rapprochement par pays, un choix qui, à cinq ans, coûte plus cher que tous les autres. La méthode qui tient sépare deux couches, d'un côté des parseurs propres à chaque format, qui produisent tous le même objet, une écriture pivot, de l'autre un moteur qui ne connaît que ce pivot. Ajouter un pays revient alors à écrire un parseur, pas à reprendre les règles métier. Voici les champs que ce pivot doit porter.

• Identifiant de compte normalisé, IBAN quand il existe, sinon couple (code banque, numéro de compte) plus le pays
• Devise du compte, en ISO 4217, jamais déduite du pays
• Montant en unité mineure, entier signé : le signe vient d'une règle de format, pas du parseur générique
• Sens explicite (crédit ou débit), redondant avec le signe et vérifié contre lui
• Date de comptabilisation et date de valeur, deux champs distincts, jamais fusionnés
• Code de nature d'origine, conservé tel quel, plus une famille pivot interne (virement reçu, prélèvement, frais, rejet…)
• Référence de la banque, l'identifiant que la banque saura retrouver en cas de litige
• Référence du donneur d'ordre (EndToEndId, référence client, Nosso Número selon le format)
• Libellé brut intégral, non tronqué, non normalisé
• Empreinte du fichier source et numéro de ligne, pour remonter à la preuve en une requête

Le camt.053 est le relevé de fin de journée d'ISO 20022. Sa force tient à trois éléments que les formats à positions ne savent pas porter : une devise attachée à chaque montant, deux dates séparées, une classification normalisée de l'opération. Sa faiblesse tient à sa souplesse, deux banques produisant des camt.053 valides et pourtant différents, parce que chacune choisit ce qu'elle structure vraiment et ce qu'elle laisse en texte libre.

<Ntry>
  <Amt Ccy="EUR">12500.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <BookgDt><Dt>2026-07-10</Dt></BookgDt>
  <ValDt><Dt>2026-07-13</Dt></ValDt>
  <AcctSvcrRef>0004512</AcctSvcrRef>
  <BkTxCd>
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs><EndToEndId>ADYEN-SETTLEMENT-2026-BATCH42</EndToEndId></Refs>
    </TxDtls>
  </NtryDtls>
</Ntry>

• Avec `Amt` et son attribut `Ccy`, la devise appartient au montant, pas au compte. Un compte multi-devises porte des entrées de devises différentes.
• `CdtDbtInd` vaut CRDT ou DBIT. Le montant, lui, reste toujours positif : le convertir en entier signé est le travail du parseur.
• `BookgDt` et `ValDt` portent, dans l'exemple, une comptabilisation le vendredi 10 et une valeur le lundi 13. Trois jours de trésorerie séparent les deux.
• `BkTxCd` porte trois niveaux tirés des listes de codes externes ISO 20022 : domaine PMNT, famille RCDT (virement reçu), sous-famille ESCT. C'est le champ qui permet d'aiguiller une écriture sans lire le libellé.
• `AcctSvcrRef` et `EndToEndId` donnent la référence que la banque retrouvera, et celle que le donneur d'ordre a posée. La seconde est la vraie clé de rapprochement automatique.

# Les lignes commencant par # sont des annotations, absentes du fichier reel.
# 01 en-tete de fichier : emetteur, destinataire, date, heure, id, version 2
01,BANKUS33,ACMECORP,260710,0800,001,,,2/
# 02 en-tete de groupe : date « as-of » de la restitution et devise du groupe
02,ACMECORP,BANKUS33,1,260710,,USD,/
# 03 compte + soldes : type code 010 = solde d'ouverture, en CENTIMES
03,0012345678,USD,010,15234025,,/
# 16 mouvement : type code 142 = credit ACH recu ; funds type Z = disponibilite inconnue
16,142,1250000,Z,0004512,PAYOUT-BATCH-42,ADYEN SETTLEMENT/
# 49 fin de compte : total de controle = somme des montants des 03 et 16, puis nb de lignes
49,16484025,3/
# 98 fin de groupe : total, nombre de comptes, nombre de lignes du groupe
98,16484025,1,5/
# 99 fin de fichier : total, nombre de groupes, nombre de lignes du fichier
99,16484025,1,7/

Chapitre 2. CNAB 240 et CFONB120 : les fichiers à positions.

Le Brésil et la France partagent une famille de formats et rien d'autre, celle des enregistrements de longueur fixe où seule la position compte. Un caractère décalé, et tout le reste de la ligne devient faux sans qu'aucune erreur ne soit levée. Le contrôle d'équilibre du chapitre précédent est ici la seule protection réelle.

Le CNAB 240, dont la version 10.11 date du 21 août 2023, est publié par la FEBRABAN, la fédération des banques brésiliennes, et non par le régulateur. Un fichier porte des enregistrements de 240 positions, organisés en lots, à raison d'un lot par service et par compte payeur. Un même fichier peut donc mélanger un lot de virements et un lot de boletos.

Le fichier qui intéresse la réconciliation est le retorno de cobrança, la restitution que la banque renvoie sur les boletos émis. Deux segments y portent tout ce qu'un comptable cherche. Le segment T identifie le titre et son code de mouvement retour, celui qui dit si le boleto a été payé, rejeté ou radié. Le segment U porte les valeurs.

• Segment T, identification du titre (Nosso Número côté banque, Seu Número côté entreprise), code de mouvement retour, motif d'occurrence, montant de la tarifa bancaire
• Segment U, montant payé, montant net crédité, intérêts et remises appliqués, date de l'occurrence et date de crédit effective
• La date de crédit n'est pas la date de paiement : le payeur règle le boleto un jour, l'argent arrive sur le compte un ou plusieurs jours plus tard
• Le montant payé n'est pas le montant émis : intérêts de retard, remise pour paiement anticipé et tarifa creusent l'écart

CFONB120 : l'overpunch, et ce qu'il implique en multi-pays

Le CFONB120 aligne des enregistrements de 120 caractères : un 01 pour l'ancien solde, des 04 pour les mouvements, des 05 de complément, un 07 pour le nouveau solde. Le dossier d'encyclopédie en donne la cartographie position par position. Un seul point compte pour un moteur multi-pays, le dernier caractère du montant codant à la fois un chiffre et le signe, héritage des cartes perforées. { vaut +0, } vaut −0, A à I valent +1 à +9, J à R valent −1 à −9.

Chapitre 3. Les fichiers d'acquéreur et leurs écarts.

Le relevé bancaire montre une ligne, un virement de l'acquéreur, qui recouvre des milliers de transactions, des remboursements, des impayés et six familles de frais. Le rapport de règlement est la pièce qui explique le passage de l'un à l'autre. Sans lui, la ligne bancaire n'est pas justifiable, et la piste d'audit s'arrête au montant net.

Les grands acquéreurs publient la structure de ces rapports, à commencer par le settlement details report d'Adyen, qui aligne vingt-quatre colonnes, dont Gross Currency, Gross Credit (GC), Exchange Rate, Net Currency et Net Credit (NC). Quatre colonnes y isolent les coûts, Commission, Markup, Scheme Fees et Interchange. Chez Stripe, le rapport Payout reconciliation n'existe que pour les comptes en versement automatique, et le rapport Balance porte les colonnes automatic_payout_id et automatic_payout_effective_at, cette dernière exprimée en UTC.

Les six écarts qui reviennent partout

Des rapports de règlement dont la structure est publiéeAdyenStripeWorldline

Chapitre 4. Dates de valeur, fuseaux et coupures.

Un rapprochement multi-pays échoue rarement sur les montants. Il échoue sur les dates. Une même opération porte quatre dates différentes, chacune vraie dans son référentiel, et le comptable qui en choisit une au hasard fabrique des suspens de fin de mois. La discipline consiste à nommer les quatre et à décider laquelle sert de fenêtre.

• Ne jamais rapprocher sur une égalité de dates. Une référence identique rapproche ; une date sert de fenêtre de tolérance, calibrée par corridor
• Stocker l'heure en UTC et le fuseau d'origine séparément. Adyen publie une colonne TimeZone à côté de la date de création, Stripe exprime automatic_payout_effective_at en UTC
• Connaître l'heure de coupure de chaque acquéreur et de chaque banque, exprimée dans son fuseau : c'est elle qui décide de quel côté d'une fin de mois tombe une vente du soir
• Tenir un calendrier de jours ouvrés par pays, jours fériés locaux compris. Un virement émis la veille d'un pont indien n'arrive pas au rythme d'un virement européen
• Rattacher le produit à la date d'opération, jamais à la date de règlement, sous peine de déplacer du chiffre d'affaires d'un exercice à l'autre

Cet exemple tient sur cinq jours calendaires et trois dates de référence distinctes. Le produit se rattache au vendredi 10, tandis que le lettrage bancaire se fait au mardi 14 et que la trésorerie compte au mercredi 15. Trois chiffres justes, trois usages différents.

Chapitre 5. Le mobile money : trois registres, aucune ligne bancaire.

Sur une large partie de l'Afrique subsaharienne et de l'Asie du Sud, comme dans certains corridors d'Amérique centrale, l'encaissement n'arrive pas sur un compte bancaire. Il arrive sur un compte de monnaie électronique tenu par un opérateur, rattaché à un numéro court. L'argent y reste jusqu'à ce que l'entreprise déclenche un transfert vers sa banque. Aucun relevé bancaire ne décrit les ventes de la journée.

La conséquence opérationnelle est directe, le rapprochement se faisant à trois registres, et non à deux. Il compare le journal des notifications reçues par le système marchand, le relevé de la plateforme de l'opérateur et le crédit bancaire du transfert périodique. Les trois doivent boucler séparément.

• L'identifiant de transaction de l'opérateur est la clé unique. La notification C2B de M-PESA le porte sous TransID, avec TransAmount, BusinessShortCode et l'horodatage TransTime
• La référence de commande est saisie par le client, dans le champ BillRefNumber sur un numéro de type facturier. Elle est fautive dans une proportion non négligeable des cas : rapprochement approché obligatoire
• Les notifications se perdent et se répètent. La livraison n'est pas garantie une fois : dédupliquer sur l'identifiant, puis interroger l'API de statut de transaction en cas de doute
• Le numéro du payeur peut être masqué selon la configuration du service : ne bâtissez pas votre appariement sur lui
• Le float du compte marchand est un actif à part, à suivre comme une caisse : Mobile Money Limited, filiale de MTN Ghana, déclare 38,4 milliards GHS de float pour la seule année 2025 (résultats MTN Ghana, mars 2026)

Chapitre 6. Multi-devises et change.

Vendre en dix devises et rendre compte dans une seule impose deux conversions, à deux instants différents, la première étant opérée par l'acquéreur ou la banque, à son taux, au moment du règlement. La seconde est comptable. Elle traduit l'opération dans la monnaie de présentation des comptes. Confondre les deux fabrique un écart de change qui ressemble à une perte d'exploitation.

IAS 21, la norme de l'IASB sur les effets des variations des cours des monnaies étrangères, pose le cadre comptable, où une opération en devise se comptabilise au cours au comptant du jour de l'opération. À la clôture, les éléments monétaires (créances, dettes, trésorerie) sont réévalués au cours de clôture. Les éléments non monétaires évalués au coût historique restent à leur cours d'origine. Les écarts qui en résultent passent en résultat.

• Stocker trois valeurs, jamais une : montant en devise d'opération, montant en devise de règlement, et le taux qui relie les deux
• Ne jamais recalculer un taux à partir du quotient de deux montants arrondis : l'arrondi masque les frais et fabrique un faux taux
• Fixer la règle d'arrondi une fois pour toutes et la documenter. Un demi-centime arbitré différemment par deux systèmes crée des écarts d'un centime par transaction, invisibles à l'unité et massifs au million
• Isoler la marge de change de l'acquéreur : elle se déduit de la comparaison entre le taux du rapport et un cours de référence du même jour, et se négocie comme une commission
• Traiter la conversion imposée au porteur (la conversion dynamique de devise) comme une ligne à part : elle change le montant brut sans changer la vente

Reste le cas des devises non convertibles ou soumises à contrôle des changes, dans lequel les fonds encaissés localement ne sortent pas librement du pays. La créance existe, l'encaissement aussi, le rapatriement non. Ces soldes se suivent dans un compte dédié, pays par pays, avec leur ancienneté.

Chapitre 7. Automatiser sans perdre la piste d'audit.

L'automatisation d'un rapprochement échoue de deux façons opposées. Trop prudente, elle laisse une file de suspens que personne ne traite. Trop permissive, elle apparie des lignes qui n'ont rien à voir et fabrique une comptabilité fausse mais équilibrée. La sortie tient dans une cascade de règles nommées, ordonnées de la plus sûre à la plus risquée, chacune traçant ce qu'elle a fait.

Les références qui survivent au voyage

• `EndToEndId` ISO 20022, posé par le donneur d'ordre, restitué au bénéficiaire quand la chaîne le préserve
• UETR Swift, identifiant unique de bout en bout au format UUID version 4, obligatoire dans le champ 121 de l'en-tête utilisateur pour tous les utilisateurs Swift depuis le 18 novembre 2018
• Référence créancier structurée ISO 11649, préfixe RF, deux chiffres de contrôle calculés en MOD 97-10, puis jusqu'à 21 caractères libres. Le contrôle détecte une saisie fautive avant qu'elle n'entre dans le moteur
• `EndToEndId` Pix, 32 caractères imposés par le Banco Central do Brasil : E, ISPB de l'agent sur 8 chiffres, horodatage yyyyMMddHHmm en UTC, puis 11 caractères de séquence
• Identifiant de lot d'acquéreur, présent à la fois dans le rapport et dans le libellé du virement, c'est le pivot du niveau de règlement

• Le fichier source ne se modifie jamais. Il se conserve tel que reçu, avec son empreinte cryptographique et sa date de réception
• Une règle qui apparie ne compense pas. Créer une écriture d'ajustement pour faire disparaître un écart est une décision comptable, soumise à seuil et à approbation distincte
• Les suspens vieillissent et se comptent. Un tableau d'ancienneté par pays et par acquéreur, revu chaque semaine, empêche la file de devenir un cimetière
• Le taux de rapprochement automatique se mesure par corridor, pas globalement : un bon chiffre mondial masque toujours un pays qui ne boucle plus
• Toute règle nouvelle se teste sur l'historique avant activation, et son effet se mesure sur le taux d'appariement erroné, pas seulement sur le taux d'appariement

Un dernier arbitrage revient dans tous les projets. Il oppose le moteur unique, déployé pour tous les pays, à l'outil retenu filiale par filiale. Le moteur unique gagne dès que les mêmes clients paient dans plusieurs pays, parce qu'un remboursement traverse alors les frontières comptables. L'outil local, lui, garde sa place quand un pays impose un format déclaratif propre. Le partage se fait sur le pivot, commun partout et spécifique nulle part.