📊 La réconciliation et le reporting dans le monde

Cinq familles de relevés, cinq histoires bancaires

Un relevé de compte est le document par lequel une banque restitue à son client les mouvements enregistrés sur un compte et les soldes qui les encadrent. Sa structure varie d'un pays à l'autre, parce que chaque tradition bancaire nationale a fixé la sienne. Un groupe présent sur six marchés reçoit donc six formes distinctes du même document. Les banques européennes livrent un XML ISO 20022, les américaines un fichier à positions fixes, les brésiliennes un enregistrement de 240 caractères et les japonaises un fichier de 120 caractères. Ces formes décrivent les mêmes mouvements d'argent selon des conventions de champ, de codage et de découpage différentes.

Le choix du format conditionne ce qu'un moteur de rapprochement peut faire des données reçues. Quatre paramètres déterminent cette capacité : la longueur de la référence transportée, la présence d'un code d'opération normalisé, la séparation de la date comptable et de la date de valeur, l'accès au détail des opérations regroupées sous une écriture agrégée. Chacun désigne une information que le fichier porte ou ne porte pas. Un format pauvre sur ces quatre points plafonne le taux de lettrage automatique, car aucun traitement en aval ne reconstitue une donnée absente à la source.

camt.053 : la convergence, et ce qu'elle ne règle pas

La famille camt (Cash Management) regroupe les messages ISO 20022 consacrés à la restitution d'information de compte. Trois d'entre eux couvrent l'essentiel des usages, et chacun répond à un besoin distinct : suivre la position de trésorerie en cours de journée, arrêter la journée comptable, ou détailler les lignes d'une écriture agrégée.

• `camt.052`, Bank to Customer Account Report : l'intrajournalier, plusieurs fois par jour, sans garantie de complétude. Il sert au pilotage de trésorerie, pas à la clôture.
• `camt.053`, Bank to Customer Statement : le relevé officiel de la journée comptable, soldes d'ouverture et de clôture inclus. Il constitue la pièce du rapprochement.
• `camt.054`, Bank to Customer Debit/Credit Notification : l'avis d'opération, souvent le seul message qui détaille les lignes d'un lot présenté en une seule écriture au relevé.

Plusieurs versions du message coexistent, et le passage de l'une à l'autre modifie l'arborescence attendue par les programmes de lecture, ce qui rompt les intégrations qui ne l'ont pas anticipé. Les déploiements européens historiques reposent sur camt.053.001.02 alors que les offres récentes livrent .001.08 et suivantes, alignées sur les recommandations du groupe CGI-MP (Common Global Implementation – Market Practice). Son groupe de travail 2 publie ses bonnes pratiques camt via Swift. Les arborescences restent proches sans être identiques d'une version à l'autre, et une même version admet des variantes d'implémentation d'une banque à l'autre. La recette d'un parseur porte donc sur chaque couple version et banque effectivement reçu, et non sur la seule conformité à la norme.

<Ntry>                                        <!-- une ecriture au releve -->
  <Amt Ccy="EUR">14208.55</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <BookgDt><Dt>2026-08-06</Dt></BookgDt>      <!-- date comptable -->
  <ValDt><Dt>2026-08-07</Dt></ValDt>          <!-- date de valeur : celle qui compte pour la tresorerie -->
  <AcctSvcrRef>BNK2608061147</AcctSvcrRef>    <!-- reference de la banque -->
  <BkTxCd>
    <Domn><Cd>PMNT</Cd>                       <!-- domaine : paiement -->
      <Fmly><Cd>RCDT</Cd>                     <!-- famille : credit recu -->
        <SubFmlyCd>ESCT</SubFmlyCd></Fmly>    <!-- sous-famille : virement SEPA -->
    </Domn>
  </BkTxCd>
  <NtryDtls><TxDtls>                          <!-- le detail sous l'ecriture agregee -->
    <Refs><EndToEndId>PAYOUT-2026-08-06-000871</EndToEndId></Refs>
    <RmtInf><Ustrd>PSP BATCH 000871</Ustrd></RmtInf>
  </TxDtls></NtryDtls>
