Claude et Gemini produisent une réponse qui ressemble à un rapprochement bancaire. Mais aucun des deux ne peut prouver que ce résultat est complet et exact. Ce sont des modèles de langage généralistes : ils génèrent une réponse plausible à partir des fichiers et des instructions reçus. Un rapprochement défendable exige que chaque ligne des deux fichiers soit prise en compte, que chaque correspondance soit traçable et que chaque écart reste visible.

C'est cette distinction qui répond à la question pratique. Claude ou Gemini peut signaler quelques transactions, suggérer des correspondances de colonnes ou proposer une ébauche de formule. Traitez ces éléments comme du matériel de travail non vérifié. Un rapprochement bancaire rigoureux — celui qu'on révise, qu'on reproduit ou qu'on remet à un client — demande plus qu'une réponse de chat.

Lire un relevé ne revient pas à le rapprocher

Le rapprochement bancaire part de deux sources : le relevé de compte et le grand livre, le journal de trésorerie ou l'export de transactions que vous souhaitez y comparer. L'objectif n'est pas de décrire ces fichiers. C'est de les comparer sans perdre aucune ligne.

Pour chaque ligne, le résultat doit répondre aux questions suivantes :

  • Quelle ligne du second fichier est son homologue ?
  • Quel champ ou quelle combinaison de champs a établi la correspondance ?
  • Les montants concordent-ils exactement ?
  • L'écart de date est-il toléré, et selon quelle règle ?
  • Si aucun homologue n'existe, dans quel fichier se trouve la ligne non rapprochée ?
  • L'un des fichiers contient-il un doublon qui a rendu la correspondance ambiguë ?

Claude et Gemini peuvent lire du contenu tabulaire et en rédiger un résumé convaincant. Cela ne garantit pas que chaque ligne source a suivi un processus de correspondance cohérent. Un paragraphe indiquant que 184 transactions ont été rapprochées n'est pas la preuve que 184 paires spécifiques ont été comparées.

La différence apparaît clairement dès qu'on énonce les exigences du résultat :

Exigence du rapprochementCe que la tâche requiertCe que la réponse de chat fournit généralement
Couverture des sourcesChaque ligne des deux fichiers figure dans le résultatUn résumé, un échantillon ou un tableau réduit
Paires rapprochéesUne ligne spécifique du fichier A liée à une ligne spécifique du fichier BUn nombre de correspondances ou une description textuelle
Base de correspondanceRéférence, montant, date ou combinaison définie, indiquée pour chaque paireUne explication inférée de la base probable
ExceptionsChaque ligne non rapprochée ou ambiguë conservéeUne sélection des écarts jugés notables
VérificationTotaux et comptages dérivés de l'ensemble complet des lignesDes chiffres présentés sans chaîne de formules vérifiable
Piste d'auditPreuve exportable au niveau de la ligneUne réponse conversationnelle susceptible de varier à chaque relance

Se demander si Claude ou Gemini peut effectuer un rapprochement bancaire, c'est différent de se demander s'ils peuvent lire un CSV. Lire le fichier n'est que l'étape d'entrée. Le rapprochement, c'est la comparaison contrôlée et la trace de ce qui est arrivé à chaque ligne.

La limite est structurelle, pas propre à un modèle

Claude et Gemini se distinguent en tant que produits, mais cette comparaison ne résout pas le problème du rapprochement. La limitation est partagée par tous les LLM généralistes : ils sont conçus pour générer une réponse, pas pour tenir un registre comptable déterministe.

Un même prompt peut produire des formulations différentes, regrouper les exceptions autrement ou choisir une correspondance différente lorsque plusieurs candidats semblent plausibles. Cette variabilité est acceptable pour rédiger un e-mail. Elle ne l'est pas quand deux règlements de 250.00 existent et qu'un seul appartient à la facture INV-1048.

Prenons ces lignes :

Bank rowDateDescriptionAmount
B-1182026-05-06TRANSFER HOLT250.00
B-1192026-05-06TRANSFER PINE250.00
Ledger rowDateReferenceCustomerAmount
L-4422026-05-05INV-1048Pine Studio250.00

Une comparaison par montant et date produit deux candidats. Le résultat n'est pas « rapproché » tant qu'une clé fiable supplémentaire ne relie pas L-442 à B-119. Un modèle peut déduire du libellé que PINE correspond probablement à Pine Studio. C'est une suggestion utile, mais ça reste une inférence. Le résultat doit soit indiquer la règle qui a validé la correspondance, soit signaler les deux candidats pour révision.

