Le taux de change du remboursement détermine ce qu'une vente à l'étranger vous coûte vraiment, et Apple et Google ne le fixent pas de la même façon

Apple et Google reprennent tous deux vos remboursements en devises étrangères sur vos revenus, mais ils ne s'accordent pas sur le jour dont il faut retenir le taux de change. Ce taux de change du remboursement explique pourquoi un remboursement sur une vente en euros, en yens ou en roupies peut vous coûter quelques centimes de plus, ou de moins, que ce que la vente vous avait rapporté. Sur un seul remboursement, c'est du bruit. Sur une année de remboursements internationaux, c'est une ligne de vos comptes que personne n'avait budgétée, et on la prend facilement pour une erreur de reporting.

Quel taux de change du remboursement chaque store utilise

Les deux stores suivent des modèles différents. Apple conserve vos revenus dans la devise de chaque storefront pendant tout le mois fiscal et ne convertit qu'une fois, au moment de vous payer. Google convertit chaque commande dans votre devise de versement au moment où elle est passée. Un remboursement hérite du modèle de son store.

Apple convertit au moment du paiement

La page Payments and Financial Reports d'Apple indique que sa banque convertit les montants des paiements dans la devise de votre compte bancaire. Le taux est fixé par la banque d'Apple, et Apple précise qu'il s'agit généralement du taux au comptant à la date du paiement, au plus trois jours ouvrés avant que l'argent n'arrive sur votre compte. Le paiement lui-même intervient dans les 45 jours suivant le dernier jour du mois fiscal au cours duquel la transaction a été finalisée.

Tant qu'Apple n'a pas payé, vos revenus restent donc en devises locales. Une vente en Allemagne figure en euros dans votre rapport. Une vente au Japon figure en yens. Le rapport financier d'Apple indique même la devise sur chaque ligne, dans un champ appelé Partner Share Currency.

Google convertit au moment de la commande

L'aide de la Play Console indique que Google utilise le taux de change en vigueur au moment où la commande est passée pour convertir une vente de la devise de l'acheteur vers celle de votre compte. Ce taux est mis à jour tout au long de la journée, et chaque reçu de commande affiche le taux appliqué. Les versements sont ensuite effectués dans la devise de votre profil de paiement.

Pourquoi un remboursement peut reprendre plus que ce que la vente a rapporté

Sur l'App Store, l'écart vient du calendrier. Les rapports financiers d'Apple reposent sur les transactions traitées et réglées au cours de chaque mois fiscal Apple, et un rapport est généré dès qu'il y a des achats ou des remboursements sur la période. Un remboursement réglé un mois plus tard y apparaît comme une ligne de retour, avec Sale or Return à R, dans la même devise locale que la vente. Il est ensuite converti avec tout le reste de ce mois ultérieur, au taux de ce paiement ultérieur.

Si la devise du storefront s'est appréciée face à la devise de votre banque entre les deux paiements, le remboursement reprend plus que ce que la vente a rapporté. Si elle s'est dépréciée, il reprend moins. Aucun des deux stores ne vous verse la différence ni ne vous facture de frais pour elle. Ce sont simplement deux conversions à deux dates différentes.

Et les remboursements Google Play

La page d'aide de Google fait deux promesses. Pour les commandes passées dans la devise locale de l'acheteur, les remboursements reviennent dans cette même devise, et les variations des taux de change n'affectent pas le montant remboursé. Et tout débit sur votre profil de paiement lié à une rétrofacturation utilise le taux de change du moment où la commande a été passée. Cette seconde phrase fige la rétrofacturation au taux d'origine.

Pour les remboursements ordinaires, la page ne précise pas quel taux convertit le débit de votre côté. Inutile de deviner pour autant. Le rapport mensuel des revenus de Google attribue à chaque ligne, y compris les lignes Charge refund et Google fee refund, son propre Currency Conversion Rate, défini comme le taux utilisé pour convertir les montants de l'acheteur en montants de versement dans votre devise de marchand. Comparez le taux d'une ligne de remboursement avec celui de sa ligne Charge d'origine et vous verrez ce qui s'est passé.

Ce que cela coûte en argent

