Référence🏦 Réconciliation bancaireAvancé⏱ 17 min de lecture

🧩 ISO 20022 côté relevés : les camt

camt.052, camt.053, camt.054 : l'arborescence XML, les Bank Transaction Codes, le lien pain → camt et le matching automatique

camt.052, 053, 054 : trois messages, trois usages

La famille camt (Cash Management) porte le reporting de compte en ISO 20022. Trois messages couvrent l'essentiel des besoins de réconciliation, en remplacement direct des MT942, MT940 et MT900/910.

⏱️
camt.052 (intraday)
Bank to Customer Account Report : soldes et écritures en cours de journée, plusieurs vacations possibles. Remplace le MT942. Il sert à tenir la position de trésorerie en temps réel.
📄
camt.053 (relevé de fin de journée)
Bank to Customer Statement : le relevé officiel et complet de la journée comptable, soldes d'ouverture et de clôture garantis. Remplace le MT940. La réconciliation s'appuie sur lui.
🔔
camt.054 (avis et détail de lots)
Bank to Customer Debit Credit Notification : avis unitaire de débit/crédit et détail des remises comptabilisées en un montant global sur le relevé. Remplace les MT900/910.
Critèrecamt.052camt.053camt.054
PériodicitéIntraday (n vacations/jour)1/jour ouvré par compteAu fil de l'eau ou par lot
Soldes portésIntermédiaires (ITBD)OPBD, CLBD, CLAV, FWAVAucun (avis)
Valeur probante comptableIndicativeRéférence pour le rapprochementComplément de détail
Équivalent MTMT942MT940MT900/MT910
Usage typePosition de trésorerie, équilibrageRéconciliation et comptabilisationDétail des remises (prélèvements émis, cartes) et notifications
Comparatif des trois camt
ℹ️
Plusieurs versions du message coexistent, banque par banque et offre par offre. La place française a historiquement déployé camt.053.001.02 (guide CFONB), tandis que CBPR+ et les offres récentes utilisent .001.08 et suivantes. Les structures sont proches mais pas identiques (par exemple Sts devient un choix Cd/Prtry en .08), si bien que le parseur doit être testé par version ET par banque.

L'arborescence du camt.053

Le camt.053 est un document XML dont la hiérarchie sépare rigoureusement le message (GrpHdr), le relevé par compte (Stmt), l'écriture comptable (Ntry) et la transaction de détail (TxDtls). Cette distinction Ntry/TxDtls est la clé de lecture, parce qu'une écriture peut agréger tout un lot dont chaque transaction reste individuellement accessible.