Cette ambiguïté est fréquente avec les acomptes, les abonnements, les salaires, les virements à montant rond et les paiements récurrents fournisseurs. Un système qui masque l'ambiguïté peut produire un résultat d'apparence propre, mais erroné.

La concordance des soldes ne prouve pas l'exactitude des transactions

Un second piège consiste à accepter la concordance des soldes de clôture comme preuve que les transactions sous-jacentes ont été rapprochées. Claude ou Gemini peut relever que le relevé bancaire et le grand livre se terminent tous deux à 48 730 $. Cela confirme un seul chiffre. Pas les lignes qui l'ont produit.

Deux erreurs peuvent s'annuler mutuellement. Un dépôt de 900 $ manquant et un règlement de 900 $ manquant laissent le solde de clôture inchangé. Il en va de même d'une charge enregistrée deux fois, accompagnée d'une charge omise du même montant. Une réponse fondée sur les soldes uniquement manquera les deux problèmes, car la différence nette est nulle.

Le rapprochement nécessite donc deux contrôles :

  1. Contrôle des soldes. Le solde d'ouverture majoré des mouvements doit correspondre au solde de clôture dans chaque source.
  2. Contrôle des transactions. Chaque ligne doit être rapprochée, laissée sans correspondance ou signalée comme ambiguë.

Les deux contrôles sont indispensables. Un résultat au niveau des transactions avec un solde d'ouverture erroné est incomplet. Des soldes qui concordent avec des lignes inexpliquées le sont tout autant.

Cette distinction prend toute son importance quand le relevé bancaire est fourni en PDF. L'extraction des lignes du document introduit un point de contrôle supplémentaire avant le rapprochement. Le nombre de transactions extrait, le solde d'ouverture, le solde de clôture, ainsi que le total des débits et crédits doivent concorder avec le relevé original. Si un libellé renvoyé à la ligne devient deux entrées, si un signe négatif disparaît ou si une page est omise, la comparaison ultérieure part de données corrompues.

Une réponse de chat sépare rarement la validation de l'extraction de la validation du rapprochement. Elle peut passer directement de la lecture du relevé à la description du résultat. Un processus défendable prouve d'abord que le relevé a été capturé intégralement, puis établit comment ces lignes capturées se comparent au grand livre.

Trois raisons pour lesquelles un résultat convaincant peut être inexact

Le modèle peut ne pas traiter le fichier en entier

Les fichiers de transactions consomment rapidement le contexte disponible, car chaque ligne contient des dates, des références, des libellés, des devises et des montants. Quand les fichiers combinés et le prompt dépassent ce que le chat peut traiter, le modèle peut ne travailler qu'à partir d'une partie du contenu fourni ou d'une représentation condensée.

La réponse obtenue peut tout de même paraître complète. Elle peut inclure des totaux, des catégories d'exceptions et une explication assurée. Tant que le résultat ne prouve pas que chaque ligne source est représentée, il est impossible de savoir, à partir de la réponse seule, si des lignes ont été omises.

Le premier contrôle n'est donc pas « Le total semble-t-il raisonnable ? » C'est : « Puis-je retrouver le nombre de lignes source dans le résultat ? » Si le fichier A contient 2 416 lignes de données et le fichier B en contient 2 389, le rapport final doit rendre compte des 4 805 apparitions de lignes comme rapprochées, non rapprochées, dupliquées ou signalées.

Les chiffres n'ont pas de chaîne de calcul vérifiable

Un total affiché dans une réponse de chat n'est pas équivalent à un total produit par une formule de tableur vérifiable ou un rapport de correspondance déterministe. Il faut savoir quelles lignes y ont contribué.

Supposons que le modèle indique :

  • 2 350 transactions rapprochées
  • 31 transactions présentes uniquement dans le relevé bancaire
  • 8 transactions présentes uniquement dans le grand livre
  • La différence inexpliquée est de 0 $

Ces chiffres semblent cohérents entre eux. Ils n'en ont pas moins besoin de preuves. La section des correspondances doit contenir 2 350 paires identifiables. Les sections d'exceptions doivent contenir 39 lignes identifiables. Les montants de ces lignes doivent reproduire les totaux annoncés. Sans cette chaîne, le résumé ne peut pas être vérifié de manière indépendante.

Le résultat peut ne pas conserver le registre de correspondance

Même un résultat exact reste fragile s'il ne peut pas montrer comment il a été obtenu. Un registre de correspondance rigoureux identifie les deux lignes sources et la base exacte utilisée.

