I tuoi report sui rimborsi non coincidono mai tra Apple, Google e il tuo server, ecco come riconciliarli

Estrai il numero di rimborsi da App Store Connect, poi estrailo dal tuo server, e i due numeri non coincideranno. Estraine un terzo dal tuo financial report e non coinciderà con nessuno dei due. Non è un bug nel sistema di nessuno. Apple e Google segnalano ciascuno i rimborsi tramite più di una superficie, ogni superficie conta un momento diverso nella vita del rimborso, e il tuo server ne vede un quarto. Se hai mai provato a riconciliare i report sui rimborsi e hai rinunciato perché i totali si allontanano, ecco perché si allontanano, di quale numero fidarti per ogni compito, e come allinearli per transazione anziché per mese.

Perché uno stesso rimborso compare come tre numeri diversi

Un singolo rimborso attraversa diversi sistemi prima di essere liquidato, e ogni sistema lo annota in un istante diverso. Il tuo server lo apprende per primo, come un evento. Un report di analisi rapida lo stima subito dopo. Il report contabile lo registra per ultimo, una volta che il denaro si è effettivamente mosso. Stesso rimborso, tre marche temporali, tre totali. L'errore è trattarne due qualsiasi come se dovessero essere uguali nello stesso giorno.

Apple ti dà due famiglie di report, più il tuo webhook

Apple segnala i rimborsi in due posti che non sono lo stesso strumento e non sono pensati per quadrare in un dato giorno. Sales and Trends è la vista rapida e stimata: i report giornalieri arrivano il giorno dopo, quelli settimanali il lunedì, e quelli mensili circa cinque giorni dopo la fine del mese, di solito entro le 8 a.m. ora del Pacific. Stima vendite e proventi in USD usando una media mobile dei tassi di cambio del mese precedente, il che lo rende buono per cogliere una tendenza e sbagliato per quadrare un pagamento. Payments and Financial Reports è la vista liquidata: generato una volta al mese secondo il calendario fiscale di Apple, disponibile entro il primo venerdì del mese fiscale in corso per il mese fiscale precedente, e generato solo se ci sono stati acquisti o rimborsi in quel periodo. Usa il tasso di cambio finalizzato applicato al tuo pagamento. Quel report è il registro contabile. Accanto a entrambi, il tuo server riceve l'App Store Server Notification REFUND nel momento in cui Apple concede un rimborso, collegata a un singolo id di transazione.

Google si divide allo stesso modo

Google Play rispecchia la stessa divisione. Il earnings report è il registro contabile, generato mensilmente e di solito disponibile entro il 5 del mese successivo, ed elenca i rimborsi come tipi di transazione a sé: Charge refund per il denaro restituito all'acquirente e Google fee refund per la commissione di servizio che Google restituisce, ciascuno etichettato come Full o Partial. Il estimated sales report è la vista di analisi a bassa latenza che mostra quanto hanno pagato gli acquirenti al lordo di tasse e commissioni, e Google dice chiaramente che è adatto all'analisi e non è consigliato per la contabilità. Lato server ricevi la Real-time Developer Notification in tempo reale e puoi rileggere un rimborso dalla Voided Purchases API.

Come Apple mostra un rimborso dentro il report, e la trappola della riga negativa

Apri il Summary Sales Report e un rimborso non si sottrae in silenzio da una vendita. Compare come una riga a sé. Le Units e il Customer Price di quella riga sono negativi, ed è così che riconosci un rimborso, e la cifra di Developer Proceeds non si comporta come il prezzo. Il report non è intrinsecamente al netto dei rimborsi. Elenca le righe di rimborso accanto alle righe di vendita, e sta a te raggrupparle. Somma la colonna Units a occhio e conterai il doppio o mancherai del tutto i rimborsi, perché una riga di rimborso di meno uno sta nella stessa colonna delle tue vendite positive.

La regola pratica è semplice: trova i rimborsi dalle Units negative, somma quelle righe a parte, e non dare mai per scontato che il report le abbia già sottratte per te. Un conteggio dei tuoi rimborsi per un featured snippet è il numero di righe con Units negative, non la somma aritmetica di una colonna.

Il calendario fiscale è il motivo per cui i tuoi totali mensili non quadrano mai

Ecco il motivo principale per cui un foglio di calcolo curato continua a rifiutarsi di quadrare. I report finanziari di Apple non seguono i mesi solari. Seguono un calendario fiscale 4-4-5, dove la maggior parte dei mesi fiscali dura quattro settimane e ogni terzo ne dura cinque. Uno sviluppatore che confronta un Financial Report con una semplice finestra da gennaio a gennaio sta confrontando due intervalli di giorni diversi, quindi i totali dei rimborsi non possono coincidere anche quando ogni numero sottostante è corretto. Sviluppatori sugli stessi forum di Apple hanno visto le cifre di Sales e quelle del Financial Report divergere di migliaia di dollari esattamente per questo motivo, con il divario che si allargava ogni mese in cui lo lasciavano accumulare.

