Les dates ne sont pas fausses. Stripe horodate chaque transaction en UTC ; votre relevé bancaire CSV enregistre la date à laquelle les fonds ont été portés au crédit en heure locale. Quand un paiement tombe près de minuit, ce sont deux jours calendaires différents. Et si Stripe regroupe plusieurs transactions dans un même virement, la comparaison ligne par ligne échoue encore plus vite.

C'est pourquoi vous pouvez voir une transaction Stripe au 31 mai, une ligne bancaire au 1er juin, et constater qu'il s'agit pourtant du même mouvement. L'écart n'est presque jamais de l'argent manquant. C'est une combinaison de décalage horaire, de délais de virement et du fait que les lignes de transactions Stripe ne sont pas les mêmes que les lignes d'un relevé bancaire.

Premier diagnostic : quel type d'écart de dates avez-vous ?

Avant de modifier quoi que ce soit dans Excel, identifiez le cas auquel vous êtes confronté. Un même écart peut avoir plusieurs origines, et seules certaines d'entre elles relèvent d'un problème UTC pur.

Seules les deux premières lignes correspondent à de vrais décalages de fuseau horaire. La troisième est un délai de règlement. La quatrième est un problème d'import de date en texte. La cinquième est celle qui fait perdre le plus de temps, car elle ressemble à un problème de dates alors qu'il s'agit d'un problème de structure de fichier.

Quelle date Stripe êtes-vous en train de comparer ?

Les exports Stripe n'utilisent pas une unique « date de transaction ». Stripe expose plusieurs dates qui décrivent des moments différents dans le cycle de vie du virement. Si vous comparez la mauvaise au relevé bancaire, l'écart est créé avant qu'Excel n'ait fait quoi que ce soit.

C'est l'étape que beaucoup de guides sautent. Une ligne de relevé bancaire est un événement de trésorerie. Un export de transactions Stripe est un événement de transaction. Un export de rapprochement de virement se situe entre les deux. Si vous exportez un CSV de transactions Stripe, prenez la colonne created et la comparez directement à la date du relevé bancaire, vous comparez le moment où le paiement est entré dans Stripe à la date à laquelle les fonds sont arrivés en banque. Ce sont deux événements différents, même avant de tenir compte d'UTC.

C'est pourquoi la bonne méthode suit cet ordre :

1. Rapprochez le dépôt bancaire du virement Stripe.
2. Rapprochez le contenu du virement aux transactions Stripe sous-jacentes.
3. Rapprochez ces transactions aux commandes, factures ou lignes de grand livre si vous avez besoin d'une justification au niveau de la transaction.

Si vous sautez l'étape intermédiaire, le problème de fuseau horaire paraît plus important qu'il ne l'est.

Convertissez l'horodatage Stripe avant toute comparaison

Une fois que vous avez identifié le bon champ côté Stripe, convertissez-le en appliquant la même logique de date que le fichier bancaire. Ne commencez pas par le formatage. Vérifiez d'abord si Excel a importé la valeur en tant que vrai horodatage ou en tant que texte.

Utilisez =TYPE(A2) sur la cellule contenant la date Stripe.

• 1 signifie qu'Excel reconnaît un numéro de série de date-heure.
• 2 signifie qu'Excel voit du texte : vous devez l'analyser avant de pouvoir faire la moindre comparaison.

Si la valeur Stripe en A2 est du texte au format 2026-05-01 23:47:18 UTC, construisez l'horodatage UTC explicitement :

=DATE(GAUCHE(A2,4),STXT(A2,6,2),STXT(A2,9,2))+TEMPS(STXT(A2,12,2),STXT(A2,15,2),STXT(A2,18,2))

Vous obtenez l'horodatage UTC sous forme de valeur date-heure Excel. Convertissez-le ensuite en heure locale en appliquant le décalage du compte. Si votre vue comptable est UTC-4, soustrayez quatre heures :

=DATE(GAUCHE(A2,4),STXT(A2,6,2),STXT(A2,9,2))+TEMPS(STXT(A2,12,2),STXT(A2,15,2),STXT(A2,18,2))-TEMPS(4,0,0)

Si votre fuseau horaire de reporting local est UTC+2, ajoutez deux heures :

=DATE(GAUCHE(A2,4),STXT(A2,6,2),STXT(A2,9,2))+TEMPS(STXT(A2,12,2),STXT(A2,15,2),STXT(A2,18,2))+TEMPS(2,0,0)

Une fois l'horodatage local correct, réduisez-le à la date calendaire si le relevé bancaire CSV ne contient qu'une date :

=ENT(B2)

Mettez ce résultat au format date. Vous comparez maintenant le jour local impliqué par l'horodatage Stripe, et non le jour UTC brut.

Si la date Stripe est déjà une vraie valeur date-heure Excel en A2, n'analysez pas à nouveau. Appliquez directement le décalage :

=A2-TEMPS(4,0,0)

Le fichier bancaire demande le même soin. Si le relevé bancaire CSV a importé 01/05/2026 comme texte, déterminez si la source utilise le format dd/mm/yyyy ou mm/dd/yyyy avant de convertir.

Si la banque utilise dd/mm/yyyy :

=DATE(DROITE(C2,4),STXT(C2,4,2),GAUCHE(C2,2))

Si la banque utilise mm/dd/yyyy :

=DATE(DROITE(C2,4),GAUCHE(C2,2),STXT(C2,4,2))

N'utilisez pas DATEVAL tant que vous n'avez pas identifié le format d'export de la banque. Une valeur comme 01/05/2026 n'est pas auto-explicite. Elle peut signifier le 1er mai ou le 5 janvier selon le système source et les paramètres régionaux d'Excel.

