Dès qu'un fichier CSV source est modifié pendant un rapprochement en cours, chaque résultat de correspondance qui suit devient suspect.
Le problème ne se limite pas à la modification visible. C'est la perte d'une référence fiable.
Une ligne a peut-être été supprimée. Une date a peut-être été réinterprétée par Excel. Un identifiant de transaction a peut-être perdu son zéro de tête. Une ligne vide a peut-être décalé l'import. Un filtre a peut-être masqué des enregistrements avant l'enregistrement du fichier. Le rapprochement peut encore produire un résultat — mais ce résultat ne prouve plus ce qu'il prétend prouver.
Ne réparez pas d'abord le fichier modifié. Figez l'état actuel, récupérez ou réexportez le fichier CSV source d'origine, comparez les deux versions sur le plan structurel, puis relancez le rapprochement depuis la référence saine.
C'est la manière la plus sûre de récupérer un rapprochement après modification du fichier CSV source en cours de traitement, sans introduire une modification de données cachée dans le rapport final.
Classifiez la défaillance avant de toucher quoi que ce soit
La première tâche consiste à déterminer si le rapprochement a échoué à cause d'un vrai écart financier ou parce que le fichier source a changé sous le processus en cours.
Consultez ce tableau avant de toucher aux formules, aux mappages, aux filtres ou aux notes de correspondance manuelle.
| Symptôme | Type probable | Premier contrôle | Corriger ou conserver |
|---|---|---|---|
| Le nombre de correspondances a changé après l'enregistrement du CSV | Fichier source modifié | Comparer le nombre de lignes et de références avec l'export d'origine | Corriger en restituant la référence de base |
| Les totaux ont changé mais le nombre de lignes est identique | Montant erroné ou signe inversé | Comparer les totaux de la colonne montant et les valeurs négatives | Corriger avant de relancer |
| Les mêmes transactions apparaissent à des dates différentes | Date incorrecte | Comparer la première date, la dernière date et le format de date | Corriger si la date a été modifiée ; conserver seulement les décalages temporels réels |
| Certaines références affichent désormais des valeurs plus courtes | Fichier source modifié | Vérifier les zéros de tête et les identifiants longs | Corriger en réexportant, pas en retapant les identifiants |
| Le rapprochement exclut des lignes précédemment incluses | Erreur de périmètre ou de filtre | Vérifier les filtres, les lignes masquées et la plage de dates | Corriger la limite du fichier source |
| Une transaction apparaît deux fois après la modification | Doublon | Compter les clés en double et les paires montant-date en double | Corriger avant de relancer |
| Une transaction attendue est absente | Enregistrement manquant | Chercher d'abord par référence, puis par montant et date proche | Corriger si omise ; conserver seulement si elle est hors périmètre |
Cette distinction est importante : les décalages temporels et les modifications de données ne se traitent pas de la même façon.
Un décalage temporel peut être conservé. Un dépôt en transit, un règlement de carte en attente ou un virement qui arrive un jour plus tard peut rester dans le rapprochement comme écart justifié.
Un fichier source modifié ne peut pas être conservé comme explication. Il doit être corrigé ou remplacé avant de pouvoir se fier au résultat du rapprochement.
Figez les fichiers tels qu'ils sont
Avant toute récupération, préservez l'état du travail en cours.
Faites une copie de :
- Le fichier CSV source modifié
- Le deuxième fichier utilisé dans la comparaison
- Le classeur de rapprochement ou le fichier de travail
- Tout export produit depuis le rapprochement
- Toute note de correspondance manuelle ou d'exception
Renommez le fichier CSV modifié pour qu'il ne puisse pas être confondu avec l'export source. Un nom de fichier explicite suffit :
| Fichier | Rôle |
|---|---|
bank-export-edited-do-not-use.csv | Montre le fichier modifié à l'origine du problème |
ledger-export-working-copy.csv | Montre l'autre côté du rapprochement |
reconciliation-before-recovery.xlsx | Conserve les formules, les filtres et les notes de revue manuelle |
Le fichier modifié est une pièce à conviction. Il est peut-être erroné, mais il explique pourquoi le rapprochement en cours est devenu non fiable.
Ne l'écrasez pas. Ne continuez pas à travailler dedans. N'enregistrez pas une autre version par-dessus.
À ce stade, l'objectif n'est pas de finir vite le rapprochement. C'est d'immobiliser les données pendant que vous prouvez ce qui a changé.
Reconstituez la référence à partir de la source d'origine
La voie de récupération propre consiste à obtenir un nouvel export non modifié depuis le système source.
Si le fichier CSV provient d'une banque, retéléchargez l'export de relevé pour le même compte et la même période. S'il provient d'un processeur de paiement, réexportez le même rapport avec les mêmes filtres. S'il provient d'un logiciel comptable, exportez le même grand livre ou le même rapport de transactions avec la même plage de dates, la même base, la même devise et le même périmètre de compte.
Ce nouvel export ne devient la référence de récupération que s'il correspond aux limites de la comparaison d'origine.
Vérifiez ces champs avant de l'utiliser :
| Contrôle de référence | Ce qu'il faut comparer | Pourquoi c'est important |
|---|---|---|
| Compte ou source | Même compte bancaire, grand livre, plateforme ou rapport | Évite de comparer le mauvais jeu de données |
| Période | Même date de début et de fin | Évite que des écarts de délai ressemblent à des modifications |
| Nombre de lignes | Total des lignes de transaction hors en-têtes | Détecte les lignes supprimées, insérées ou filtrées |
| Nombre de références | Références de transaction non vides | Détecte les clés de correspondance cassées |
| Plage de dates | Dates de transaction les plus ancienne et la plus récente | Détecte un périmètre modifié ou des dates réinterprétées |
| Total des montants | Mouvement net ou total de la colonne montant concernée | Détecte les signes modifiés, les lignes supprimées ou les valeurs éditées |
| Nombre de doublons | Références en double ou combinaisons montant-date-référence en double | Détecte les lignes copiées ou les doublons à l'import |
| Lignes sans référence | Lignes sans la référence attendue | Détecte les lignes qui ne peuvent pas être rapprochées de façon fiable |
Si le système source a changé depuis le premier export, le nouveau fichier peut ne pas être identique. Ce n'est pas rédhibitoire. Cela signifie que vous devez séparer les changements du système des modifications du fichier.
Par exemple, un rapport de processeur de paiement peut désormais inclure un ajustement arrivé en retard, qui n'était pas disponible lors du premier export. Ce n'est pas la même chose que quelqu'un qui a modifié une cellule d'un CSV. C'est un nouvel enregistrement source. Notez-le comme un écart de périmètre, puis décidez si la période de rapprochement doit l'inclure.
La référence est fiable seulement quand vous pouvez en justifier les limites : même source, même période, mêmes paramètres de rapport, mêmes colonnes, et même total financier ou variation justifiée.
Comparez le CSV modifié à la référence
Une fois l'export propre obtenu, comparez-le au fichier CSV modifié avant de relancer le rapprochement.
Ne commencez pas par la comparaison ligne à ligne. Commencez par les contrôles structurels. Ils sont plus rapides et éliminent des catégories entières de défaillances.
| Contrôle | Référence propre | CSV modifié | Ce qu'une différence signifie |
|---|---|---|---|
| Lignes de transaction | 4,812 | 4,809 | Des lignes ont été supprimées, filtrées ou perdues |
| Références non vides | 4,812 | 4,780 | Des clés de correspondance ont été modifiées ou effacées |
| Références en double | 0 | 3 | Des lignes ont été copiées ou des identifiants endommagés |
| Date la plus ancienne | 2026-05-01 | 2026-05-02 | Les enregistrements du premier jour sont absents ou filtrés |
| Date la plus récente | 2026-05-31 | 2026-05-31 | La limite de fin semble intacte |
| Montant net | 184,229.10 | 184,010.55 | Un ou plusieurs montants ont changé ou des lignes sont manquantes |
Ce tableau vous indique où chercher ensuite.
Si le nombre de lignes a changé, cherchez les lignes manquantes ou insérées. Si le nombre de références a changé, inspectez la colonne de référence. Si les totaux ont changé, comparez la colonne montant. Si la plage de dates a changé, vérifiez si Excel a converti les dates ou si un filtre a retiré les dates limites.
Les modifications courantes dans un CSV sont silencieuses :
- Les identifiants numériques longs sont convertis en notation scientifique
- Les zéros de tête sont supprimés des références
- Les dates basculent entre le format JJ/MM et MM/JJ
- Les montants stockés en texte deviennent des nombres
- Les signes négatifs passent d'une colonne débit séparée à une seule colonne montant
- Des lignes vides sont insérées au-dessus de l'en-tête
- Des filtres masqués sont enregistrés dans le fichier de travail
- Des notes supplémentaires sont saisies dans une colonne que l'import utilise pour la correspondance
- Les lignes sont triées sans sélectionner l'intégralité du jeu de données
Cette dernière modification est particulièrement destructrice. Si une seule colonne est triée indépendamment, les dates, les références et les montants peuvent se retrouver attachés aux mauvaises lignes. Le fichier peut encore sembler complet. Le nombre de lignes et le total peuvent même rester proches. Mais les relations entre transactions sont brisées.
Si vous constatez ce type de modification, ne tentez pas de réparer le CSV manuellement. Réexportez et relancez.
Identifiez les lignes exactement modifiées, uniquement après avoir stabilisé la structure
La comparaison ligne à ligne ne vient qu'après que les contrôles structurels sont satisfaisants.
Utilisez d'abord l'identifiant le plus fort :
- Identifiant de transaction ou référence source
- Montant exact plus date exacte
- Montant exact plus date proche
- Libellé ou mémo
- Position dans les lignes environnantes
La référence est la meilleure clé quand elle est intacte. Montant plus date est utile quand les références sont absentes ou endommagées, mais c'est une clé plus faible. Deux transactions peuvent partager le même montant à la même date. Le libellé est encore plus faible, car les banques et les processeurs reformulent les descriptions entre les exports.
Établissez un tableau de comparaison comme celui-ci :
| Référence | Montant référence | Montant modifié | Date référence | Date modifiée | Statut |
|---|---|---|---|---|---|
| TXN-10481 | 242.18 | 242.18 | 2026-05-08 | 2026-05-08 | Inchangé |
| TXN-10482 | 119.00 | 119.00 | 2026-05-08 | 2026-08-05 | Date modifiée |
| TXN-10483 | 84.50 | 48.50 | 2026-05-09 | 2026-05-09 | Montant modifié |
| TXN-10484 | 300.00 | Absent | 2026-05-09 | Absent | Absent du fichier modifié |
Le travail de récupération devient alors précis.
Vous ne dites plus « Le CSV a été modifié. » Vous dites : « La version modifiée a changé une date, changé un montant, et supprimé une ligne. » C'est le niveau de détail nécessaire avant de décider si le rapprochement précédent peut être récupéré.
Si le problème se résume à un enregistrement manquant entre deux fichiers financiers, utilisez le même ordre de recherche décrit dans comment retrouver une transaction manquante entre deux fichiers financiers rapidement : référence d'abord, puis montant et date exacts, puis dates proches, puis doublons ou problèmes de périmètre.
Décidez si l'ancien rapprochement peut être utilisé
Dans la plupart des cas, un rapprochement doit être considéré comme invalide dès lors qu'un fichier CSV source a été modifié.
Il existe des exceptions, mais elles sont étroites.
| Ce qui a changé | L'ancien rapprochement est-il fiable ? | Action de récupération |
|---|---|---|
| Le nom du fichier seulement | En général oui | Vérifiez le hachage ou les contrôles structurels, puis continuez |
| L'ordre de tri seulement, toutes les colonnes conservées ensemble | Parfois | Relancez la correspondance si la position des lignes a été utilisée |
| Un filtre masqué appliqué, lignes source inchangées | Non | Retirez le filtre ou réexportez, puis relancez |
| Une colonne de notes ajoutée hors de la plage de correspondance | Parfois | Vérifiez que le mappage d'import n'a pas été décalé |
| Un montant, une date ou une référence modifié | Non | Réexportez et relancez |
| Des lignes supprimées ou insérées | Non | Réexportez et relancez |
| Des colonnes renommées ou déplacées | Non avant vérification du mappage | Remappez et relancez depuis la référence |
| Des identifiants reformatés par Excel | Non | Réexportez en conservant les identifiants en texte |
La question clé est de savoir si la modification a touché un champ utilisé pour la correspondance, le périmètre ou la totalisation.
Ce sont les champs de contrôle :
- Identifiant de transaction
- Référence
- Date
- Montant
- Devise
- Compte
- Identifiant client ou fournisseur
- Indicateur débit ou crédit
- Statut
- Période de rapport
Si l'un de ces champs a changé, le résultat du rapprochement précédent ne peut pas tenir. Le résultat peut encore être proche, mais proche n'est pas la même chose que prêt pour l'audit.
Si le rapprochement a déjà produit un résultat erroné et que vous devez isoler le point de rupture, appliquez la même logique référence-d'abord décrite dans pourquoi votre rapprochement était erroné et comment retrouver l'endroit où il a déraillé. Partez du dernier état fiable, puis testez ce qui a changé après ce point.
Relancez depuis la référence propre
Une fois le fichier CSV source propre obtenu, relancez le rapprochement depuis le début.
Utilisez le même deuxième fichier qu'avant, sauf si ce fichier a lui aussi changé. Si les deux côtés ont changé, figez les deux versions modifiées et réexportez les deux références. Ne mélangez pas un fichier propre avec un fichier de travail non vérifié.
La relance doit suivre cet ordre :
| Étape | Action | Contrôle |
|---|---|---|
| 1 | Chargez le fichier CSV source propre | Vérifiez le nombre de lignes, la plage de dates et le total des montants |
| 2 | Chargez le fichier de comparaison | Vérifiez les mêmes contrôles sur le second fichier |
| 3 | Confirmez les clés de correspondance | Utilisez la référence en priorité lorsqu'elle est disponible |
| 4 | Lancez la correspondance | Séparez les statuts : correspondances, absences, doublons, écarts de montant |
| 5 | Comparez le résultat avec la relance échouée | Justifiez chaque différence significative |
| 6 | Enregistrez le rapport récupéré | Gardez-le séparé de la version échouée |
Ne copiez pas les décisions de correspondance manuelle depuis la relance échouée, sauf si chaque décision est toujours valide par rapport à la référence propre.
Les notes manuelles sont des éléments de preuve utiles, pas des preuves en tant que telles. Une note qui indiquait « rapproché par montant et date » pouvait être exacte par rapport au fichier modifié et fausse par rapport au fichier propre. Revérifiez toute substitution manuelle qui a influé sur le résultat final.
Le rapport récupéré doit indiquer :
- Le fichier CSV source propre utilisé
- Le fichier de comparaison utilisé
- Le nombre de lignes de chacun des deux fichiers
- La plage de dates de chacun des deux fichiers
- Le total des montants ou le mouvement net de chacun des deux fichiers
- Les lignes rapprochées
- Les lignes manquantes
- Les doublons
- Les écarts de montant
- Les écarts de date
- Les décalages temporels réels reportés
- Les erreurs corrigées avant clôture
Ce résultat est plus solide que le rapprochement d'origine, car il documente le chemin de récupération. Il ne cache pas la défaillance. Il prouve comment elle a été contenue.
Ne corrigez pas le CSV modifié, sauf si aucun réexport n'est possible
Il arrive qu'aucun export propre ne soit disponible. Le portail bancaire peut ne plus proposer le même fichier. Le système source a peut-être changé. Le client a peut-être envoyé un CSV sans chemin de téléchargement direct.
Si aucune source n'est disponible pour un réexport, traitez le CSV modifié comme une pièce à conviction endommagée, pas comme un fichier de travail normal.
Utilisez tous les documents indépendants disponibles :
- Relevé bancaire au format PDF
- Rapport de transactions de la plateforme
- Export du grand livre comptable
- Copie précédemment enregistrée du CSV
- Pièce jointe par e-mail
- Historique de téléchargement
- Résultat du rapprochement depuis la dernière relance fiable
- Fichier d'origine envoyé par le client, si disponible
Reconstituez ensuite un fichier source contrôlé à partir de ces éléments. Indiquez clairement qu'il s'agit d'une reconstitution. Ne faites pas croire qu'il s'agit de l'export d'origine.
Le fichier reconstitué doit être accompagné d'un journal de révision :
| Élément reconstitué | Éléments de preuve utilisés | Modification apportée | Note du réviseur |
|---|---|---|---|
| Date de TXN-10482 | Relevé PDF bancaire et export du grand livre | Date rétablie au 2026-05-08 | Le CSV modifié indiquait 2026-08-05 |
| Montant de TXN-10483 | Rapport du processeur | Montant rétabli à 84.50 | Le CSV modifié indiquait 48.50 |
| Ligne TXN-10484 | Pièce jointe de l'export précédent | Ligne manquante réinsérée | Ligne absente du CSV modifié |
C'est plus lent qu'un réexport. Cette méthode doit être le recours de dernier ressort, pas le réflexe par défaut.
Ce qu'il faut documenter avant de clôturer la récupération
La note de clôture de la récupération doit être courte et précise.
Elle doit répondre à cinq questions :
| Question | Réponse à documenter |
|---|---|
| Qu'est-ce qui a changé ? | Le fichier CSV source a été modifié après le début du rapprochement |
| Comment cela a-t-il été détecté ? | Le nombre de lignes, de références, la plage de dates, les totaux ou la comparaison des lignes a révélé un écart |
| Quelle référence a été utilisée ? | Le réexport non modifié ou le fichier source reconstitué |
| Qu'est-ce qui a été relancé ? | Le rapprochement complet depuis la référence vérifiée |
| Qu'est-ce qui reste en suspens ? | Seulement les décalages temporels réels ou les exceptions non résolues |
N'écrivez pas un journal exhaustif de toutes les tentatives. La note de clôture doit permettre à quelqu'un de faire confiance au résultat récupéré.
Une bonne note ressemble à ceci :
Le fichier CSV bancaire d'origine a été modifié pendant le rapprochement. Le fichier modifié comportait trois lignes en moins, un montant changé et une date changée par rapport au relevé bancaire réexporté. Le rapprochement a été relancé à partir du fichier CSV source réexporté pour le même compte et la même période. Le rapport final sépare les lignes rapprochées, les enregistrements manquants et les décalages temporels. Aucun résultat du fichier modifié n'a été repris dans le rapport récupéré sans revérification.
C'est suffisant.
Le lecteur voit la rupture, la référence de récupération et le contrôle final.
Où s'arrête la récupération
La récupération est terminée quand le rapprochement final peut être tracé jusqu'à un fichier source fiable.
Cela signifie :
- Le CSV modifié est conservé mais n'est pas utilisé comme référence finale
- L'export propre ou le fichier reconstitué est clairement identifié
- Le nombre de lignes, de références, la plage de dates, les totaux, les doublons et les lignes sans référence ont été vérifiés
- Le rapprochement a été relancé depuis la référence vérifiée
- Les décalages temporels sont séparés des erreurs
- Les substitutions manuelles de la relance échouée ont été revérifiées
- Le rapport final explique ce qui a changé et ce qui reste non résolu
Arrêtez-vous là.
Ne continuez pas à ajuster l'ancien fichier jusqu'à ce que les totaux concordent. Ne forcez pas une ligne d'équilibrage parce que l'écart est faible. Ne clôturez pas depuis un fichier dont l'historique source est incertain.
Le CSV modifié a créé un problème d'intégrité des données. La récupération n'est pas terminée quand les chiffres semblent proches. Elle est terminée quand la source, le périmètre et la relance peuvent être défendus.