</Ntry>

Les formats qui ne migrent pas : BAI2, CNAB, Zengin

Le BAI2 (Cash Management Balance Reporting Specifications, Version 2) est le format dans lequel les banques américaines restituent à leurs clients entreprises les soldes et les mouvements d'un compte. Il demeure le format de relevé le plus répandu entre banques et entreprises aux États-Unis, à l'écart de la convergence européenne vers ISO 20022. Il descend d'un standard de lockbox publié en 1971. BAI1 arrive en 1980, la forme actuelle en 1987, les codes d'opérations de prêt en 2001. Le format change ensuite de propriétaire lorsque le Bank Administration Institute transfère les droits à l'Accredited Standards Committee X9 en 2008. La structure d'enregistrements publiée en 1987 reste celle en vigueur aujourd'hui.

01,SENDER,RECEIVER,260807,0730,1,,,2/      en-tete de fichier
02,RECEIVER,BANKID,1,260806,,USD,2/        en-tete de groupe (une date, une devise)
03,0001234567,USD,010,15250000,,/          compte + solde d'ouverture (code 010), en cents
88,015,17310000,,/                         continuation : solde de cloture (code 015)
88,045,16980000,,/                         continuation : solde disponible de cloture (code 045)
16,275,2500000,0,DEP0099,,VIREMENT PSP/    code dans la plage 100-399 = credit
16,475,1440000,0,CHK0451,,PAIEMENT FRNS/   code dans la plage 400-699 = debit (475 = cheque paye)
49,32050000,5/                             total de compte + nombre d'enregistrements
98,32050000,1,7/                           total de groupe
99,32050000,1,9/                           total de fichier

La lecture d'un fichier BAI2 repose sur deux conventions, dont l'ignorance produit l'essentiel des erreurs d'intégration. Les montants sont exprimés en unités mineures de la devise. Aucun séparateur décimal n'y figure. Le sens de l'opération se déduit ensuite de la plage à laquelle appartient le code type, et non du code pris isolément. Les codes 010 à 099 portent les soldes, sur l'enregistrement 03. De 100 à 399, les codes désignent des crédits ; de 400 à 699, des débits ; au-delà de 900, des opérations codifiées par chaque banque. Un traitement peut donc se fonder sur la plage pour établir le sens, alors que la signification fine d'un code varie d'un établissement à l'autre.

Le Brésil emploie une famille de formats qui lui est propre. La FEBRABAN publie le Layout Padrão CNAB 240, où l'échange de relevés pour rapprochement bancaire passe par le segment E, porteur d'une catégorie d'écriture par mouvement. Le CNAB 400, hérité des années 1980, subsiste chez de nombreux facturiers pour les remises et retours de boleto. Une intégration brésilienne traite donc deux générations de fichiers en même temps, ainsi que la clé métier qui les relie. Cette clé est le Nosso Número, identifiant du boleto attribué par la banque. Au Japon, le format Zengin de la Japanese Bankers Association tient dans quatre types d'enregistrement de 120 caractères, identifiés par leur premier caractère. Il ne transporte aucune référence structurée. Le seul identifiant du payeur est le nom qu'il a saisi, en katakana.

Les fichiers d'acquéreur : pourquoi le montant net est ce montant-là

Un fichier d'acquéreur détaille les opérations compensées et les montants qui en résultent, pour le compte du réseau de cartes ou de l'acquéreur qui le produit. Ces fichiers suivent des formats propres aux schemes et aux acquéreurs, sans rapport avec ceux que les banques emploient pour les relevés de compte. Ils portent la décomposition qu'un relevé bancaire ne donne pas : celui-ci enregistre le montant arrivé sur le compte sans indiquer ce qui le compose. Visa compense historiquement en fichiers Base II, organisés en transaction codes. Une vente relève du TC05, un crédit du TC06. Mastercard utilise l'IPM (Integrated Product Messages), où un message 1240 porte une première présentation, un 1442 un chargeback, un 1740 des frais.

