Ce n'est pas Wave qui est en cause. Un export Wave et un relevé bancaire décrivent les mêmes mouvements de trésorerie, mais pas de la même façon : dates différentes, règles de signe différentes, colonnes souvent différentes aussi.

Quand les exports CSV Wave ne correspondent pas aux relevés bancaires téléchargés, l'écart existe en général avant même qu'une formule soit lancée. L'un des fichiers peut être un rapport de compte filtré. L'autre peut être un relevé brut de banque. Une colonne de dates peut contenir de vraies dates Excel ; l'autre, du texte. Un fichier peut afficher l'argent entrant comme un débit. L'autre, comme un dépôt positif.

La solution tient en trois décisions : choisir le bon export Wave, normaliser les dates et les montants selon une règle commune, puis ne comparer que les lignes qui doivent effectivement se correspondre. Une fois ces trois points réglés, la plupart des lignes « sans correspondance » s'expliquent d'elles-mêmes.

Lire l'écart avant de modifier quoi que ce soit

Commencez par identifier ce à quoi vous avez affaire. Un problème de stockage de dates ne se corrige pas de la même façon qu'un problème de signe. Un problème de périmètre de rapport ne se traite pas comme une incohérence de description.

Ce tableau précise la nature de l'écart avant de chercher à le corriger. C'est important : la bonne étape suivante dépend du diagnostic.

Pour un premier contrôle rapide, utilisez =TYPE(A2) sur les champs que vous comptez rapprocher.

• 1 signifie qu'Excel a stocké un nombre.
• 2 signifie qu'Excel a stocké du texte.

Cette réponse est plus utile que ce que la cellule affiche à l'écran. Une date qui semble correcte mais renvoie 2 reste du texte. Un montant affiché avec des séparateurs qui renvoie 2 ne se comportera pas comme un vrai montant.

Choisir l'export Wave qui peut réellement être rapproché d'un relevé bancaire

Beaucoup d'écarts Wave commencent par le mauvais export.

Un relevé bancaire est ciblé : un seul compte bancaire ou de carte de crédit, une plage de dates précise, uniquement les mouvements réglés. Un export Wave n'est pas toujours aussi ciblé. Si vous exportez l'ensemble des données comptables de l'entreprise, vous récupérez des écritures comptables sur l'ensemble du plan de comptes, et non un fichier calqué sur un relevé bancaire.

Cette distinction est plus importante qu'on ne le croit.

Si vous exportez l'intégralité de Wave et que vous le comparez à un seul relevé bancaire, les nombres de lignes seront faux avant même d'examiner une date ou un montant. Les virements internes, les comptes hors-banque, les écritures d'ouverture et les journaux sans rapport avec le compte peuvent tous figurer dans le fichier Wave, alors que le relevé bancaire n'en sait rien.

La première question n'est donc pas « quelle colonne dois-je rapprocher ? ». C'est : « est-ce que j'ai exporté le même périmètre dans les deux systèmes ? »

Pour cette tâche, le point de départ le plus fiable est généralement :

1. Un export de type « transactions du compte » dans Wave, filtré sur le compte bancaire exact à rapprocher.
2. La même période que le relevé bancaire téléchargé.
3. Une seule devise et un seul compte.

Si l'un de ces trois critères diverge, le reste du travail de nettoyage devient peu fiable.

Normaliser les dates avant toute comparaison de lignes

Il y a ici deux problèmes de dates, et ils sont différents.

Le premier est le stockage : un côté peut contenir une vraie date, l'autre du texte. Le second est la signification : Wave peut afficher la date de saisie de l'écriture comptable, tandis que le relevé bancaire affiche la date de valeur ou la date d'enregistrement du mouvement réglé.

Commencez par le stockage.

Si le fichier bancaire contient une date au format texte dd/mm/yyyy, convertissez-la explicitement avec :

=DATE(DROITE(B2;4);STXT(B2;4;2);GAUCHE(B2;2))

Si le fichier bancaire contient une date au format texte mm/dd/yyyy, utilisez :

=DATE(DROITE(B2;4);GAUCHE(B2;2);STXT(B2;4;2))

Si un export Wave vous donne une date au format texte ISO comme 2026-05-01, utilisez :

=DATE(GAUCHE(C2;4);STXT(C2;6;2);DROITE(C2;2))

Ces formules extraient directement les composantes de la date. Elles ne demandent pas à Excel de deviner le format à partir des paramètres régionaux. C'est l'option la plus sûre quand vous manipulez des fichiers CSV issus de systèmes différents.

Attention aux dates ambiguës comme 01/05/2026. Cette chaîne n'est pas explicite d'elle-même : elle peut signifier le 1er janvier ou le 1er mai selon la source. Avant de la convertir, vérifiez :

• si le fichier contient aussi une date comme 31/05/2026, ce qui confirme le format jour-premier
• si l'export bancaire intitule le champ Posted Date, Value Date ou Transaction Date
• si l'affichage d'origine dans Wave ou dans le portail bancaire confirme le format

Traitez ensuite la signification.

Même une fois que les deux fichiers contiennent de vraies dates, celles-ci peuvent légitimement différer. Le côté Wave peut refléter la date de saisie de la transaction ; le côté bancaire, la date à laquelle la banque l'a enregistrée. Cet écart est courant en fin de semaine, en fin de mois ou lors de règlements par des prestataires de paiement.

