Pourquoi mes ventes App Store et mon financial report ne concordent-ils pas ?

Ils mesurent des choses différentes sur des horloges différentes. Sales and Trends est une estimation rapide en USD utilisant un taux de change en moyenne mobile, tandis que Payments and Financial Reports est l'enregistrement comptable réglé sur le calendrier fiscal 4-4-5 d'Apple, avec le taux de change finalisé. Comme les mois fiscaux ne sont pas des mois calendaires et que les remboursements se règlent plus tard que la vente, les deux totaux divergent par conception. Rapprochez avec le financial report pour tout ce qui touche à l'argent.

Comment les remboursements apparaissent-ils dans le Summary Sales Report de l'App Store ?

Un remboursement apparaît comme sa propre ligne avec des Units négatives et un Customer Price négatif. Le rapport n'est pas net de remboursements, donc les lignes de remboursement côtoient les lignes de vente au lieu de les annuler. Identifiez les remboursements par les Units négatives et totalisez ces lignes séparément, car additionner la colonne à l'œil comptera mal vos remboursements.

Pourquoi mon serveur montre-t-il plus de notifications REFUND que mon sales report ?

Parce que les deux comptent des moments différents. Votre serveur entend l'événement de remboursement en temps réel, tandis que le sales report enregistre la ligne réglée plus tard, et les remboursements partiels ou resoumis peuvent générer plus d'une notification. Pour trancher la différence, prenez les ids de transaction que votre serveur a vus et passez-les par le point de terminaison Get Refund History de l'App Store Server API, qui renvoie le propre enregistrement d'Apple de ce qui a réellement été remboursé.

Quel chiffre de remboursement dois-je utiliser pour la comptabilité ?

Le Payments and Financial Reports d'Apple et le earnings report de Google Play. Ce sont les enregistrements réglés, de qualité comptable. Sales and Trends d'Apple et le estimated sales report de Google sont des analyses rapides que les deux boutiques vous disent de ne pas utiliser pour la comptabilité, et les notifications de votre serveur servent à contrôler l'accès, pas à comptabiliser des revenus.

Un remboursement apparaît-il dans le même mois que la vente d'origine ?

Généralement non. Un remboursement est attribué à la date à laquelle il est réglé, pas à la date de l'achat d'origine, sur les deux boutiques. Une vente de mars remboursée en avril réduit vos totaux d'avril, donc faire correspondre deux mois par leurs étiquettes fera croire que le remboursement a disparu d'un mois et est apparu dans un autre. Faites plutôt correspondre par id de transaction.

Tous les articles

Playbook17 août 20268 min de lecture

Vos rapports de remboursement ne concordent jamais entre Apple, Google et votre serveur, voici comment les rapprocher

Apple affiche les remboursements dans deux rapports, Google dans deux autres, et votre serveur en voit un quatrième. Aucun des décomptes ne concorde, et les écarts sont voulus. Voici pourquoi chaque surface attribue les remboursements différemment, et comment rapprocher les rapports de remboursement de vos propres enregistrements par transaction.

Le bureau d'un comptable avec trois piles distinctes de rapports financiers imprimés et une loupe, illustrant à quel point il est difficile de rapprocher les rapports de remboursement entre Apple et Google

Points clés

Apple répartit les rapports de remboursement entre deux outils qui, par conception, ne concordent jamais. Sales and Trends estime les remboursements rapidement en USD, et Payments and Financial Reports les règle plus tard selon le calendrier fiscal d'Apple. La notification REFUND de votre serveur est une troisième vue, en temps réel, du même événement.
Dans le Summary Sales Report d'Apple, un remboursement est sa propre ligne avec des Units négatives et un Customer Price négatif, et le rapport n'est pas net de remboursements. Si vous additionnez une colonne à l'œil, vous compterez mal, car les lignes de remboursement côtoient les lignes de vente au lieu de les annuler.
Les rapports financiers d'Apple suivent un calendrier fiscal 4-4-5, pas des mois calendaires, et le rapport d'un mois fiscal est disponible le premier vendredi du mois fiscal suivant. Tout total de remboursements que vous comparez à un simple mois calendaire sera faussé avant même de commencer.
Google Play sépare les remboursements de la même façon. Le earnings report liste Charge refund et Google fee refund comme leurs propres types de transaction, chacun marqué Full ou Partial, tandis que le estimated sales report est une analyse à faible latence que Google déclare inadaptée à la comptabilité.
Un remboursement est attribué à la date à laquelle il est réglé, pas à la date de la vente d'origine, donc le remboursement d'un achat de mars atterrit dans vos chiffres d'avril sur les deux boutiques. Rapprochez les remboursements par id de transaction, jamais en alignant des totaux mensuels.
Les développeurs trouvent régulièrement plus de notifications REFUND que de lignes de remboursement dans le Summary Sales Report sur la même fenêtre, car les deux comptent des moments différents. Le point de terminaison Get Refund History de l'App Store Server API d'Apple est la source de vérité pour le rapprochement, un id de transaction à la fois.
Seules deux de ces surfaces sont conçues pour la comptabilité : le financial report d'Apple et le earnings report de Google. Rapprochez l'argent avec ceux-là, rapprochez l'accès avec les notifications de votre serveur, et ne demandez jamais à un chiffre de faire le travail de l'autre.