Ligne fichier ALigne fichier BBase de correspondanceStatut
B-118Montant dupliqué ; pas de référence uniqueÀ réviser
B-119L-442Libellé/client et montant exactRapproché
B-120Référence absente du grand livreNon rapproché (banque)

Ce tableau peut être vérifié. « Le règlement de 250.00 a été rapproché avec Pine Studio » ne peut pas l'être, sauf si les identifiants sources et la base sont conservés.

C'est aussi pourquoi un nouveau prompt ne constitue pas une piste d'audit. Demander à Claude ou Gemini d'expliquer la réponse précédente produit une nouvelle réponse générée. Cela ne reconstruit pas un registre déterministe capturé au moment de l'exécution de la comparaison.

Comment vérifier un rapprochement bancaire produit par une IA

Si vous avez déjà utilisé Claude ou Gemini, ne jetez pas le travail aussitôt. Traitez le résultat comme une ébauche et testez-le par rapport aux fichiers sources.

  1. Consignez le nombre de lignes sources. Excluez les en-têtes et les lignes vides. Conservez le décompte pour chaque fichier séparément.
  2. Exigez un résultat au niveau de la ligne. Chaque ligne source a besoin d'un identifiant stable. Ajoutez-en un avant l'envoi si les fichiers n'en contiennent pas.
  3. Vérifiez la couverture complète. Chaque identifiant des deux fichiers doit apparaître une fois dans le résultat : rapproché, non rapproché, dupliqué ou à réviser.
  4. Examinez les paires rapprochées. Confirmez que chaque paire indique les champs utilisés pour l'établir. Le montant seul ne suffit pas en présence de doublons.
  5. Recalculez tous les totaux en dehors du chat. Additionnez les sections de correspondances et d'exceptions directement à partir du résultat adossé aux sources.
  6. Recherchez les lignes réutilisées. Une ligne de relevé bancaire ne doit pas satisfaire deux lignes du grand livre, sauf si le rapprochement autorise et documente explicitement une correspondance un-à-plusieurs.
  7. Relancez manuellement un échantillon d'exceptions. Vérifiez en priorité les montants répétés, les dates adjacentes, les références vides, les extournes, les remboursements et les libellés modifiés.

Si le modèle ne peut pas retourner des identifiants de lignes stables, une couverture complète des sources et une liste d'exceptions reproductible, le résultat n'est pas prêt pour la clôture mensuelle ou la remise à un client. Utilisez-le comme piste d'investigation, pas comme rapprochement terminé.

Pour une comparaison plus large du même problème dans une autre interface de chat, consultez si ChatGPT peut rapprocher des fichiers CSV de relevés bancaires. Le nom du modèle change. L'exigence de vérification, non. Le problème connexe est pourquoi la correspondance par IA sans piste d'audit ne peut pas être fiable : un résultat plausible et un résultat prouvable sont deux livrables différents.

Ce qu'un rapprochement bancaire exact doit contenir

La fiabilité ne se résume pas à un pourcentage affiché en haut d'un rapport. C'est la capacité à inspecter le résultat jusqu'à la ligne source.

Un résultat exploitable contient :

  • Chaque ligne du fichier bancaire
  • Chaque ligne du fichier grand livre
  • Un lien visible entre chaque paire rapprochée
  • La base exacte de chaque correspondance
  • Des listes séparées pour les lignes présentes uniquement dans le relevé et uniquement dans le grand livre
  • Les candidats dupliqués et ambigus exclus des correspondances confirmées
  • Des comptages et des totaux recalculables à partir des lignes détaillées
  • Les valeurs sources originales conservées pour révision

Cette structure permet à une autre personne de reproduire la conclusion. Elle prévient également un échec courant : forcer le rapprochement à zéro en acceptant une correspondance plausible mais non étayée.

Claude ou Gemini peut suggérer que « Transaction Date » correspond à « Posting Date », expliquer pourquoi une fenêtre de tolérance de date peut être nécessaire, ou rédiger une liste de contrôle. Ces résultats restent en dehors des preuves finales. Ils sont consultatifs. La correspondance finale nécessite un processus déterministe qui lit les deux fichiers complets et expose chaque décision.

La réponse exacte est donc conditionnelle. Claude et Gemini peuvent aider à comprendre les données d'un relevé bancaire et produire une ébauche ressemblant à un rapprochement. Ils ne peuvent pas, par une simple réponse de chat généraliste, fournir la couverture complète des lignes, le registre de correspondance déterministe et les preuves prêtes pour l'audit nécessaires pour établir que le rapprochement est exact.