Si le montant correspond mais que la date diffère d'un ou deux jours, ne marquez pas la ligne comme manquante. Demandez-vous d'abord si vous êtes face à un écart entre date de transaction et date de valeur. C'est une catégorie d'explication, pas une anomalie.

Si le problème principal est que les deux fichiers ne s'accordent pas sur le rôle de leurs colonnes, les fichiers CSV bancaires avec des noms de colonnes différents correspondent au problème adjacent.

Normaliser les signes et la structure des montants selon une règle commune

Les écarts de montant sont le plus souvent des écarts de structure déguisés.

Le relevé bancaire peut vous donner une seule colonne Amount signée, ou des colonnes Deposit et Withdrawal séparées. Le côté Wave peut vous donner une seule colonne de montant dans certains exports, et des colonnes Debit et Credit séparées dans d'autres. Ces formats ne sont pas interchangeables tant que vous n'avez pas forcé les deux fichiers dans la même convention de signe.

Choisissez une règle et appliquez-la partout :

• argent entrant dans le compte bancaire = positif
• argent sortant du compte bancaire = négatif

Si le fichier bancaire sépare Withdrawal et Deposit, convertissez-le en ligne avec :

=SI(E2<>"";-VALEUR(SUBSTITUE(E2;",";""));VALEUR(SUBSTITUE(F2;",";")))

Vous obtenez ainsi une seule colonne de montant signé à partir de deux colonnes bancaires séparées.

Si le rapport Wave pour le compte bancaire sépare Debit et Credit, convertissez-le avec :

=SI(G2<>"";VALEUR(SUBSTITUE(G2;",";""));-VALEUR(SUBSTITUE(H2;",";")))

Pour un compte d'actif bancaire, cette règle fonctionne en général, car les débits augmentent le solde du compte et les crédits le diminuent. Une fois que les deux fichiers suivent la même logique de signe, beaucoup de faux écarts disparaissent immédiatement.

Si l'un des côtés possède déjà une seule colonne de montant mais qu'Excel l'a stockée comme du texte, convertissez-la directement :

=VALEUR(SUBSTITUE(D2;",";"))

Ne sautez pas le SUBSTITUE quand le fichier contient des séparateurs de milliers. VALEUR("1,250.00") fonctionne souvent, mais un nettoyage explicite est plus sûr quand le format d'export change d'un mois à l'autre.

L'objectif de cette étape n'est pas la cohérence cosmétique. C'est de s'assurer que le même mouvement de trésorerie a la même signification numérique dans les deux fichiers. Tant que ce n'est pas le cas, le rapprochement sur les montants ne dit presque rien.

Rapprocher les lignes qui doivent se correspondre, pas chaque champ du fichier

Un relevé bancaire et un export Wave ne sont pas tenus d'avoir une symétrie parfaite ligne par ligne. Certains champs servent au rapprochement direct. D'autres ne servent qu'à expliquer la ligne une fois le mouvement de trésorerie identifié.

La clé de rapprochement la plus fiable en premier passage est généralement :

1. le montant signé normalisé
2. la bonne base de date
3. une référence ou un libellé si l'un existe

Le libellé doit rester dans la couche de vérification. Les références bancaires sont inconsistantes. Les descriptions Wave peuvent être plus propres, plus courtes ou modifiées après l'import. Si vous faites du libellé la clé principale trop tôt, deux lignes correctes peuvent paraître sans correspondance car les mots diffèrent même si les montants sont identiques.

C'est aussi là qu'apparaissent les problèmes de correspondance un-à-plusieurs. Un virement enregistré dans les livres peut créer plusieurs lignes comptables dans Wave, tandis que le relevé bancaire n'affiche qu'un seul mouvement réglé. Un virement groupé ou un encaissement consolidé de prestataire peut produire le même résultat. Ce n'est pas un signe que la trésorerie est fausse. C'est que les fichiers enregistrent l'événement à des niveaux différents.

Ce que signifient les écarts résiduels

Une fois le périmètre, les dates et les signes normalisés, les exceptions restantes deviennent beaucoup plus lisibles.

C'est à ce stade que le rapprochement devient défendable. Vous ne dites plus « ces fichiers CSV ne correspondent pas ». Vous dites : « ces trois lignes présentent un décalage de date de valeur, celle-ci est une erreur de conversion de signe, et ces deux-là appartiennent à une paire de virement ». C'est une vraie réponse.

D'où vient vraiment l'écart dans la plupart des rapprochements Wave / banque

En pratique, les causes récurrentes sont généralement les suivantes :

• Le mauvais export Wave a été utilisé : le périmètre du fichier est plus large que le relevé bancaire.
• L'un des fichiers stocke les dates sous forme de texte et l'autre sous forme de vraies dates.
• Les deux fichiers n'utilisent pas la même signification de date : date de transaction contre date de valeur.
• Le fichier bancaire applique une règle de signe unique, tandis que le rapport Wave utilise des colonnes débit et crédit.
• Un virement ou une saisie groupée crée plusieurs lignes Wave pour un seul mouvement bancaire.
• Les descriptions diffèrent suffisamment pour que le rapprochement par texte génère de faux écarts.

Remarquez ce qui ne figure pas dans cette liste : le problème est rarement que Wave et la banque sont en désaccord sur la réalité. Le problème vient du fait que les fichiers sont structurés différemment, et que la comparaison a démarré avant que cette structure soit normalisée.

Si la vraie contrainte est de reconstruire manuellement le même rapprochement chaque mois, comparer deux fichiers CSV de relevés bancaires sans formules est l'étape suivante après avoir compris le schéma des écarts lui-même.