Chapitre 1. Les trois niveaux de réconciliation.

Vendre n'est pas encaisser. Entre la commande validée sur le site et l'euro crédité en banque s'intercalent capture, compensation, frais, remboursements, chargebacks, réserves et agrégation en payouts. La réconciliation consiste à prouver, ligne à ligne, que rien ne s'est perdu dans cette chaîne, ni en montant ni en délai. L'exigence est comptable (image fidèle, CAC), fiscale et opérationnelle. Il faut détecter un payout manquant en jours, pas en mois, quand la trésorerie du commerçant en dépend.

Trois questions, trois réconciliations

Réconciliation transactionnelle. Chaque commande a-t-elle son paiement ? Rapproche le back-office e-commerce (commandes) des transactions PSP (autorisées, capturées). Détecte les captures manquantes, doublons, écarts de montant.
Réconciliation de règlement. Le net versé est-il juste ? Rapproche les transactions capturées du rapport de règlement PSP (brut − frais − remboursements − chargebacks − réserves), puis ce rapport du virement effectivement reçu en banque.
Réconciliation comptable (bancaire). Le grand livre reflète-t-il la banque ? Lettrage des écritures du relevé (camt.053, MT940, CFONB120) contre la comptabilité, apurement des comptes d'attente et de transit (471, 511, 580).

Le chemin d'un paiement de 49,90 €

Client

Paie 49,90 € sur le site

Autorisation puis capture, référence commande CMD-88412

PSP

Enregistre la transaction

Référence PSP unique, statut Settled à J+1

Scheme / acquéreur

Compense et règle le PSP

Interchange et scheme fees prélevés au passage

PSP

Verse un payout net agrégé

Batch 191 : centaines de transactions, J+1 à J+3

Banque

Crédite le compte et produit le relevé

camt.053, MT940 ou CFONB120 le lendemain matin

Comptabilité

Lettre l'écriture contre les pièces

Payout ↔ rapport PSP ↔ transactions ↔ commandes

Niveau	Sources rapprochées	Fréquence	Écarts typiques
1. Transactionnel	Back-office commandes ↔ transactions PSP	Quotidienne (voire continue)	Capture oubliée, doublon, montant modifié
2. Règlement	Transactions ↔ rapport de règlement ↔ virement banque	À chaque payout	Frais inattendus, chargeback débité, réserve, écart FX
3. Comptable	Relevé bancaire ↔ grand livre	Quotidienne + clôture	Écriture non lettrée, compte d'attente vieillissant

Synthèse des trois niveaux

⚠️

Les trois niveaux ont des temporalités différentes, et chacun se réfère à une date qui lui est propre. Une vente du 30 juin peut être réglée le 2 juillet et comptabilisée sur juillet. Sans gestion rigoureuse des cut-offs (date de transaction vs date de règlement vs date de valeur), la réconciliation produit de faux écarts en fin de mois. Ce décalage est le premier motif d'exceptions dans la pratique, plus fréquent encore que les erreurs de fichier.

Chapitre 2. Rapports de règlement PSP : reconstituer le net.

Le rapport de règlement (settlement report, payout report) est le document pivot du niveau 2. Il liste chaque transaction incluse dans un versement, avec la décomposition des frais prélevés sur chacune d'elles. Son total net doit correspondre au centime au virement reçu en banque. Sa clé de lot (batch ou payout ID) doit se retrouver dans le libellé du virement, faute de quoi le rattachement d'un crédit bancaire à son rapport repose sur le seul montant.

Brut : montant payé par le client, signé (négatif pour remboursements et chargebacks).
Commission PSP : markup du prestataire, soit fondu dans un taux global (blended), soit isolé (interchange++).
Interchange : reversé à l'émetteur, plafonné dans l'UE par le règlement IFR 2015/751 à 0,2 % (débit) et 0,3 % (crédit) pour les cartes consommateurs.
Scheme fees : redevances Visa/Mastercard/CB, typiquement 0,02 à 0,15 % selon le réseau et le type de transaction.
Ajustements : frais de chargeback, réserves (rolling reserve), corrections, conversion de devise avec son taux.

Extrait de rapport de règlement du batch 191 (CSV, format type Adyen)