Le règlement proprement dit figure dans une autre série de rapports. Les rapports du VSS (VisaNet Settlement Service) sont livrés en enregistrements TC46, exploitables par machine ; le TC47 en est la déclinaison lisible. Le rapport VSS-110 porte le résumé de règlement de la journée, sur lequel un acquéreur cale sa position. Un commerçant n'accède pas à ces fichiers et reçoit le settlement report de son PSP, qui en est une projection. Le rapprochement consiste alors à confronter cette projection, ligne à ligne, au crédit reçu en banque.

La clé de rapprochement, rail par rail

La clé de rapprochement est l'identifiant qui accompagne une opération depuis son initiation jusqu'à son inscription au relevé, et qui permet de relier les deux enregistrements. Chaque rail en produit un, et un seul, qui survit à l'ensemble du parcours. Son format, son producteur et son point d'apparition varient d'un système à l'autre. Le taux de lettrage automatique dépend de la présence de cette clé dans chacune des sources rapprochées, ce qui fait de son identification la première étape de conception d'un dispositif d'encaissement.

Le Pix brésilien emploie deux identifiants distincts. L'`EndToEndId` d'un Pix est un code de 32 caractères généré par l'institution du payeur au moment de l'initiation, construit comme E + ISPB du participant + horodatage + séquentiel. Il est unique dans le SPI et accompagne l'opération de bout en bout, ce qui en fait la clé de déduplication naturelle. Le `txid`, lui, est choisi par le bénéficiaire et remonté avec le paiement. Le manuel de normes du Banco Central lui assigne explicitement la fonction de rapprochement côté marchand. Le bénéficiaire fixe donc sa propre référence avant l'encaissement et la retrouve à l'identique dans le message reçu, sans reprise manuelle.

Le dispositif mexicain repose sur une preuve de règlement centralisée plutôt que sur une référence portée par le marchand. Pour tout virement SPEI dont l'établissement destinataire a confirmé le crédit, Banco de México produit un Comprobante Electrónico de Pago. Ce document porte la clave de rastreo, les institutions, les comptes et un sceau numérique, et se télécharge en PDF ou en XML vérifiable. Une entreprise à gros volume automatise cette récupération et vérifie chaque crédit annoncé contre le document correspondant. Le dispositif est public. La plupart des autres marchés n'offrent pas d'équivalent.

Trois dates par opération, et aucune n'est alignée

Une opération porte au minimum trois dates. La date d'opération est celle de l'acte commercial. La date comptable (booking date) est celle de l'inscription au compte. La date de valeur (value date) détermine le calcul des intérêts et la trésorerie réellement disponible. Certains marchés en ajoutent une quatrième, la date de disponibilité des fonds, distincte des trois autres. Un rapprochement mené sur une date différente de celle qu'emploie la source opposée fait apparaître un écart quotidien. L'écart de sens inverse du lendemain le compense sans jamais le supprimer.

Au Brésil, les créances issues des arrangements de paiement s'enregistrent auprès d'entités agréées par le Banco Central. Ces créances correspondent à ce que l'acquéreur doit au commerçant avant échéance. CERC, Núclea, B3, TAG et CRDC sont reliées par une convention d'interopérabilité publiée par la banque centrale. Le commerçant brésilien dispose donc d'une source officielle et opposable de son agenda de recebíveis, indépendante de son acquéreur. Le rapprochement s'appuie sur cette source autant que sur le relevé bancaire, alors qu'aucun autre grand marché ne dispose d'un registre équivalent.

Réconcilier le mobile money