BkToCstmrStmt1 messageGrpHdrMsgId · CreDtTmStmt1 par compte · ElctrncSeqNbAcct + Bal[ ]IBAN · OPBD CLBD CLAV ITBDNtryL'ÉCRITURE comptable (BOOK)NtryDtls / BtchNbOfTxs = 350TxDtls #1TxDtls #21 → nTxDtls #350Refs/EndToEndIdRefs/MndtId (RUM)RmtInf/Strd (factures)Chrgs (frais isolés)AmtDtls (devise)ContrôleOPBD + Σ Ntry signés = CLBDVu par la comptabilitéExigé par le matching1 Ntry = 1 crédit global de remise. Un moteur qui s’arrête au Ntry ne rapprochera jamais un impayé unitaire.Certaines banques ne restituent pas TxDtls sur les lots : le détail arrive alors dans un camt.054 séparé.
ÉlémentCheminRôle
GrpHdrBkToCstmrStmt/GrpHdrEn-tête du message : MsgId unique, CreDtTm (horodatage de génération)
StmtBkToCstmrStmt/StmtUn relevé par compte : Id, ElctrncSeqNb (n° séquentiel, équivalent :28C:), FrToDt
AcctStmt/AcctCompte : IBAN, devise, titulaire (Ownr)
BalStmt/Bal (répété)Soldes typés : OPBD ouverture, CLBD clôture comptable, CLAV disponible, ITBD intermédiaire, FWAV prévisionnel
NtryStmt/Ntry (répété)Écriture comptable : montant, sens (CdtDbtInd), statut (BOOK/PDNG), dates (BookgDt, ValDt), référence banque (AcctSvcrRef), BkTxCd
NtryDtlsNtry/NtryDtlsDétail de l'écriture : nombre de transactions du lot (Btch/NbOfTxs) et liste de TxDtls
TxDtlsNtryDtls/TxDtls (répété)La transaction unitaire : références, montants détaillés, parties, motif
RefsTxDtls/RefsLe trésor du matching : MsgId, PmtInfId, InstrId, EndToEndId, MndtId, TxId, tous restitués sans troncature
RmtInfTxDtls/RmtInfMotif de paiement : Ustrd (libre, 140 c.) ou Strd (structuré : références de factures, référence créancier ISO 11649 « RF »)
Éléments structurants du camt.053
🔑
Ntry ≠ TxDtls
Une remise de 350 prélèvements émis apparaît comme 1 `Ntry` (le crédit global) contenant 350 `TxDtls`, ou comme 1 Ntry renvoyant vers un camt.054 de détail. Un moteur de réconciliation qui s'arrête au niveau de l'écriture ne dispose d'aucune donnée pour rapprocher les impayés unitaires, puisque ceux-ci ne figurent que dans les TxDtls.

Bank Transaction Codes : la taxonomie Domain / Family / SubFamily

Le Bank Transaction Code (BTC) est un code publié par ISO qui qualifie chaque écriture sur trois niveaux, le domaine, la famille et la sous-famille. Là où le MT940 se limitait à un code du type NTRF et le CFONB120 à un code AFB à deux chiffres, le BTC indique ce qu'est l'opération, dans les mêmes termes d'une banque à l'autre dès lors qu'elle le renseigne.

DomainFamilySubFamilySignification
PMNTRCDTESCTVirement SEPA reçu (received credit transfer, SEPA)
PMNTICDTESCTVirement SEPA émis
PMNTRDDTESDDPrélèvement SEPA Core débité sur le compte
PMNTRDDTBBDDPrélèvement SEPA B2B débité
PMNTIDDTESDDRemise de prélèvements SEPA émise (créancier), créditée
PMNTCCRDPOSDPaiement carte au point de vente (côté porteur)
PMNTCNTRCDPTDépôt d'espèces au guichet
PMNTICDTCHRGFrais sur virement émis
Exemples de Bank Transaction Codes fréquents

Le BTC coexiste avec un code propriétaire (Prtry). En France, les banques y restituent le code opération AFB historique (avec Issr = CFONB). La transition des moteurs de réconciliation construits sur le CFONB120 en est facilitée, parce que chaque écriture porte les deux codages à la fois.

ℹ️
La table de routage comptable se construit sur le BTC en priorité, code propriétaire en secours. Une écriture codée PMNT/RCDT/ESCT s'impute et se rapproche alors automatiquement, quel que soit le libellé qu'elle porte par ailleurs.

Exemple complet de camt.053 annoté

Relevé camt.053.001.08 du 10/07/2026 : un payout Adyen en crédit, un prélèvement de loyer en débit. Les écritures et les soldes reprennent volontairement ceux de l'exemple CFONB120 du topic suivant, de quoi comparer les deux formats sur un cas identique.