Company Account,Merchant Account,Psp Reference,Merchant Reference,Payment Method,Type,Gross (EUR),Commission (EUR),Scheme Fees (EUR),Interchange (EUR),Net (EUR),Batch
MaSociete,MaSociete_ECOM,QFQTKPMMK7HXWN82,CMD-88412,visa,Settled,49.90,0.11,0.03,0.10,49.66,191
MaSociete,MaSociete_ECOM,LZXCVBNMK2JD93PA,CMD-88413,mc,Settled,120.00,0.14,0.05,0.24,119.57,191
MaSociete,MaSociete_ECOM,PPWOEIRUT5GH28QZ,CMD-88301,visa,Refunded,-35.00,0.05,0.00,0.00,-35.05,191
MaSociete,MaSociete_ECOM,MMBBCCDDEE11FF22,CMD-87990,mc,Chargeback,-29.90,15.00,0.00,0.00,-44.90,191
MaSociete,MaSociete_ECOM,,,,Fee,0.00,49.00,0.00,0.00,-49.00,191

Net du batch 191 : 49.66 + 119.57 - 35.05 - 44.90 - 49.00 = 40.28 EUR
-> a rapprocher du virement "ADYEN NV PAYOUT-191" recu en banque.

La ligne Refunded rembourse le client et ne restitue pas la commission. La ligne Chargeback reprend le montant et ajoute 15 € de frais de litige. La ligne Fee porte les frais mensuels facturés au fil de l'eau, sans se rattacher à une transaction particulière. Le net du lot, 40,28 €, est l'unique montant qui apparaîtra en banque, toutes les autres lignes ne vivant que dans le rapport.

Modèle	Décomposition	Coût total	Réconciliation
Blended 1,2 %	Taux unique tout compris : 1,20 €	1,20 €	Simple, mais opaque : impossible d'auditer interchange et scheme fees
Interchange++	Interchange 0,20 € + scheme fees ≈ 0,08 € + markup PSP 0,25 €	≈ 0,53 €	Trois lignes à rapprocher par transaction, mais coûts auditables et négociables

Blended vs interchange++ sur une transaction Visa débit consommateur FR de 100 €

🔑

Réconcilier au niveau transaction, jamais seulement au total du lot. Deux erreurs de signe opposé se compensent silencieusement dans un cumul, où un total juste dissimule deux lignes fausses. La règle d'or : total du rapport = somme des lignes = virement bancaire. La vérification revient au moteur, pas à un humain sous Excel.

Quelques points de vigilance reviennent. Les payouts multi-devises imposent un rapport par devise de règlement et un taux de conversion à archiver avec le rapport lui-même, pour que l'écart de change reste explicable après coup. Les remboursements s'imputent parfois sur un lot postérieur à la vente, et les réserves se libèrent des mois plus tard. Reste le changement de format de rapport par le PSP, à traiter comme une évolution d'interface, avec recette de non-régression. Un format qui bouge casse le lettrage.

Chapitre 3. MT940 / MT942 : le relevé SWIFT historique.

Le MT940 (Customer Statement Message) est le relevé de compte de fin de journée du monde SWIFT FIN, catégorie 9. Conçu dans les années 1980, il reste omniprésent dans les trésoreries multi-banques, où il sert de plus petit dénominateur commun entre établissements. Le MT942 est son pendant intraday (opérations provisoires depuis le dernier relevé), le MT941 un simple rapport de soldes. Le format repose sur des tags délimités par deux-points, en texte brut, avec des lignes limitées à 65 caractères, contrainte qui pèse sur tout ce que la banque peut y écrire.

Tag	Nom	Contenu
:20:	Transaction Reference	Référence du message, unique par relevé
:25:	Account Identification	Compte concerné (BIC/IBAN ou banque-guichet-compte)
:28C:	Statement Number	Numéro de relevé / numéro de séquence
:60F: / :60M:	Opening Balance	Solde d'ouverture (F = final, M = intermédiaire) : sens, date, devise, montant
:61:	Statement Line	Une ligne par mouvement, le cœur du format
:86:	Information to Account Owner	Libellé libre, non structuré, jusqu'à 6 lignes de 65 caractères
:62F: / :62M:	Closing Balance	Solde de clôture comptable
:64: / :65:	Available / Forward Balance	Solde disponible, soldes prévisionnels