Voici une illustration chiffrée avec des montants inventés, pour montrer le mécanisme plutôt qu'un taux réel. Supposons que votre Partner Share sur une vente App Store dans un storefront en euros soit de €7.00 et que votre compte bancaire soit en dollars américains.

Côté euros, le solde est nul, exactement comme il se doit. Côté dollars, non, parce que le remboursement a été converti un jour où l'euro valait plus. Inversez les deux taux et vous seriez gagnant de $0.28. Sur une seule vente, c'est négligeable. Sur des milliers de remboursements concentrés sur quelques devises pendant un fort mouvement de change, cela devient de l'argent réel, et cet argent n'apparaît nulle part sous une ligne intitulée perte de change.

Les coûts qu'aucun taux n'efface

La variation de change est la petite partie. La grande partie, c'est ce que vous avez dépensé pour livrer la vente avant qu'elle ne soit remboursée, et rien de tout cela ne revient, dans aucune devise.

• Calcul : le temps de GPU ou de serveur derrière chaque image, vidéo ou réponse de modèle que l'acheteur a déjà reçue.
• Appels d'API : des requêtes tierces facturées dès leur exécution, souvent en dollars, où que vive l'acheteur.
• Stockage : les fichiers créés par l'acheteur, qui restent sur votre facture après le remboursement.
• Reversements : les parts de revenus déjà envoyées aux créateurs, affiliés ou partenaires sur cette vente.

C'est pourquoi les deux flux de remboursement qui vous demandent des preuves comptent davantage que n'importe quel taux de change. Le CONSUMPTION_REQUEST d'Apple vous laisse 12 heures pour envoyer des informations de consommation, et l'examen des rétrofacturations de Google Play via orders.reviewrefund vous laisse 24 heures. Tous les autres remboursements, de la fenêtre en libre-service de 48 heures de Google aux remboursements accordés par le support et aux achats annulés, sont décidés sans vous.

Les rétrofacturations en devises étrangères sur Google Play

À partir du 3 août 2026, Google Play et les développeurs partagent les coûts des rétrofacturations pour les commandes passées après cette date. Le développeur prend en charge le prix d'achat moins les frais de service de Play, plus les frais de rétrofacturation facturés par l'établissement financier. Google continue de prendre en charge ses propres frais de service.

La partie change est prévisible. Comme Google utilise le taux du moment de la commande pour les débits de rétrofacturation, la part correspondant au prix d'une rétrofacturation perdue vous coûte, dans votre devise de versement, le même montant que celui que la vente avait rapporté. Les frais bancaires sont la partie qui n'est pas liée à la vente. Le rapport des revenus de Google indique que les montants des rétrofacturations apparaissent dans le cycle de facturation des revenus du mois suivant, et que les frais de rétrofacturation s'affichent sous forme de total mensuel agrégé une fois les litiges résolus.

Pourquoi vos chiffres de remboursement ne concordent pas d'un rapport à l'autre

Si vos totaux de remboursement diffèrent selon l'endroit où vous les lisez, la devise en est une cause fréquente. Sales and Trends d'Apple estime les montants en USD à l'aide d'une moyenne mobile des taux de change du mois précédent. Payments and Financial Reports utilise le taux réel du paiement, affiché seulement une fois le paiement du mois versé. Apple dit clairement que les remboursements, les nouvelles tentatives de facturation et les conversions de devises peuvent être enregistrés à des moments différents dans chaque système, et demande aux développeurs de ne pas comparer directement les deux totaux.

Une routine de rapprochement rapide

• Rapprochez d'abord les remboursements App Store dans la devise du storefront, à l'aide de Partner Share Currency, avant toute conversion.
• Convertissez au taux du paiement qui a effectivement porté le remboursement, pas au taux de la vente initiale.
• Sur Google Play, associez chaque ligne Charge refund à sa ligne Charge d'origine et comparez leurs valeurs de Currency Conversion Rate.
• Suivez les rétrofacturations séparément des remboursements, puisque Google les facture dans le cycle du mois suivant et ajoute les frais bancaires sous forme de total mensuel.
• Conservez des enregistrements d'usage par transaction, pour qu'un remboursement contestable soit contesté dans la fenêtre de 12 ou 24 heures, quelle que soit sa devise.