Extrayez le nombre de remboursements d'App Store Connect, puis extrayez-le de votre serveur, et les deux chiffres ne concorderont pas. Extrayez-en un troisième de votre financial report et il ne concordera avec aucun des deux non plus. Ce n'est pas un bug dans le système de qui que ce soit. Apple et Google déclarent chacun les remboursements via plus d'une surface, chaque surface compte un moment différent dans la vie du remboursement, et votre serveur en voit un quatrième. Si vous avez déjà essayé de rapprocher des rapports de remboursement et abandonné parce que les totaux s'écartent, voici pourquoi ils s'écartent, quel chiffre croire pour quelle tâche, et comment les aligner par transaction plutôt que par mois.

Pourquoi un même remboursement apparaît sous trois chiffres différents

Un seul remboursement traverse plusieurs systèmes avant d'être réglé, et chaque système le consigne à un instant différent. Votre serveur l'apprend en premier, sous forme d'événement. Un rapport d'analyse rapide l'estime ensuite. Le rapport comptable l'enregistre en dernier, une fois que l'argent a réellement bougé. Même remboursement, trois horodatages, trois totaux. L'erreur est de traiter deux d'entre eux comme s'ils devaient être égaux le même jour.

Apple vous donne deux familles de rapports, plus votre webhook

Apple déclare les remboursements à deux endroits qui ne sont pas le même outil et ne sont pas censés concorder un jour donné. Sales and Trends est la vue rapide et estimée : les rapports quotidiens arrivent le lendemain, les hebdomadaires le lundi, et les mensuels environ cinq jours après la fin du mois, généralement avant 8 a.m. heure du Pacific. Il estime les ventes et les revenus en USD à l'aide d'une moyenne mobile des taux de change du mois précédent, ce qui le rend bon pour repérer une tendance et mauvais pour boucler un versement. Payments and Financial Reports est la vue réglée : généré une fois par mois selon le calendrier fiscal d'Apple, disponible le premier vendredi du mois fiscal en cours pour le mois fiscal précédent, et généré uniquement s'il y a eu des achats ou des remboursements sur cette période. Il utilise le taux de change finalisé appliqué à votre versement. Ce rapport est l'enregistrement comptable. Aux côtés des deux, votre serveur reçoit l'App Store Server Notification REFUND au moment où Apple accorde un remboursement, rattachée à un seul id de transaction.

Google se divise de la même façon

Google Play reproduit la même division. Le earnings report est l'enregistrement comptable, généré mensuellement et généralement disponible d'ici le 5 du mois suivant, et il liste les remboursements comme leurs propres types de transaction : Charge refund pour l'argent rendu à l'acheteur et Google fee refund pour les frais de service que Google restitue, chacun étiqueté Full ou Partial. Le estimated sales report est la vue d'analyse à faible latence qui montre ce que les acheteurs ont payé avant taxes et frais, et Google dit clairement qu'il convient à l'analyse et n'est pas recommandé pour la comptabilité. Côté serveur, vous recevez la Real-time Developer Notification en temps réel et pouvez relire un remboursement depuis la Voided Purchases API.

Comment Apple affiche un remboursement dans le rapport, et le piège de la ligne négative

