Comment créer un rapport sur les retours et les remboursements : un guide complet

Une boutique signale un taux de retour de 12 %. Pour un tiers de ces retours, rien n'a été physiquement renvoyé.
Ce n'est pas une erreur dans les données. C'est ce qui se produit lorsqu'un remboursement est enregistré comme un retour, ce qui est précisément la méthode de calcul de la plupart des plateformes.
La distinction peut sembler pointilleuse, jusqu'à ce que quelqu'un aux opérations planifie la capacité de l'entrepôt à partir de vos chiffres.
Ce guide présente ce qui doit figurer dans un rapport sur les retours et remboursements, et pourquoi ces deux termes décrivent des événements différents. Il aborde ensuite le problème de date qui fausse discrètement les comparaisons mensuelles, puis explique comment générer ce rapport à partir d'un export.
Ce que doit contenir un rapport sur les retours et remboursements
Cinq éléments doivent figurer sur la même vue, et le taux n'en est qu'un parmi d'autres.
La valeur remboursée, le nombre de commandes remboursées, la période, le dénominateur utilisé pour la division, et la répartition entre remboursements totaux et partiels.
Ajoutez les codes de motif si votre plateforme les enregistre. Un taux vous indique l'ampleur du problème, tandis que les motifs vous indiquent sa nature.
Excluez d'abord les frais de port et les taxes. Ces deux éléments sont généralement suivis séparément, et les mélanger rendra tout rapprochement ultérieur impossible.
Retours et remboursements ne sont pas la même chose
La documentation des plateformes est particulièrement claire à ce sujet, et il est utile d'en lire les termes exacts.
La documentation analytique de WooCommerce sépare directement les deux. Elle précise que « le remboursement décrit la transaction qui renvoie de l'argent à un client ».
L'autre moitié de cette définition est la plus importante. La métrique des retours enregistre la valeur remboursée, « que le remboursement soit total ou partiel et que les marchandises aient été physiquement retournées ou non ».
Ainsi, un geste commercial pour un article endommagé compte comme un retour, même si rien n'est renvoyé. Un ajustement de prix également.
Cette simple phrase explique pourquoi un chiffre de retours issu des outils d'analyse e-commerce ne peut pas être transmis à une équipe d'entrepôt comme prévision des retours physiques.
Les frais de port et les taxes sont également exclus. Les frais de port et taxes remboursés ne sont pas inclus dans le montant des remboursements. Ils apparaissent plutôt sous forme de valeurs négatives dans les chiffres des frais de port et des taxes.
Le problème de date
Ce problème-là modifie votre courbe de tendance plutôt qu'une simple cellule, ce qui le rend bien plus redoutable.
WooCommerce enregistre les remboursements « sous forme de nombre négatif à la date à laquelle le retour a eu lieu (et non à la date à laquelle la commande a été passée) ».
Pensez à l'impact de cette méthode sur une comparaison mensuelle. Un remboursement effectué en mars pour une commande de février est comptabilisé en mars, et le chiffre d'affaires de février n'est jamais réajusté.
Les deux mois sont désormais légèrement faussés dans des directions opposées. Février semble meilleur qu'il ne l'était, et mars supporte un coût qu'il n'a pas généré.
Il existe deux solutions acceptables, et vous devez en choisir une par écrit.
Établissez le rapport en fonction de la date de remboursement et qualifiez-le de vue de trésorerie. Il correspondra à votre banque et à votre plateforme, mais ne correspondra jamais à une analyse de cohorte.
Ou réattribuez chaque remboursement à sa date de commande d'origine. Cela donne une image fidèle par période de vente, mais cela signifie que le chiffre du mois dernier changera après sa publication.
Aucune de ces méthodes n'est mauvaise. Ce qui l'est, c'est de publier sans préciser celle que vous avez choisie.
Choisir le dénominateur
Un taux de retour a besoin d'un diviseur, et il en existe trois couramment utilisés qui produisent trois chiffres différents.
| Dénominateur | Signification du taux | Idéal pour |
|---|---|---|
| Commandes sur la période | Part des commandes ayant donné lieu à un remboursement | Charge de travail du service client |
| Unités expédiées | Part des articles retournés | Entrepôt et réapprovisionnement |
| Valeur nette des ventes | Part du chiffre d'affaires annulé | Finance et marge |
Choisissez en fonction de votre public. Une revue financière s'intéressera à la valeur, tandis qu'une revue opérationnelle préférera les unités.
Soyez ensuite attentif aux chiffres de vente associés, car ils sont également définis de manière précise. WooCommerce définit les ventes brutes comme le prix multiplié par la quantité, hors remboursements, coupons, taxes et frais de port, et les ventes nettes comme les ventes brutes moins les retours et les coupons.
Le panier moyen (AOV) y est calculé en divisant les ventes nettes par le nombre de commandes. Les remboursements sont donc déjà intégrés dans l'AOV que vous mentionnez peut-être par ailleurs.
Notre guide pour transformer les commandes e-commerce brutes en un rapport de tendance des ventes traite de la partie revenus de ce même export.
Comment procéder manuellement
Option 1 : Deux totaux et une division
Filtrez l'export pour ne garder que les remboursements de la période, puis calculez le montant total remboursé à l'aide de la fonction SUMIFS.
Comptez les commandes concernées avec COUNTIFS, en dédoublant d'abord les identifiants de commande si une même commande peut faire l'objet de plusieurs remboursements.
Divisez une seule fois à la fin. Conserver les deux totaux visibles permet à un tiers de vérifier facilement votre travail.
On atteint vite les limites de cette méthode. Vous obtenez un taux unique pour une période donnée, sans aucune visibilité sur les produits ou les motifs qui l'expliquent.
Option 2 : Une ligne par remboursement
Créez un tableau avec une ligne par remboursement. Ajoutez des colonnes pour la date de commande, la date de remboursement, le nombre de jours d'écart, la valeur remboursée, le type (total ou partiel) et le motif.
Calculez l'écart en jours en soustrayant la date la plus ancienne de la plus récente. Les recommandations de Microsoft concernant la fonction DATEDIF signalent qu'elle « peut calculer des résultats incorrects dans certains scénarios ».
Le rapport peut désormais être segmenté : par produit, par catégorie, par canal, par motif ou par délai de remboursement.
La colonne du délai est souvent sous-estimée. Une concentration de remboursements 40 jours après l'achat indique un problème de durabilité, tandis qu'une concentration à 4 jours pointe vers un problème de taille ou de description.
La limite réside dans le volume et les jointures. Associer les remboursements aux lignes de commande et aux données produits dépasse le stade où les formules restent simples et gérables.
Option 3 : Un onglet de définitions
Notez la date sur laquelle vous basez votre rapport, le dénominateur choisi, et si les frais de port et les taxes sont inclus.
Enregistrez ensuite les exclusions. Les commandes annulées qui n'ont jamais été expédiées, les transactions de test et les rétrofacturations (chargebacks) doivent chacune faire l'objet d'un traitement clairement défini.
Les rétrofacturations sont l'élément que l'on oublie souvent. L'argent s'en va, aucun retour n'est enregistré, et les deux systèmes restent en désaccord permanent.
La limite est que le simple fait de rédiger une règle ne l'applique pas automatiquement. Quelqu'un devra recréer les mêmes filtres le mois suivant.
La limite commune. Ces trois options supposent que l'export contienne les deux dates. S'il ne contient que la date de remboursement, l'analyse de cohorte ne pourra pas être reconstituée à partir de ce fichier.
Là où la méthode manuelle montre ses limites
Le premier rapport prend une matinée. Le quatrième prend plus de temps, car trois éléments ont dérivé entre-temps.
Les remboursements partiels se multiplient. Une commande avec trois remboursements partiels devient trois lignes, et un décompte de commandes basé sur le nombre de lignes est alors faussé.
Les catalogues de produits évoluent. Un SKU renommé divise l'historique d'un produit en deux, et le produit le plus problématique disparaît du haut de votre liste.
De plus, les définitions changent discrètement. Quelqu'un décide d'inclure les frais de port remboursés ce mois-ci parce que cela semblait plus complet, et la tendance est rompue.
Il existe un quatrième coût qui n'apparaît qu'en réunion. Lorsque quelqu'un demande pourquoi la finance a un chiffre différent, la réponse réside dans une convention de date située dans un onglet que vous n'avez pas sous les yeux.
Le volet outillage fait l'objet d'un récapitulatif dédié dans les outils d'IA pour l'analyse e-commerce.
Comment le concevoir avec Powerdrill Bloom
Étape 1 : Importez vos exports de commandes et de remboursements
Importez simultanément le fichier des commandes et celui des remboursements. Powerdrill Bloom analyse la structure des colonnes dès leur réception, de sorte que les dates de remboursement manquantes, les identifiants de commande en double et les valeurs SKU incohérentes sont détectés avant même le calcul du moindre taux.
Étape 2 : Décrivez le rapport en langage naturel
Énoncez les règles plutôt que de les programmer. Indiquez la date de référence du rapport, le dénominateur, si les frais de port et les taxes sont inclus, et ce qu'il faut exclure.
Posez ensuite les questions qui permettent de détecter les erreurs. Demandez combien de commandes comportent plus d'un remboursement. Demandez quels remboursements sortent de la période de déclaration de leur commande d'origine. Enfin, demandez le taux par produit et par code de motif.
Étape 3 : Exportez le graphique, le rapport ou la présentation
Extrayez le taux avec son dénominateur, une distribution du délai de remboursement en jours, ou des diapositives présentant la convention de date à côté du chiffre.
Erreurs courantes
Considérer les retours comme des retours physiques. Les indicateurs des plateformes comptabilisent la valeur remboursée, que les marchandises aient été renvoyées ou non. Précisez clairement de quoi vous parlez.
Présenter le taux sans son dénominateur. Les commandes, les unités et la valeur donnent trois résultats différents. Indiquez clairement celui que vous utilisez sur le rapport.
Mélanger la date de remboursement et la date de commande. Choisissez une convention, indiquez-la clairement et ne comparez jamais des données basées sur l'une et l'autre.
Inclure discrètement les frais de port et taxes remboursés. Ces deux éléments sont généralement suivis séparément. Les ajouter rend tout rapprochement avec la finance impossible.
Compter les lignes au lieu des commandes. Les remboursements partiels génèrent plusieurs lignes par commande. Dédoublez les données avant de compter.
Ignorer les rétrofacturations (chargebacks). L'argent sort sans qu'aucun remboursement ne soit enregistré. Décidez de l'endroit où elles doivent apparaître et consignez-le par écrit.
Se comparer à un taux sectoriel publié. Les autres e-commerçants utilisent d'autres dénominateurs et d'autres règles de date. Comparez-vous d'abord à votre propre tendance.
Conclusion
Séparez la transaction de remboursement de la valeur des retours, choisissez une convention de date, sélectionnez un dénominateur et présentez le taux à côté de la base dont il est issu.
Le taux n'est pas le livrable en soi. C'est la répartition par produit, par motif et par délai de remboursement qui vous indique s'il faut corriger une fiche produit, un guide des tailles ou changer de fournisseur.
Si reconstruire cette répartition chaque mois vous prend une journée entière, essayez Powerdrill Bloom sur votre export de commandes. Consultez également les pages de l'assistant IA pour CSV et du générateur de rapports IA.
Foire aux questions
Quelle est la différence entre un retour et un remboursement ?
Un remboursement est la transaction qui renvoie l'argent. Les retours, en tant qu'indicateur, enregistrent la valeur remboursée des biens et services, que ces derniers aient été physiquement retournés ou non.
Comment calculer le taux de retour ?
Divisez l'activité remboursée par une base définie, puis multipliez par 100. Cette base peut être les commandes, les unités expédiées ou la valeur nette des ventes, chacune donnant un chiffre différent.
Dois-je baser mon rapport sur la date de remboursement ou sur la date de commande ?
L'une ou l'autre, à condition de le préciser clairement. La date de remboursement correspond à votre plateforme et à votre banque, tandis que la date de commande offre une image plus fidèle de chaque période de vente.
Les frais de port et taxes remboursés sont-ils pris en compte ?
Généralement pas dans le montant des remboursements. WooCommerce comptabilise plutôt les frais de port et taxes remboursés dans les chiffres des frais de port et des taxes.
Pourquoi mon chiffre diffère-t-il de celui de la finance ?
Le plus souvent en raison de la convention de date, suivie de l'inclusion ou non des frais de port, des taxes et des rétrofacturations (chargebacks). Comparez les définitions avant de comparer les chiffres.