Il earnings report di Google è mensile, ma porta con sé una propria tempistica e un proprio fuso orario, e nessuno dei due è l'orologio UTC del tuo server. La trappola più profonda è comune a entrambi gli store: un rimborso è attribuito alla data in cui viene liquidato, non alla data della vendita originale. Rimborsa un acquisto di marzo a inizio aprile e riduce i tuoi numeri di aprile, non quelli di marzo. Allinea due mesi per le loro etichette e il rimborso sembrerà svanito dall'uno e materializzato nell'altro.

Quanto costa un rimborso, e in quale report leggerlo

La riconciliazione è in realtà una questione di contabilità, quindi segui il denaro. In un rimborso lo store restituisce la propria commissione, il che significa che l'importo che esce davvero dal tuo conto è la tua quota della vendita, non l'intero prezzo che il cliente vede restituito. Su Google Play quella restituzione è una riga visibile: il tipo di transazione Google fee refund sul tuo earnings report è la commissione di servizio che ti torna, accanto al Charge refund andato all'acquirente. Sull'App Store, Apple detrae i tuoi proventi al netto della commissione e restituisce la sua commissione nello stesso movimento, quindi il financial report mostra la detrazione al netto della quota di Apple.

La tempistica del flusso di cassa è dove gli sviluppatori restano sorpresi. Su Google Play, se rimborsi un ordine prima che Google ti abbia pagato per esso, semplicemente non ricevi mai quell'importo. Se rimborsi dopo il pagamento, Google lo detrae da un pagamento futuro. E se un'ondata di rimborsi spinge il tuo saldo in negativo e resta negativo per almeno 48 ore, Google addebiterà sul conto bancario che di norma riceve i tuoi pagamenti l'importo mancante. Un chargeback è la versione più dura dello stesso evento: su Google Play, per gli ordini effettuati il August 3, 2026 o dopo, il chargeback sposta il prezzo di acquisto più le commissioni della banca sullo sviluppatore, e finisce sul report di un mese successivo a quello della vendita.

Come riconciliare i tuoi report sui rimborsi, passo dopo passo

Il lavoro diventa semplice appena smetti di cercare di rendere ogni numero uguale e invece assegni ogni numero alla domanda a cui risponde. Ci sono solo due domande: quanto denaro si è mosso, e chi ha ancora accesso.

• Decidi la domanda prima di aprire un report. Per il denaro, la risposta sta nel financial report di Apple e nel earnings report di Google, punto. Per l'accesso, la risposta sta nelle notifiche del tuo server. Non riconciliare mai l'uno contro l'altro.
• Scegli l'id di transazione come chiave di join su tutte e quattro le superfici. È l'unico campo che una vendita, il suo rimborso, i report e il tuo webhook condividono tutti.
• Per Apple, quando il Summary Sales Report e il tuo webhook non concordano, chiama l'endpoint Get Refund History dell'App Store Server API a /inApps/v2/refund/lookup/{transactionId}. Restituisce le transazioni rimborsate firmate di un cliente, con revocationDate e revocationReason, un id di transazione alla volta, e pagina attraverso la sua cronologia. Quell'endpoint è l'ago della bilancia.
• Per Google, confronta le righe Charge refund del earnings report con ciò che la Voided Purchases API riporta per gli stessi ordini, e ricorda che un rimborso parziale è contrassegnato come Partial e non azzererà l'addebito originale.
• Allineati sull'orologio del report, non sul tuo. Quello di Apple è un mese fiscale in ora del Pacific. Il earnings report di Google ha un proprio mese e fuso orario. I tuoi log sono quasi certamente in UTC. Converti al calendario del report prima di confrontare, altrimenti i soli confini del giorno creeranno discrepanze fantasma.
• Aspettati che la stima si muova. Sales and Trends è una stima e continuerà a cambiare man mano che le transazioni si liquidano. Riconcilia con il financial report, mai con la stima, e mai con l'istantanea di ieri della stima.

Quando il tuo server mostra più rimborsi del report

Il panico più comune è trovare più notifiche REFUND sul tuo server che righe di rimborso nel sales report per la stessa finestra. Di solito non è denaro perso. Le due superfici contano momenti diversi, una notifica può precedere la riga del report di giorni, e un rimborso parziale o una richiesta reinviata può produrre più di un evento. Gli sviluppatori hanno riportato esattamente questa forma, migliaia di notifiche REFUND a fronte di un conteggio più piccolo di righe con Units negative per lo stesso mese. Risolvilo sempre allo stesso modo: prendi gli id di transazione che il tuo server ha visto, passali attraverso Get Refund History, e lascia che il registro di Apple stabilisca quali sono stati davvero rimborsati e per quanto.

La versione breve

Non puoi far mostrare alla stima di Apple, al financial report di Apple, al earnings report di Google e al tuo webhook lo stesso totale di rimborsi nello stesso giorno, e dovresti smettere di provarci. Leggi ciascuno per ciò che è fatto per dirti. Fidati del financial report e del earnings report per il denaro, fidati delle notifiche del tuo server per l'accesso, e quando due superfici litigano, uniscile sull'id di transazione e lascia che la ricerca Get Refund History o Voided Purchases risolva il pareggio. I rimborsi riconciliati non sono totali che coincidono. Sono transazioni che coincidono.