Ouvrez le Summary Sales Report et un remboursement ne se soustrait pas discrètement d'une vente. Il apparaît comme sa propre ligne. Les Units et le Customer Price de cette ligne sont négatifs, c'est ainsi que vous repérez un remboursement, et le chiffre de Developer Proceeds ne se comporte pas comme le prix. Le rapport n'est pas intrinsèquement net de remboursements. Il liste les lignes de remboursement à côté des lignes de vente, et c'est à vous de les regrouper. Additionnez la colonne Units à l'œil et vous compterez en double ou raterez complètement les remboursements, car une ligne de remboursement de moins un se trouve dans la même colonne que vos ventes positives.

La règle pratique est simple : trouvez les remboursements par les Units négatives, additionnez ces lignes à part, et ne supposez jamais que le rapport les a déjà déduites pour vous. Un décompte de vos remboursements pour un featured snippet est le nombre de lignes à Units négatives, pas la somme arithmétique d'une colonne.

Surface Apple	À quoi ça sert	Quand ça se met à jour	Comment un remboursement apparaît
Sales and Trends	Estimation rapide de tendance, pas de comptabilité	Quotidien le lendemain, mensuel environ 5 jours après la fin du mois	Unités négatives dans la tendance, estimées en USD
Summary Sales Report	Le détail téléchargeable derrière Sales and Trends	La même cadence que Sales and Trends	Sa propre ligne, Units négatives et Customer Price négatif
Payments and Financial Reports	L'enregistrement comptable et de versement	Mensuel selon le calendrier fiscal d'Apple, le premier vendredi	Déduction réglée des revenus de ce mois fiscal
Notification de serveur REFUND	Contrôle d'accès en temps réel	Le moment où Apple accorde le remboursement	Un événement, un id de transaction

Le calendrier fiscal explique pourquoi vos totaux mensuels ne concordent jamais

Voici la principale raison pour laquelle un tableur soigné refuse toujours de s'équilibrer. Les rapports financiers d'Apple ne suivent pas les mois calendaires. Ils suivent un calendrier fiscal 4-4-5, où la plupart des mois fiscaux durent quatre semaines et où un sur trois en dure cinq. Un développeur qui compare un Financial Report à une simple fenêtre de janvier à janvier compare deux plages de jours différentes, donc les totaux de remboursements ne peuvent pas concorder même quand chaque chiffre sous-jacent est correct. Des développeurs sur les propres forums d'Apple ont vu les chiffres de Sales et ceux du Financial Report diverger de milliers de dollars pour exactement cette raison, l'écart se creusant chaque mois qu'ils le laissaient s'accumuler.

Le earnings report de Google est mensuel, mais il porte sa propre temporalité et son propre fuseau horaire, et aucun n'est l'horloge UTC de votre serveur. Le piège plus profond est partagé par les deux boutiques : un remboursement est attribué à la date à laquelle il est réglé, pas à la date de la vente d'origine. Remboursez un achat de mars début avril et il réduit vos chiffres d'avril, pas ceux de mars. Alignez deux mois par leurs étiquettes et le remboursement semblera avoir disparu de l'un et s'être matérialisé dans l'autre.

Deux tableurs imprimés posés côte à côte pendant qu'une main suit une ligne à travers les deux, illustrant le rapprochement des rapports de remboursement par id de transaction

Combien coûte un remboursement, et dans quel rapport le lire

Le rapprochement est en réalité une question de comptabilité, alors suivez l'argent. Lors d'un remboursement, la boutique restitue sa propre commission, ce qui veut dire que le montant qui quitte réellement votre compte est votre part de la vente, pas le prix complet que le client voit remboursé. Sur Google Play, cette restitution est une ligne visible : le type de transaction Google fee refund sur votre earnings report est les frais de service qui vous reviennent, à côté du Charge refund parti à l'acheteur. Sur l'App Store, Apple déduit vos revenus après commission et rend sa commission dans le même mouvement, donc le financial report montre la déduction nette de la part d'Apple.

La temporalité de la trésorerie est là où les développeurs sont surpris. Sur Google Play, si vous remboursez une commande avant que Google vous ait payé pour elle, vous ne recevez tout simplement jamais ce montant. Si vous remboursez après le versement, Google le déduit d'un versement futur. Et si une vague de remboursements pousse votre solde en négatif et qu'il reste négatif pendant au moins 48 heures, Google débitera le compte bancaire qui reçoit normalement vos versements du montant manquant. Un chargeback est la version plus dure du même événement : sur Google Play, pour les commandes passées le August 3, 2026 ou après, le chargeback transfère le prix d'achat plus les frais de la banque au développeur, et il tombe sur le rapport d'un mois postérieur à celui de la vente.