camt.053, relevé du 10/07/2026 (annoté)
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>CAMT053-20260711-000132</MsgId>       <!-- identifiant unique du message -->
      <CreDtTm>2026-07-11T04:07:12+02:00</CreDtTm> <!-- genere par la banque a 4h07 -->
    </GrpHdr>
    <Stmt>
      <Id>STMT-2026-07-10-132</Id>
      <ElctrncSeqNb>132</ElctrncSeqNb>             <!-- n° sequentiel = detection de releve manquant -->
      <CreDtTm>2026-07-11T04:07:12+02:00</CreDtTm>
      <Acct>
        <Id><IBAN>FR7630004008120001234567887</IBAN></Id>
        <Ccy>EUR</Ccy>
        <Ownr><Nm>ACME DISTRIBUTION SAS</Nm></Ownr>
      </Acct>
      <Bal>                                        <!-- solde d'ouverture -->
        <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="EUR">152340.25</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-07-09</Dt></Dt>
      </Bal>
      <Bal>                                        <!-- solde de cloture comptable -->
        <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
        <Amt Ccy="EUR">162999.75</Amt>             <!-- 152340,25 + 12500,00 - 1840,50 -->
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt><Dt>2026-07-10</Dt></Dt>
      </Bal>
      <Ntry>                                       <!-- ECRITURE 1 : payout Adyen -->
        <Amt Ccy="EUR">12500.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Sts><Cd>BOOK</Cd></Sts>                   <!-- comptabilisee (vs PDNG en attente) -->
        <BookgDt><Dt>2026-07-10</Dt></BookgDt>
        <ValDt><Dt>2026-07-10</Dt></ValDt>
        <AcctSvcrRef>BNK7593012</AcctSvcrRef>      <!-- reference banque (= //ref du MT940) -->
        <BkTxCd>
          <Domn>
            <Cd>PMNT</Cd>
            <Fmly><Cd>RCDT</Cd><SubFmlyCd>ESCT</SubFmlyCd></Fmly> <!-- virement SEPA recu -->
          </Domn>
          <Prtry><Cd>15</Cd><Issr>CFONB</Issr></Prtry>            <!-- code AFB en parallele -->
        </BkTxCd>
        <NtryDtls>
          <TxDtls>
            <Refs>
              <!-- EndToEndId complet, NON tronque : la cle du matching automatique -->
              <EndToEndId>ADYEN-SETTLEMENT-2026-BATCH42</EndToEndId>
            </Refs>
            <RltdPties>
              <Dbtr><Pty><Nm>ADYEN N.V.</Nm></Pty></Dbtr>         <!-- donneur d'ordre -->
            </RltdPties>
            <RmtInf><Ustrd>SETTLEMENT BATCH 42 ACME FR</Ustrd></RmtInf>
          </TxDtls>
        </NtryDtls>
      </Ntry>
      <Ntry>                                       <!-- ECRITURE 2 : prelevement SEPA debite -->
        <Amt Ccy="EUR">1840.50</Amt>
        <CdtDbtInd>DBIT</CdtDbtInd>
        <Sts><Cd>BOOK</Cd></Sts>
        <BookgDt><Dt>2026-07-10</Dt></BookgDt>
        <ValDt><Dt>2026-07-10</Dt></ValDt>
        <AcctSvcrRef>BNK7593044</AcctSvcrRef>
        <BkTxCd>
          <Domn><Cd>PMNT</Cd><Fmly><Cd>RDDT</Cd><SubFmlyCd>ESDD</SubFmlyCd></Fmly></Domn>
        </BkTxCd>
        <NtryDtls>
          <TxDtls>
            <Refs>
              <EndToEndId>LOYER-2026-07</EndToEndId>
              <MndtId>RUM-FONCDOCKS-0042</MndtId>  <!-- RUM du mandat de prelevement -->
            </Refs>
            <RltdPties><Cdtr><Pty><Nm>FONCIERE DES DOCKS</Nm></Pty></Cdtr></RltdPties>
            <RmtInf><Ustrd>LOYER ENTREPOT JUILLET 2026</Ustrd></RmtInf>
          </TxDtls>
        </NtryDtls>
      </Ntry>
    </Stmt>
  </BkToCstmrStmt>
</Document>
  • Contrôle d'intégrité : OPBD 152 340,25 + 12 500,00 − 1 840,50 = 162 999,75 = CLBD. ✔
  • L'EndToEndId de 29 caractères passe intact, là où le :61: du MT940 l'aurait tronqué à 16.
  • Le MndtId (RUM) permet de rapprocher le débit de la base de mandats sans analyse de libellé.
  • Le double codage BTC + code AFB propriétaire autorise une migration en douceur depuis le CFONB120.

pain.001, pain.008 et le lien remise → relevé

Les messages pain (Payment Initiation) sont le versant « aller » des camt : pain.001 transporte les remises de virements, pain.008 les remises de prélèvements, pain.002 restitue les statuts (accepté, rejeté, motif). L'apport d'ISO 20022 tient dans la circulation des références de bout en bout, puisque les identifiants émis dans la remise pain sont restitués dans le camt qui rend compte de son exécution.

MessageRôleRéférences clés émisesRestitution camt
pain.001Remise de virements (SCT / SCT Inst)PmtInfId (lot), EndToEndId et InstrId (par virement)camt.054 (avis de débit du lot), camt.053 (Ntry + TxDtls/Refs)
pain.008Remise de prélèvements SEPA (Core / B2B)PmtInfId, EndToEndId, MndtId (RUM)Crédit de remise, puis débits unitaires des impayés (retours RtrInf avec motif)
pain.002Compte rendu de traitementStatuts ACCP/RJCT + codes motifs ISOEn amont du relevé : filtre les rejets techniques
Messages pain et leur restitution côté relevé
Boucle fermée remise → relevé
ERP / trésorerie
Émet le pain.001
PmtInfId REM-2026-07-10-01, 120 virements, EndToEndId par facture
Banque
Acquitte via pain.002
118 acceptés, 2 rejetés (IBAN invalide, compte clos)
Banque
Exécute et débite le compte
1 débit global du lot, date d'exécution demandée
Banque
Notifie en camt.054
Détail des 118 exécutés, rattachés au PmtInfId
Banque
Restitue le camt.053 à J+1
Ntry du lot + TxDtls portant chaque EndToEndId
Moteur de réconciliation
Matche automatiquement
EndToEndId relevé = EndToEndId remise = facture ERP : lettrage sans intervention
🔑
L'EndToEndId doit être signifiant et unique (par exemple FACT-2026-18452), et jamais renseigné à NOTPROVIDED, valeur qui prive la chaîne de toute clé exploitable. Il circule jusqu'à la banque de la contrepartie et revient dans les relevés des deux parties, de sorte que deux back-offices se rapprochent sur la même clé.

Avantages, limites et stratégie d'adoption

  • Références non tronquées : EndToEndId 35 caractères, PmtInfId, MndtId. Le matching déterministe devient la norme.
  • Données de remise structurées : RmtInf/Strd peut porter des numéros de factures et la référence créancier ISO 11649 (« RF »). Le lettrage client s'automatise.
  • Sémantique normalisée : les Bank Transaction Codes remplacent l'exégèse de libellés.
  • Multi-devises et parties complètes : montants d'origine (AmtDtls), taux de change, donneur d'ordre ultime (UltmtDbtr).
  • Un seul standard de la remise au relevé : pain → pacs → camt, mêmes identifiants partout.
⚠️
Les limites du monde réel
Toutes les banques ne remplissent pas les camt avec le même soin. Les défauts relevés sont des TxDtls absents sur certains lots, des BTC génériques (PMNT/MCOP/OTHR), des versions différentes d'une banque à l'autre et des données de remise perdues quand un maillon de la chaîne est resté en MT. Chaque banque doit donc être testée avec des flux réels avant de généraliser les règles de matching.

Une stratégie d'adoption pragmatique en 2026 consiste à basculer la réception en camt.053/054 partout où la banque le propose, le CFONB120 ou le MT940 restant en flux de secours pendant un trimestre. Elle suppose aussi d'imposer des EndToEndId signifiants sur toutes les remises émises, puis de reconstruire les règles de routage comptable sur les BTC.

← Précédent
📨 SWIFT MT et le relevé MT940
Suivant →
🗂️ Les formats français CFONB