Structure d'un MT940

Décomposer le champ :61:

Date de valeur : 6 chiffres AAMMJJ (ex. 260710).
Date d'opération : 4 chiffres MMJJ, optionnelle (ex. 0710).
Sens : C crédit, D débit, avec RC/RD pour les annulations (reversals).
Montant : virgule décimale obligatoire (ex. 15230,50).
Type d'opération : une lettre (N standard, S SWIFT, F premier avis) + code 3 lettres : TRF virement, CHG frais, DDT prélèvement, CHK chèque, MSC divers, soit NTRF, NCHG, NDDT…
Référence pour le titulaire : 16 caractères max (PAYOUT-4521, ou NONREF).
`//` Référence banque puis, en ligne suivante, informations complémentaires (34 caractères).

MT940 complet, journée du 10/07/2026

:20:STMT-20260710-0191
:25:30004 00012 00012345678
:28C:191/1
:60F:C260709EUR125430,17
:61:2607100710C15230,50NTRFPAYOUT-4521//BQE889123
ADYEN NV BATCH 191
:86:VIR SEPA RECU ADYEN NV
MOTIF PAYOUT-4521 REMISE CARTES DU 09/07
:61:2607100710D1250,00NCHGNONREF//BQE889124
:86:COMMISSIONS MONETIQUE JUIN 2026
:62F:C260710EUR139410,67
:64:C260710EUR139410,67

Verification : 125430,17 + 15230,50 - 1250,00 = 139410,67 -> soldes coherents.
Ligne :61: n1 : valeur 10/07, credit, 15 230,50 EUR, virement (NTRF),
reference client PAYOUT-4521 (cle de matching), reference banque BQE889123.

⚠️

Le talon d'Achille : le :86:

Tout ce qui identifie vraiment l'opération (donneur d'ordre, motif, références de remise) est entassé dans le champ :86:, non structuré et différent d'une banque à l'autre. Certaines banques y glissent des sous-codes maison (?20, ?21…), d'autres du texte libre. Tout parseur MT940 est donc un assemblage de règles par établissement, fragile aux changements, qu'une simple refonte de libellé côté banque suffit à mettre en défaut. Telle est la raison d'être de camt.053.

Le MT942 partage la ligne :61:, mais ajoute l'horodatage (:13D:) et les compteurs :90D:/:90C:, nombre et somme des débits/crédits. On l'utilise pour tenir une position de trésorerie à 14 h et décider des équilibrages du jour, ou pour détecter au fil de l'eau un virement attendu. Les écritures MT942 sont provisoires. Seule la version du MT940 de fin de journée fait foi pour la réconciliation comptable, et elle seule peut servir de pièce au lettrage.

Chapitre 4. camt.052 / 053 / 054 : le relevé ISO 20022.

La famille camt (cash management) d'ISO 20022 remplace progressivement les MT9xx. camt.052 couvre l'intraday (≈ MT942), camt.053 le relevé de fin de journée (≈ MT940), camt.054 les notifications de débit/crédit et le détail des remises agrégées. Le gain n'est pas cosmétique, avec un XML structuré, des références de bout en bout, des codes d'opération normalisés et le multi-devises natif, autant d'éléments qu'un moteur exploite sans règle propre à chaque banque.

GrpHdr : identifiant et horodatage du message.
Stmt (053) / Rpt (052) / Ntfctn (054) : un bloc par compte.
Bal : soldes typés, avec OPBD ouverture comptable, CLBD clôture comptable, ITBD intermédiaire, CLAV clôture disponible, FWAV prévisionnel.
Ntry : une écriture (montant, sens CRDT/DBIT, statut BOOK/PDNG, code BTC).
NtryDtls → TxDtls : le détail transactionnel, soit les références (EndToEndId !), les contreparties, les montants d'origine et les frais, le motif de rejet (RtrInf).

Bank Transaction Codes : la sémantique normalisée