Un avertissement mérite plus d'attention que la plupart des guides ne lui en accordent : un décalage fixe -TEMPS(4,0,0) ou -TEMPS(5,0,0) est fiable uniquement si la plage de dates reste dans une seule période d'heure d'été. Si l'export couvre un changement d'heure, un seul décalage peut corriger la moitié du fichier et fausser l'autre moitié. Dans ce cas, découpez le fichier par période ou utilisez un rapport Stripe qui expose déjà la colonne du fuseau horaire du compte, et conservez la version _utc uniquement comme référence d'audit.

Rapprochez le virement à la banque avant de toucher aux transactions individuelles

Une fois les horodatages normalisés, la question suivante est celle du niveau de rapprochement. Si le relevé bancaire CSV contient un seul dépôt net et le fichier Stripe des transactions individuelles, remboursements et commissions, vous n'avez toujours pas de correspondance ligne par ligne. Vous avez une relation un-à-plusieurs.

La ligne bancaire doit d'abord être rapprochée d'un rapport de virement Stripe. Ensuite, les transactions incluses dans ce virement expliquent le montant.

Supposons que votre relevé bancaire CSV affiche cette ligne :

Votre export de transactions Stripe peut contenir trente-sept lignes créées entre 2026-05-31 21:00:00 UTC et 2026-06-01 03:00:00 UTC. Si vous comparez ces dates de transactions directement à la ligne bancaire du 1er juin, vous conclurez que de nombreuses lignes sont « décalées d'un jour ». Certaines le sont. Mais le fait le plus important est qu'aucune de ces lignes n'est censée correspondre individuellement à la ligne bancaire. Elles font partie d'un lot de virement.

La bonne justification ressemble à ceci :

• L'export de virement Stripe affiche un virement net de 4,820.25.
• Le champ du virement qui indique l'arrivée prévue en banque s'aligne avec la fenêtre d'imputation bancaire.
• Les transactions détaillées de ce virement s'additionnent pour donner le même montant net après commissions, remboursements et litiges.

À ce stade, le problème de dates retrouve sa juste proportion. C'est une étape de normalisation, pas l'intégralité du rapprochement.

Si vous avez besoin d'explorer le côté virement plus en détail, rapprocher un CSV de virement Stripe de votre relevé bancaire et rapprocher un relevé bancaire aux virements Stripe quand les dates diffèrent couvrent le flux du dépôt depuis l'autre sens.

Les cas limites qui créent encore de faux écarts après la conversion

Convertir Stripe en heure locale résout le premier niveau du problème. Pas tous les niveaux. Plusieurs situations génèrent encore des ruptures de dates apparentes, même après que le calcul de fuseau horaire est correct.

Filtrage en fin de mois

Celui-ci piège des équipes compétentes parce que le tableau semble propre. Vous exportez le relevé bancaire de mai. Puis vous exportez Stripe pour mai en UTC. Les transactions locales de fin de soirée du 31 mai peuvent apparaître comme étant le 1er juin dans Stripe, ce qui les exclut du filtre Stripe même si elles appartiennent à votre clôture de mai en heure locale. Ajoutez un tampon d'un jour de chaque côté de la période Stripe, convertissez en date locale, puis filtrez la colonne de date convertie sur le mois que vous clôturez.

Imputation en week-end ou jour férié

Un virement peut être effectif le vendredi et n'arriver en banque que le lundi. Ce n'est pas un champ de date erroné. C'est le traitement bancaire. Si le montant du virement et le motif de référence correspondent, traitez l'écart de dates comme un délai de règlement, sauf si les fonds manquent encore après la fenêtre bancaire normale.

Remboursements et litiges arrivant plus tard

Le paiement d'origine peut appartenir à un virement, tandis que le remboursement ou le litige touche un virement ultérieur. Quand on tente de rapprocher le relevé bancaire uniquement aux dates de création des paiements, ces réductions ultérieures ressemblent à des écarts inexpliqués. Ils ne le sont pas. Ils appartiennent à un lot de virement postérieur et doivent y être tracés.

Colonnes de fuseau horaire mixtes

Certains exports Stripe peuvent afficher à la fois les versions en heure locale et _utc du même champ. Si vous construisez des formules sur une colonne ce mois-ci et sur l'autre le mois suivant, le classeur produira des incohérences qui ressembleront à des erreurs dans les données source. Choisissez une norme et tenez-vous-y pour tout le rapprochement.

Dommages au copier-coller

Si quelqu'un colle des lignes Stripe dans une feuille au lieu d'importer le CSV, Excel peut silencieusement supprimer le contexte de fuseau horaire, convertir les horodatages en valeurs d'affichage locales, ou les stocker comme texte. Quand la formule commence à échouer uniquement après un collage, le fichier source est peut-être intact et c'est la copie dans la feuille qui a changé.

Quand le travail dans le tableau devient le vrai problème

Cet écart est gérable quand vous tracez un seul virement. Il devient coûteux quand chaque mois exige le même nettoyage : analyser l'horodatage Stripe, le convertir en heure locale, tamponner la période, séparer les dates de virement des dates de transaction, puis expliquer pourquoi un dépôt contient des dizaines de lignes sous-jacentes.

La norme à atteindre n'est pas « chaque date Stripe doit être égale à la date bancaire ». La norme, c'est que chaque dépôt bancaire soit rattaché au bon virement Stripe, que chaque virement soit expliqué par les transactions qu'il contient, et que tout écart de dates restant soit classé comme décalage horaire, délai de règlement, ou exception réelle nécessitant une correction.