Le fichier CSV de litiges Stripe ne manque pas vos commandes. Il décrit la même vente à travers les identifiants de litige et de charge Stripe, alors que votre tableau de commandes est généralement construit autour d'un numéro de commande interne. Si vous tentez de faire correspondre directement les lignes dp_ avec les numéros de commande, chaque ligne semble erronée — même quand tous les enregistrements sont bel et bien là.
Pour recouper un export CSV de litiges Stripe avec votre tableau de commandes, vous avez besoin de la charge comme lien. Une ligne de litige appartient d'abord à une charge, puis à une commande. En suivant cette chaîne, vous pouvez identifier quelle vente a été contestée, si le montant contesté correspond à la totalité de la commande ou seulement à une partie, et quels enregistrements il vous manque encore pour constituer un dossier.
Ce que la ligne de litige vous dit vraiment
Avant de commencer le recoupement, identifiez la référence sur laquelle vous travaillez vraiment. Les exports de litiges Stripe et les exports de commandes partagent rarement un nom de colonne commun.
| Ce que vous voyez dans le CSV de litiges | Ce que Stripe entend par là | Ce que contient généralement votre fichier de commandes | Ce qui se passe si vous faites correspondre directement |
|---|---|---|---|
dp_1... dans la colonne id | L'identifiant du dossier de litige | #10482 ou ORD-10482 | Aucune correspondance. Ce sont des types d'objets différents. |
ch_1... dans une colonne de charge | Le paiement original réussi | stripe_charge_id, payment ref, ou une colonne passerelle | C'est le meilleur lien direct si votre export de commandes l'a conservé. |
pi_3... ou une référence de payment intent | Le flux de paiement lié à la charge | payment_intent, données de session de paiement, ou une référence passerelle | Bon lien si l'ID de charge n'est pas enregistré sur la ligne de commande. |
| Montant du litige inférieur au total de la commande | Une contestation partielle du paiement original | Montant total dans le tableau des ventes | Semble être une mauvaise correspondance de montant, à moins de comparer séparément la charge originale et la partie contestée. |
| Litige créé des jours ou des semaines après la vente | La date d'ouverture de la rétrofacturation | La date de commande originale | Semble pointer vers la mauvaise vente si vous faites correspondre par date seule. |
Si votre premier essai était RECHERCHEV(dispute_id; orders; ...), le tableur a fait exactement ce qu'on lui demandait. Les valeurs sont différentes. Le problème, c'est la clé de correspondance, pas la formule.
Réunissez les fichiers qui créent le lien
Deux fichiers ne suffisent pas toujours. Pour ce travail, vous en avez généralement besoin de trois.
| Fichier | Rôle | Colonnes nécessaires |
|---|---|---|
| Export CSV de litiges Stripe | Définit le dossier de litige | ID de litige, ID de charge, montant, motif, date de création, statut |
| Export des charges ou paiements Stripe | Fait le lien entre les données de litige et le paiement original | ID de charge, payment intent, e-mail client, date de paiement, montant original, champs de métadonnées ou de référence |
| Export des commandes | Identifie la vente concernée dans votre propre système | ID de commande, date de commande, montant brut, e-mail client, référence de paiement, champs d'expédition ou de facturation |
Le fichier intermédiaire est celui que la plupart des gens ignorent. C'est pour ça que le recoupement échoue.
Le CSV de litiges vous dit quel paiement a été contesté. Le fichier de commandes vous dit quelle vente vous intéresse en interne. L'export de charges ou de paiements fait la traduction entre les deux. Si votre système de commandes enregistre déjà l'ID de charge Stripe sur chaque ligne de commande, le lien est court. Sinon, le fichier intermédiaire devient indispensable.
Conservez les exports bruts intacts. Ne commencez pas par trier, supprimer des colonnes, ou coller un fichier dans un autre onglet. Le recoupement de litiges est déjà une correspondance en plusieurs étapes. Dès que les lignes sources bougent, vous ajoutez un deuxième problème par-dessus le premier.
Faites correspondre dans cet ordre, pas au hasard
Un recoupement propre commence par l'identifiant le plus fiable et ne se replie sur un autre que si celui-ci est absent.
1. ID de charge vers ID de charge
Si le fichier de commandes contient un champ stripe_charge_id, gateway_reference, ou similaire, commencez par là. C'est le chemin le plus court du litige à la commande.
| CSV de litiges | Export de charges | Export de commandes | Résultat |
|---|---|---|---|
charge = ch_3N8... | charge_id = ch_3N8... | stripe_charge_id = ch_3N8... | Correspondance directe avec la commande concernée |
À ce stade, ajoutez l'ID de commande à côté de l'ID de litige. Ne vous arrêtez pas à « correspondance trouvée ». Récupérez aussi la date de commande, l'e-mail client, le montant original de la commande et l'état d'expédition actuel. Ce sont en général les champs dont vous aurez besoin quand quelqu'un demande si le litige est justifié ou si la commande a bien été livrée.
2. Payment intent ou référence de paiement
Certains tableaux de commandes conservent le payment intent mais pas l'ID de charge final. Dans ce cas, utilisez l'export de paiements pour relier la charge du litige au payment intent, puis le payment intent à la commande.
C'est courant quand le système de commerce écrit une référence passerelle au moment du paiement et ne met jamais à jour la ligne de commande avec l'objet de charge final. La commande reste traçable. Vous ne pouvez pas passer directement du fichier de litiges au fichier de commandes.
3. Métadonnées ou référence de paiement reportée dans la commande
Si l'export de charges contient des métadonnées comme un numéro de commande interne, un numéro de facture ou une référence de paiement, utilisez-les en priorité. C'est souvent la voie de récupération la plus nette quand l'export de commandes n'expose pas les identifiants Stripe dans des colonnes visibles.
L'essentiel ici est de faire correspondre un objet de paiement à un objet de commande. Ne réduisez pas la logique à « même montant, donc même vente ». Le montant est un signal d'appui. Ce n'est pas le lien.
4. Montant, client et délai comme repli contrôlé
Si aucun des deux fichiers n'a conservé les identifiants Stripe, vous pouvez quand même retrouver la commande, mais vous faites maintenant une investigation plutôt qu'une correspondance directe.
Utilisez une fenêtre de candidats réduite :
- Même e-mail client ou nom du titulaire de la carte
- Montant de la charge original proche du montant contesté
- Commande passée près de la date de création de la charge
- Une seule ligne de paiement réussi, pas une tentative échouée ni une autorisation en double
C'est là que même les équipes compétentes perdent du temps. Elles cherchent le montant contesté dans le tableau de commandes, voient cinq lignes avec la même valeur, et choisissent la mauvaise. La correspondance par montant seul est fragile : beaucoup de boutiques vendent à des prix récurrents. Avant de vous fier à une correspondance par montant, comptez combien de commandes le partagent :
=NB.SI(Commandes!$D:$D,D2)Si le résultat dépasse 1, le montant n'est pas unique. Réduisez par client et date de charge avant de choisir une ligne.
Si la charge contestée ne remonte toujours pas, traitez-la comme un problème d'enregistrement manquant et travaillez-la comme n'importe quelle autre comparaison de deux fichiers défaillante. Retrouver une transaction manquante entre deux fichiers financiers rapidement est la bonne suite de procédure à ce stade.
Construisez un tableau de suivi des litiges qui répond à la vraie question
La vraie question n'est pas « est-ce que je peux aligner les lignes ». C'est « quelles commandes sont concernées, et que dois-je faire ensuite ».
Le tableau de sortie doit donc ressembler davantage à un tableau de contrôle qu'à un brouillon de formules.
| Colonne de sortie | Pourquoi elle appartient au tableau de suivi |
|---|---|
| ID de litige | Identifie le dossier auquel vous répondez |
| ID de charge | Ancre le litige au paiement original |
| ID de commande | Indique à l'entreprise quelle vente est concernée |
| Date de commande | Distingue la date de vente de la date d'ouverture du litige |
| Date de création du litige | Indique quand la rétrofacturation a été ouverte |
| Montant original de la charge | Confirme la valeur totale du paiement |
| Montant contesté | Signale immédiatement les litiges partiels |
| E-mail ou nom du client | Aide à confirmer l'identité de la commande |
| Motif ou catégorie | Indique le type de preuve dont vous aurez probablement besoin |
| Statut de correspondance | Correspondance directe par ID, via l'export de paiements, correspondance probable, ou non résolue |
Ces libellés de statut ont leur importance. Ils vous empêchent de traiter chaque ligne comme également fiable.
Une bonne structure de premier passage :
Correspondance directe par IDCorrespondée via l'export de paiementsCorrespondance probable : révision manuelleCommande introuvable
Le tableau vous indique maintenant où le travail est vraiment nécessaire. Les deux premiers groupes peuvent passer rapidement à la collecte de preuves. Le troisième nécessite une révision humaine. Le quatrième signifie généralement l'une de trois choses : la mauvaise plage de dates a été exportée, la charge réussie manque dans le fichier intermédiaire, ou le système de commandes n'a jamais conservé la référence côté Stripe.
Si vous devez également retracer l'impact du paiement contesté sur la trésorerie, le rapprochement d'un export CSV de virement Stripe avec votre relevé bancaire couvre le volet des versements de la même investigation.
Les cas limites qui créent de fausses non-correspondances
C'est là que les articles superficiels s'arrêtent. La correspondance directe n'est que la moitié du travail. Ce sont les cas difficiles qui font traîner le recoupement.
Le montant contesté n'est pas le montant total de la commande.
Une rétrofacturation peut être partielle. Quand le total de la commande est 120.00 et le montant contesté est 40.00, la ligne n'est pas erronée. Elle vous dit que seule une partie du paiement original est contestée. Conservez les deux montants dans le tableau de suivi.
La date du litige n'est pas la date de la commande.
La charge peut avoir eu lieu en janvier et le litige s'ouvrir en mars. Une correspondance par date de création du litige vous enverra dans la mauvaise fenêtre de commandes.
Un même client a passé plusieurs commandes similaires.
Même client. Même mois. Même total de commande. Si vous ne vous ancrez pas sur la charge ou la référence de paiement, le tableur peut vous pointer vers la mauvaise vente avec une totale assurance.
La première tentative de paiement a échoué, mais une deuxième a réussi.
Les systèmes de commandes conservent souvent l'enregistrement de commande tandis que Stripe affiche plusieurs événements de paiement autour. Seule la charge réussie liée au litige compte. Les tentatives échouées et les autorisations en double créent du bruit, pas des preuves.
L'export de commandes contient des totaux nets ou par article, tandis que Stripe enregistre le montant total débité.
La TVA, les frais de port, les remises et la gestion des devises peuvent faire paraître différents le total du tableau de commandes et le montant de la charge, même quand ils appartiennent à la même vente. Quand l'identifiant correspond, faites confiance à l'identifiant plutôt qu'à la comparaison approximative des montants.
Le fichier de litiges est correct, mais votre tableau a perdu la clé.
Cela arrive quand quelqu'un exporte les bonnes données puis reconstruit le tableau manuellement. Les colonnes masquées disparaissent. Les colonnes de référence sont renommées. La correspondance échoue parce que le champ de lien n'a jamais été reporté dans le fichier de travail.
Que faire quand il n'existe aucune référence de commande exploitable
Parfois, le système de commandes n'a jamais écrit l'ID de charge Stripe, le payment intent, ni aucune référence de paiement réutilisable dans un export. Cela ne rend pas le litige impossible à retracer, mais cela change la nature du travail.
Dans ce cas :
- Partez de l'ID de charge dans l'export de litiges.
- Récupérez les détails du paiement côté Stripe pour cette charge.
- Intégrez l'identifiant client, le montant du paiement et l'horodatage du paiement.
- Réduisez les commandes candidates par client d'abord, puis par fenêtre de temps, puis par montant.
- Marquez le résultat comme correspondance probable jusqu'à ce qu'un autre champ métier le confirme.
Le champ de confirmation peut être le code postal de livraison, le numéro de facture, le lot de produits, la référence d'abonnement ou le jeton de paiement interne. L'essentiel est de ne pas traiter une correspondance approximative comme une correspondance ferme.
C'est aussi là que les équipes découvrent que leur export de commandes n'est pas conçu pour le traitement des litiges. Il est conçu pour le reporting des ventes. Ce ne sont pas le même travail. Le reporting des ventes peut se contenter d'une colonne de montant propre et d'une date. Le traitement des litiges a besoin d'un lien récupérable vers l'objet de paiement.
Quand l'approche fichier par fichier coûte plus que le litige lui-même
Un litige ponctuel peut se traiter manuellement. Le processus devient coûteux quand vous reconstruisez sans cesse le même lien : exporter les litiges, exporter les charges, exporter les commandes, retrouver la référence commune, signaler les montants partiels, puis trier les lignes confirmées de celles qui nécessitent encore une révision.
Le recoupement est complet quand chaque ligne de litige aboutit à l'un des quatre résultats : correspondance avec une commande spécifique, correspondance via un fichier intermédiaire, réduite à un petit ensemble à réviser manuellement, ou confirmée absente des enregistrements de commandes. Une fois cette structure en place, vous savez quelles ventes sont concernées et quels dossiers nécessitent encore un travail de preuve. C'est l'objet du tableur. Pas un mur de formules. Une réponse défendable.