Chaque écriture porte un code BTC à trois niveaux tirés d'une nomenclature ISO externe, Domaine / Famille / Sous-famille. Le MT940 offrait NTRF fourre-tout, sous lequel se rangeaient indifféremment tous les virements. Le camt distingue nativement un virement SEPA reçu d'un prélèvement retourné, et le moteur de matching route l'écriture sans avoir à lire son libellé.

Domaine	Famille	Sous-famille	Signification
PMNT	RCDT	ESCT	Virement SEPA reçu
PMNT	ICDT	ESCT	Virement SEPA émis
PMNT	IDDT	ESDD	Remise de prélèvements SEPA (côté créancier)
PMNT	RDDT	ESDD	Prélèvement SEPA payé (côté débiteur)
PMNT	IDDT	UPDD	Prélèvement retourné / impayé
PMNT	CCRD	CWDL	Retrait espèces par carte

BTC usuels (domaine PMNT = paiements)

camt.053, extrait annoté (même journée que le MT940 précédent)

<BkToCstmrStmt>
  <GrpHdr>
    <MsgId>CAMT053-20260710-0001</MsgId>
    <CreDtTm>2026-07-11T06:00:00+02:00</CreDtTm>
  </GrpHdr>
  <Stmt>
    <Id>STMT-2026-0191</Id>
    <Acct><Id><IBAN>FR7630004000120001234567890</IBAN></Id></Acct>
    <Bal><!-- solde d'ouverture comptable -->
      <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
      <Amt Ccy="EUR">125430.17</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Dt><Dt>2026-07-09</Dt></Dt>
    </Bal>
    <Ntry><!-- le payout Adyen -->
      <Amt Ccy="EUR">15230.50</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Sts><Cd>BOOK</Cd></Sts>
      <ValDt><Dt>2026-07-10</Dt></ValDt>
      <BkTxCd><Domn>
        <Cd>PMNT</Cd>
        <Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly>
      </Domn></BkTxCd>
      <NtryDtls><TxDtls>
        <Refs><EndToEndId>PAYOUT-4521</EndToEndId></Refs>
        <RltdPties><Dbtr><Pty><Nm>ADYEN NV</Nm></Pty></Dbtr></RltdPties>
        <RmtInf><Ustrd>REMISE CARTES DU 09/07 BATCH 191</Ustrd></RmtInf>
      </TxDtls></NtryDtls>
    </Ntry>
  </Stmt>
</BkToCstmrStmt>