Lors d'un remboursement	App Store	Google Play
Ce qui quitte votre compte	Vos revenus après commission	Le prix d'achat moins les frais de service de Play
Ce que la boutique restitue	La commission d'Apple	Les frais de service, sous forme de ligne Google fee refund
Quel rapport pour le rapprochement	Payments and Financial Reports	Earnings report
Quand ça se règle	Le mois fiscal où c'est traité, d'ici le premier vendredi suivant	Déduit du versement de cette période ou de la suivante
Le twist du chargeback	Apple absorbe la mécanique de litige de carte	À partir du Aug 3 2026, le prix plus les frais bancaires basculent sur vous

Comment rapprocher vos rapports de remboursement, étape par étape

Le travail devient simple dès que vous cessez d'essayer de rendre chaque chiffre égal et qu'à la place vous assignez chaque chiffre à la question à laquelle il répond. Il n'y a que deux questions : combien d'argent a bougé, et qui a encore accès.

Décidez de la question avant d'ouvrir un rapport. Pour l'argent, la réponse est dans le financial report d'Apple et le earnings report de Google, point final. Pour l'accès, la réponse est dans les notifications de votre serveur. Ne rapprochez jamais l'un contre l'autre.
Choisissez l'id de transaction comme clé de jointure sur les quatre surfaces. C'est le seul champ qu'une vente, son remboursement, les rapports et votre webhook partagent tous.
Pour Apple, quand le Summary Sales Report et votre webhook divergent, appelez le point de terminaison Get Refund History de l'App Store Server API à /inApps/v2/refund/lookup/{transactionId}. Il renvoie les transactions remboursées signées d'un client, avec revocationDate et revocationReason, un id de transaction à la fois, et pagine dans son historique. Ce point de terminaison est le juge de paix.
Pour Google, recoupez les lignes Charge refund du earnings report avec ce que la Voided Purchases API rapporte pour les mêmes commandes, et rappelez-vous qu'un remboursement partiel est étiqueté Partial et ne remettra pas à zéro la charge d'origine.
Alignez-vous sur l'horloge du rapport, pas la vôtre. Celle d'Apple est un mois fiscal en heure du Pacific. Le earnings report de Google a son propre mois et son propre fuseau horaire. Vos journaux sont presque certainement en UTC. Convertissez au calendrier du rapport avant de comparer, sinon les limites de journée créeront à elles seules des écarts fantômes.
Attendez-vous à ce que l'estimation bouge. Sales and Trends est une estimation et continuera de changer à mesure que les transactions se règlent. Rapprochez avec le financial report, jamais avec l'estimation, et jamais avec l'instantané d'hier de l'estimation.

Quand votre serveur montre plus de remboursements que le rapport

La panique la plus courante est de trouver plus de notifications REFUND sur votre serveur que de lignes de remboursement dans le sales report sur la même fenêtre. Ce n'est généralement pas de l'argent perdu. Les deux surfaces comptent des moments différents, une notification peut précéder la ligne du rapport de plusieurs jours, et un remboursement partiel ou une demande resoumise peut produire plus d'un événement. Des développeurs ont rapporté exactement cette forme, des milliers de notifications REFUND face à un nombre plus petit de lignes à Units négatives pour le même mois. Résolvez-le toujours de la même façon : prenez les ids de transaction que votre serveur a vus, passez-les par Get Refund History, et laissez le propre enregistrement d'Apple trancher lesquels ont vraiment été remboursés et pour combien.

La version courte

Vous ne pouvez pas faire en sorte que l'estimation d'Apple, le financial report d'Apple, le earnings report de Google et votre webhook affichent tous le même total de remboursements le même jour, et vous devriez cesser d'essayer. Lisez chacun pour ce qu'il est fait pour vous dire. Faites confiance au financial report et au earnings report pour l'argent, faites confiance aux notifications de votre serveur pour l'accès, et quand deux surfaces s'affrontent, joignez-les sur l'id de transaction et laissez la recherche Get Refund History ou Voided Purchases départager. Les remboursements rapprochés ne sont pas des totaux qui concordent. Ce sont des transactions qui concordent.