Le mobile money désigne un service de paiement et de transfert reposant sur un compte de monnaie électronique tenu par un opérateur et utilisé depuis un téléphone mobile. Il constitue le rail dominant de plusieurs dizaines de marchés, et sa réconciliation obéit à des règles distinctes de celles d'un compte bancaire. La monnaie qui circule est de la monnaie électronique émise par l'opérateur et adossée à un compte de cantonnement, alors que le réseau d'agents assure la conversion avec les espèces. Trois registres coexistent donc là où une banque n'en tient qu'un.

Le nombre d'opérations traitées par ces réseaux dépasse celui de bien des schemes carte. M-PESA au Kenya, exploité par Safaricom depuis 2007, a traité 46,41 milliards de transactions sur l'exercice clos le 31 mars 2026. La valeur correspondante atteint 41 680 milliards de shillings, auprès de 40 millions de clients actifs mensuels. La distribution des montants unitaires y est particulière. Les micro-transactions gratuites atteignent 17,1 milliards d'opérations et représentent 58 % de l'activité. Un moteur de rapprochement calibré sur des paniers européens reçoit donc, pour un même chiffre d'affaires, un nombre de lignes sans commune mesure, et s'effondre à ce volume unitaire. MTN MoMo revendique de son côté 23,3 milliards de transactions fintech pour 500,3 milliards de dollars sur l'exercice 2025.

L'encaissement en mobile money repose sur un paiement poussé par le payeur vers le compte du marchand. Le client valide l'opération vers un Paybill ou un Till, et le marchand ne tire pas les fonds de son côté. La notification arrive par callback HTTP, avec un TransID produit par l'opérateur et un BillRefNumber saisi par le client sur son clavier. Cette saisie manuelle est la source première du suspens, puisqu'un chiffre inversé dans un numéro de facture rend l'encaissement inimputable alors même que les fonds sont arrivés. Le portefeuille marchand sépare aussi le compte qui reçoit les encaissements de celui qui sert les décaissements, nommés Utility Account et Working Account chez Safaricom. Le rapprochement porte donc sur deux soldes distincts pour un même marchand.

Automatiser : moteur de rapprochement, comptes virtuels, file d'exceptions

L'automatisation du rapprochement combine deux chantiers. Le premier consiste à rendre les opérations rapprochables en amont, par la clé fixée avant l'encaissement, le format de relevé négocié et l'ouverture de comptes virtuels. Le second organise le traitement industriel de ce que le moteur laisse en suspens. Les organisations qui atteignent des taux de lettrage élevés ont presque toutes agi sur la source avant d'écrire la moindre règle d'appariement.

• Appariement par clé exacte. EndToEndId, txid, ARN, TransID, trace number. Le seul cas où le rapprochement est une preuve et non une présomption.
• Appariement au lot. Le versement bancaire contre le total du settlement report, puis explosion du lot en transactions. Indispensable dès que la banque agrège.
• Un à plusieurs. Un virement client qui solde huit factures ; il faut une logique d'allocation, pas une correspondance.
• Plusieurs à un. Un paiement fractionné, une commande réglée en deux fois, ou un encaissement mobile money complété par un second envoi.
• Tolérance encadrée. Un écart de quelques unités sur un change ou un arrondi peut se rapprocher automatiquement, sous plafond documenté et avec journalisation. Sans ce journal, les écarts absorbés par la tolérance ne sont plus dénombrables après coup, et le contrôle interne perd la mesure de ce qui a été accepté sans examen.

Certains rails ne transportent aucune référence exploitable. Les comptes virtuels y répondent par un dispositif bancaire, plutôt que par une règle d'appariement supplémentaire. La banque attribue au marchand une plage d'identifiants de compte, un par client ou par contrat, tous rattachés à un compte réel unique. Le payeur envoie ses fonds sur l'identifiant qui lui a été communiqué, et l'imputation se déduit du compte crédité, de façon déterministe et quelle que soit la pauvreté du format de relevé. Le dispositif est la réponse standard au format Zengin au Japon, aux relevés BAI2 sans référence normalisée, et à la plupart des rails asiatiques et africains adressés par numéro de compte.