Critère	MT940	camt.053
Structure	Tags texte, :86: libre	XML entièrement structuré (schéma XSD)
Identification de l'opération	Code 3 lettres (NTRF…)	BTC à 3 niveaux normalisés
Références	16 caractères, souvent tronquées	`EndToEndId` 35 caractères, propagé de bout en bout
Contreparties	Dans le texte libre	Champs dédiés (nom, IBAN, BIC)
Taille de fichier	Compacte	5 à 10× plus volumineuse (négligeable aujourd'hui)
Parsing	Règles par banque, fragile	Générique, robuste

MT940 vs camt.053

🔑

camt.054 : la pièce manquante

Une remise carte ou un lot de prélèvements apparaît sur le camt.053 en une seule écriture agrégée, dont le montant ne correspond à aucune commande prise isolément. Le camt.054 en livre le détail opération par opération, chaque transaction de la remise, chaque prélèvement du lot, les impayés avec leur code motif RtrRsnInf. Le couple 053 + 054 est la configuration cible pour une réconciliation automatisée, le premier portant le solde de fin de journée et le second la granularité.

Depuis novembre 2025, la coexistence MT/MX est terminée sur SWIFT pour les instructions de paiement interbancaires. MT103 et MT202 sont remplacés par pacs.008 et pacs.009 sous CBPR+. Les relevés MT940/942 restent tolérés en relation banque-entreprise, sans date de retrait ferme, chaque établissement fixant son propre calendrier de bascule. Mais les banques poussent activement le camt, et toute nouvelle intégration devrait le choisir par défaut plutôt que reconduire un parseur à règles.

Chapitre 5. CFONB120 : le relevé de compte à la française.

Le CFONB120 est le format français historique de relevé de compte. Il est normalisé par le Comité Français d'Organisation et de Normalisation Bancaires, aujourd'hui commission du CFONB au sein de la FBF. Le format repose sur des enregistrements de 120 caractères en largeur fixe, sans balise. Chaque champ est identifié par sa position et par sa longueur, jamais par un nom. Malgré son âge, il reste massivement distribué via EBICS aux trésoreries et logiciels comptables français, dont beaucoup n'acceptent aucun autre format en entrée.

Enregistrement 01 : ancien solde (solde d'ouverture) du compte.
Enregistrement 04 : un mouvement (une écriture), le cœur du fichier.
Enregistrement 05 : complément d'information du mouvement précédent (libellés additionnels) ; plusieurs 05 peuvent suivre un 04.
Enregistrement 07 : nouveau solde (solde de clôture).

Position	Longueur	Champ
1–2	2	Code enregistrement (`04`)
3–7	5	Code banque
12–16	5	Code guichet
17–19	3	Code devise ISO
20	1	Nombre de décimales du montant
22–32	11	Numéro de compte
33–34	2	Code opération interbancaire (typologie AFB : virement, prélèvement, carte, chèque…)
35–40	6	Date de comptabilisation (JJMMAA)
43–48	6	Date de valeur (JJMMAA)
49–79	31	Libellé
91–104	14	Montant, dernier caractère = chiffre + signe combinés
105–120	16	Zone référence

Champs principaux de l'enregistrement 04 (mouvement)

La signature du format est le montant signé par lettre (overpunch, hérité des cartes perforées et de l'EBCDIC), piège classique des premiers parseurs écrits à la main. Le dernier caractère du montant encode à la fois le dernier chiffre et le signe : { = 0 crédit, A–I = 1 à 9 crédit ; } = 0 débit, J–R = 1 à 9 débit. 0000000152305{ avec 2 décimales vaut donc +15 230,50, et 0000000012500} vaut −1 250,00. Tout se joue sur la dernière lettre.

CFONB120, extrait annoté (champs espacés et lignes raccourcies pour la lisibilité ; 120 caractères en réel)

01 30004      00012 EUR 2  00012345678    090726                                   0000001254301G
04 30004      00012 EUR 2  00012345678 05 100726  100726 VIR SEPA ADYEN NV        0000000152305{ PAYOUT-4521
05 30004      00012 EUR 2  00012345678 05 100726         LIB REMISE CARTES DU 09/07 BATCH 191
04 30004      00012 EUR 2  00012345678 18 100726  100726 COMMISSIONS MONETIQUE    0000000012500} FRAIS-JUIN
07 30004      00012 EUR 2  00012345678    100726                                   0000001394106G

Lecture :
- 01 : ancien solde 1 254 301G -> G = 7 credit -> +125 430,17 EUR
- 04 : mouvement credit 152305{ -> { = 0 credit -> +15 230,50 EUR
- 05 : libelle complementaire rattache au 04 precedent
- 04 : mouvement debit 12500} -> } = 0 debit -> -1 250,00 EUR
- 07 : nouveau solde +139 410,67 EUR (coherent avec 01 + mouvements)

⚠️

Le code opération interbancaire (2 caractères, positions 33–34) suit la table AFB, avec des extensions SEPA propres à chaque établissement. Le contenu des enregistrements 05 varie lui aussi d'une banque à l'autre, parfois structuré en sous-zones, parfois réduit à du texte libre. Comme pour le :86: du MT940, prévoir un jeu de règles de parsing par banque, plus des tests de non-régression à chaque changement de contrat ou d'établissement. Le cousin CFONB240 sert, lui, aux relevés d'opérations (LCR/BOR), le CFONB320 aux ordres de virement internationaux. Ne pas les confondre.

Chapitre 6. pain.001 / pain.008 et les canaux : EBICS, SwiftNet, API.

La famille pain (payment initiation) couvre le sens aller : pain.001 pour initier des virements (SCT), pain.008 pour émettre des prélèvements (SDD), pain.002 pour les comptes rendus de statut (accepté, rejeté avec code motif). La boucle est bouclée quand le EndToEndId posé dans le pain.001 ressort tel quel dans le camt.053 du bénéficiaire et du donneur d'ordre. Cette continuité est la clé d'or de la réconciliation, celle qui dispense d'inventer des rapprochements par montant et par date.

pain.001, virement fournisseur (extrait)

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <MsgId>PAIN001-20260711-0001</MsgId>
      <CreDtTm>2026-07-11T09:30:00+02:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <CtrlSum>12435.20</CtrlSum>
      <InitgPty><Nm>MA SOCIETE SAS</Nm></InitgPty>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>LOT-FRS-20260711</PmtInfId>
      <PmtMtd>TRF</PmtMtd>
      <BtchBookg>false</BtchBookg><!-- false = une ecriture par virement au releve -->
      <ReqdExctnDt><Dt>2026-07-13</Dt></ReqdExctnDt>
      <Dbtr><Nm>MA SOCIETE SAS</Nm></Dbtr>
      <DbtrAcct><Id><IBAN>FR7630004000120001234567890</IBAN></Id></DbtrAcct>
      <DbtrAgt><FinInstnId><BICFI>BNPAFRPPXXX</BICFI></FinInstnId></DbtrAgt>
      <CdtTrfTxInf>
        <PmtId>
          <InstrId>INSTR-2214</InstrId>
          <EndToEndId>FACT-2026-2214</EndToEndId><!-- propage jusqu'au camt.053 -->
        </PmtId>
        <Amt><InstdAmt Ccy="EUR">12435.20</InstdAmt></Amt>
        <Cdtr><Nm>FOURNISSEUR SARL</Nm></Cdtr>
        <CdtrAcct><Id><IBAN>FR7610096000301234567890189</IBAN></Id></CdtrAcct>
        <RmtInf><Ustrd>FACTURE 2026-2214</Ustrd></RmtInf>
      </CdtTrfTxInf>
    </PmtInf>
  </CstmrCdtTrfInitn>
</Document>

BtchBookg false = une écriture bancaire par virement (réconciliation fine) ; true = une écriture agrégée par lot (relevé compact, mais détail à récupérer en camt.054).
pain.008 ajoute la mécanique de mandat : MndtId (RUM), date de signature, séquence FRST/RCUR/OOFF/FNAL, et le créancier identifié par son ICS. Les impayés (R-transactions) reviennent en pain.002 ou camt.054 avec des codes motifs normalisés (AM04 provision insuffisante, MD01 mandat absent…).
Le EndToEndId (35 caractères) survit à toute la chaîne interbancaire : y placer une clé métier (numéro de facture, ID payout), jamais du texte libre.

Trois canaux pour échanger ces fichiers

Critère	EBICS	SwiftNet (SCORE)	API
Zone	France, Allemagne, Suisse, Autriche	Mondial, multibanque	Selon la banque / DSP2 : UE
Coût indicatif	Faible (quelques dizaines d'€/mois par banque)	Élevé (adhésion SWIFT, BIC, service bureau)	Faible à moyen (API premium payantes)
Formats	Fichiers : pain, camt, CFONB	FIN (MT) + FileAct (tout fichier)	JSON temps réel + fichiers
Sécurité	Signatures personnelles ; profil TS avec signature disjointe des ordres	PKI SWIFT, non-répudiation	OAuth2, certificats eIDAS (QWAC/QSeal)
Cas d'usage type	ETI/PME française multi-banques	Groupe international, trésorerie centralisée	Solde temps réel, notification instantanée de crédit

Comparatif des canaux banque-entreprise

ℹ️

EBICS 3.0 unifie les versions française et allemande du protocole, longtemps divergentes sur les types d'ordres. Il remplace les types d'ordres historiques (FDL/FUL) par les BTF (Business Transaction Formats), qui décrivent explicitement format, version et usage du fichier échangé. La migration est généralisée en France depuis 2025. Les API DSP2 (AIS), elles, restent limitées pour la trésorerie, avec un périmètre restreint aux comptes de paiement et 4 consultations par jour sans présence du client. Au-delà, les banques vendent des API premium, hors cadre réglementaire et à leurs propres conditions tarifaires.

Aller-retour complet d'un virement fournisseur

Trésorerie / ERP

Génère le pain.001

EndToEndId = FACT-2026-2214

Canal EBICS TS

Transmet le fichier signé

Signature électronique disjointe de l'ordre

Banque émettrice

Contrôle et exécute

pain.002 : ACCP (accepté) ou RJCT + code motif

CSM (STEP2 / CORE FR)

Règle le virement interbancaire

pacs.008 entre banques

Banque du fournisseur

Crédite le compte

camt.054 de notification de crédit, le cas échéant

Relevé J+1

camt.053 chez les deux parties

EndToEndId intact → matching automatique dans les deux ERP

Chapitre 7. Moteur de matching, exceptions et KPI.

Le moteur de réconciliation applique une cascade de règles, de la plus stricte à la plus tolérante. Chaque ligne bancaire non rapprochée descend d'un cran, jusqu'au matching manuel qui reste le dernier étage. L'objectif consiste à ne présenter à l'humain que des exceptions qualifiées, avec un diagnostic proposé et la piste à vérifier en premier, plutôt qu'à tout matcher automatiquement. Le reste doit passer seul.

Exact 1-1 : référence identique (EndToEndId, payout ID) + montant exact + fenêtre de dates. Doit capter 85–95 % des lignes.
N-vers-1 : somme de N transactions du rapport PSP = 1 virement bancaire (payout agrégé) ; clé = batch ID + total au centime.
Avec tolérance : montant à ± X (frais bancaires prélevés au fil de l'eau, écarts de conversion FX). L'écart généré doit être comptabilisé, pas ignoré.
Fuzzy : similarité de libellé (donneur d'ordre, motif), distance de dates ; à réserver aux faibles montants avec revue par échantillonnage.
Apprentissage : chaque matching manuel devient une règle candidate (même contrepartie, même structure de libellé), validée avant industrialisation.

Exception	Cause typique	Traitement
Payout attendu absent	Jour férié bancaire, seuil de versement PSP non atteint, compte gelé	Alerte J+1 automatique ; escalade PSP à J+2
Virement sans rapport	Rapport de règlement en retard ou changement de format	Compte d'attente + relance ; ne jamais lettrer « au global »
Écart de quelques centimes	Arrondis FX, frais unitaires	Règle de tolérance avec écriture d'écart dédiée
Chargeback/impayé débité	Litige carte, R-transaction SDD (AM04, MD01…)	Routage vers l'équipe litiges avec la référence d'origine
Réserve retenue ou libérée	Rolling reserve contractuelle du PSP	Compte spécifique « réserves PSP », suivi d'échéancier
Doublon d'écriture	Rejeu de fichier, incident banque	Blocage automatique : même référence + même montant + même date

Exceptions courantes et traitement

KPI	Définition	Cible usuelle
Taux d'auto-match	Lignes rapprochées sans intervention / total	> 95 % en volume, > 98 % en montant
Exceptions ouvertes > 5 jours	Vieillissement du stock d'écarts	≈ 0 ; toute exception > 10 jours escaladée
Solde des comptes d'attente	Montant non affecté (cash unapplied)	Tendance à zéro à chaque clôture
Délai de certification du cash	Jours entre fin de mois et banque = compta	≤ J+3
Écarts absorbés en tolérance	Somme des mini-écarts passés en charges	Suivi mensuel ; une dérive signale un problème de frais ou de FX

KPI de la fonction réconciliation

🔑

La qualité d'une réconciliation se joue en amont du moteur, dans les références posées au moment où le flux est créé. Exiger du PSP un payout ID dans le libellé de virement. Poser des EndToEndId porteurs de sens dans chaque pain.001, activer camt.053 + camt.054 plutôt que MT940, interdire les remboursements hors outil. Un moteur médiocre avec des références propres bat un moteur brillant sur des données muettes.

Reste un point d'architecture. Conserver les fichiers bruts (rapports PSP, relevés) immuables et archivés, pour la piste d'audit et le contrôle fiscal des comptabilités informatisées. Tous les retraitements sont portés par le moteur, et rejouables à l'identique sur les fichiers d'origine. La réconciliation s'exécute quotidiennement, et non comme un traitement de fin de mois. La clôture n'en est que la photographie.

Réconciliation et formats bancaires. 7 chapitres et un QCM final.

Chapitre 1. Les trois niveaux de réconciliation.

Trois questions, trois réconciliations