Questions fréquentes

Pourquoi mes ventes App Store et mon financial report ne concordent-ils pas ?: Ils mesurent des choses différentes sur des horloges différentes. Sales and Trends est une estimation rapide en USD utilisant un taux de change en moyenne mobile, tandis que Payments and Financial Reports est l'enregistrement comptable réglé sur le calendrier fiscal 4-4-5 d'Apple, avec le taux de change finalisé. Comme les mois fiscaux ne sont pas des mois calendaires et que les remboursements se règlent plus tard que la vente, les deux totaux divergent par conception. Rapprochez avec le financial report pour tout ce qui touche à l'argent.
Comment les remboursements apparaissent-ils dans le Summary Sales Report de l'App Store ?: Un remboursement apparaît comme sa propre ligne avec des Units négatives et un Customer Price négatif. Le rapport n'est pas net de remboursements, donc les lignes de remboursement côtoient les lignes de vente au lieu de les annuler. Identifiez les remboursements par les Units négatives et totalisez ces lignes séparément, car additionner la colonne à l'œil comptera mal vos remboursements.
Quand les remboursements apparaissent-ils dans le earnings report de Google Play ?: Le earnings report est généré mensuellement et généralement disponible d'ici le 5 du mois suivant. Un remboursement apparaît sous deux types de transaction, Charge refund pour l'argent rendu à l'acheteur et Google fee refund pour les frais de service que Google vous restitue, chacun marqué Full ou Partial. Si vous avez remboursé avant que Google vous paie, vous ne recevez jamais ce montant ; si c'est après, il est déduit d'un versement futur.
Pourquoi mon serveur montre-t-il plus de notifications REFUND que mon sales report ?: Parce que les deux comptent des moments différents. Votre serveur entend l'événement de remboursement en temps réel, tandis que le sales report enregistre la ligne réglée plus tard, et les remboursements partiels ou resoumis peuvent générer plus d'une notification. Pour trancher la différence, prenez les ids de transaction que votre serveur a vus et passez-les par le point de terminaison Get Refund History de l'App Store Server API, qui renvoie le propre enregistrement d'Apple de ce qui a réellement été remboursé.
Quel chiffre de remboursement dois-je utiliser pour la comptabilité ?: Le Payments and Financial Reports d'Apple et le earnings report de Google Play. Ce sont les enregistrements réglés, de qualité comptable. Sales and Trends d'Apple et le estimated sales report de Google sont des analyses rapides que les deux boutiques vous disent de ne pas utiliser pour la comptabilité, et les notifications de votre serveur servent à contrôler l'accès, pas à comptabiliser des revenus.
Un remboursement apparaît-il dans le même mois que la vente d'origine ?: Généralement non. Un remboursement est attribué à la date à laquelle il est réglé, pas à la date de l'achat d'origine, sur les deux boutiques. Une vente de mars remboursée en avril réduit vos totaux d'avril, donc faire correspondre deux mois par leurs étiquettes fera croire que le remboursement a disparu d'un mois et est apparu dans un autre. Faites plutôt correspondre par id de transaction.

Sources et lectures complémentaires

RefundHalt

Le pilote automatique des remboursements pour l'App Store et Google Play

Poursuivre la lecture

Playbook7 min de lecture

Google Play vous laisse émettre vous-même un remboursement partiel, et l'App Store confie chaque remboursement à Apple

Sur Google Play, vous pouvez rembourser une partie d'une commande depuis la Console, par pourcentage ou par montant, et partager la perte avec la commission de Google. Sur l'App Store, vous ne pouvez émettre aucun remboursement. Voici comment fonctionne un remboursement partiel sur chaque store, et ce qu'il vous coûte.

Deep dive9 min de lecture

Un taux de remboursement d'app sain se situe entre 2 et 5 pour cent, voici où trouver le vôtre et ce qu'il coûte vraiment

La plupart des apps mobiles remboursent entre 2 et 5 pour cent des transactions payées, mais Apple et Google gardent ce chiffre dans des tableaux de bord différents. Voici où trouver le taux de remboursement de votre app, ce qui est normal selon le plan et la catégorie, et ce que chaque remboursement coûte réellement après les frais.