Je refund-rapporten kloppen nooit tussen Apple, Google en je server, zo stem je ze af

Haal het refund-aantal uit App Store Connect, haal het dan uit je server, en de twee getallen komen niet overeen. Haal een derde uit je Financial Report en het klopt met geen van beide. Dit is geen bug in iemands systeem. Apple en Google rapporteren terugbetalingen elk via meer dan één oppervlak, elk oppervlak telt een ander moment in het leven van de terugbetaling, en je server ziet een vierde. Als je ooit hebt geprobeerd refund-rapporten af te stemmen en het hebt opgegeven omdat de totalen uiteenlopen, hier lees je waarom ze uiteenlopen, welk getal je voor welke taak vertrouwt en hoe je ze per transactie in plaats van per maand op één lijn brengt.

Waarom één terugbetaling als drie verschillende getallen verschijnt

Eén terugbetaling passeert meerdere systemen voordat ze verrekend is, en elk systeem noteert haar op een ander moment. Je server hoort er als eerste van, als een gebeurtenis. Een snel analyserapport schat haar daarna. Het boekhoudrapport legt haar als laatste vast, zodra het geld daadwerkelijk verplaatst is. Dezelfde terugbetaling, drie tijdstempels, drie totalen. De fout is er twee behandelen alsof ze op dezelfde dag gelijk moeten zijn.

Apple geeft je twee rapportfamilies, plus je webhook

Apple rapporteert terugbetalingen op twee plekken die niet dezelfde tool zijn en niet bedoeld zijn om op een bepaalde dag te kloppen. Sales and Trends is de snelle, geschatte kijk: dagrapporten komen de volgende dag, weekrapporten op maandag, maandrapporten ongeveer vijf dagen na het einde van de maand, doorgaans tegen 8 a.m. Pacific. Het schat verkoop en opbrengsten in USD met een voortschrijdend gemiddelde van de wisselkoersen van de vorige maand, wat het goed maakt om een trend te zien en verkeerd om een uitbetaling te kloppen. Payments and Financial Reports is de verrekende kijk: eens per maand gegenereerd op Apples fiscale kalender, beschikbaar tegen de eerste vrijdag van de huidige fiscale maand voor de vorige fiscale maand, en alleen gegenereerd als er in die periode aankopen of terugbetalingen waren. Het gebruikt de definitieve wisselkoers die op je uitbetaling wordt toegepast. Dat rapport is de boekhoudkundige registratie. Naast beide ontvangt je server de App Store Server Notification REFUND op het moment dat Apple een terugbetaling verleent, gekoppeld aan één transaction id.

Google splitst op dezelfde manier

Google Play weerspiegelt de splitsing. Het earnings report is de boekhoudkundige registratie, maandelijks gegenereerd en doorgaans beschikbaar tegen de 5e van de volgende maand, en het vermeldt terugbetalingen als eigen transactietypes: Charge refund voor het geld dat aan de koper wordt teruggegeven en Google fee refund voor de servicekosten die Google teruggeeft, elk gemarkeerd als Full of Partial. Het estimated sales report is de analysekijk met lage latentie die toont wat kopers vóór belastingen en kosten betaalden, en Google zegt onomwonden dat het geschikt is voor analyse en niet aanbevolen voor de boekhouding. Aan de serverkant krijg je de realtime Real-time Developer Notification en kun je een terugbetaling teruglezen uit de Voided Purchases API.

Hoe Apple een terugbetaling in het rapport toont, en de negatieve-regel-val

Open het Summary Sales Report en een terugbetaling trekt zich niet stilletjes af van een verkoop. Ze verschijnt als een eigen regel. De Units en de Customer Price op die regel zijn negatief, waaraan je een terugbetaling überhaupt herkent, en het Developer Proceeds cijfer gedraagt zich niet zoals de prijs. Het rapport is niet van nature netto van terugbetalingen. Het vermeldt refund-regels naast verkoopregels, en het is jouw taak om ze te sorteren. Tel de Units-kolom op het oog op en je telt óf dubbel óf mist de terugbetalingen volledig, want een min-één refund-regel staat in dezelfde kolom als je positieve verkopen.

De praktische regel is eenvoudig: vind terugbetalingen aan de negatieve Units, tel die regels apart op, en ga er nooit van uit dat het rapport ze al voor je heeft verrekend. Een als featured snippet bruikbare telling van je terugbetalingen is het aantal regels met negatieve Units, niet de rekenkundige som van een kolom.

De fiscale kalender is waarom je maandtotalen nooit kloppen

Hier is de allerbelangrijkste reden waarom een zorgvuldig spreadsheet toch weigert te kloppen. Apples financiële rapporten lopen niet op kalendermaanden. Ze lopen op een 4-4-5 fiscale kalender, waar de meeste fiscale maanden vier weken zijn en elke derde vijf weken. Een ontwikkelaar die een Financial Report vergelijkt met een gewoon venster van januari tot januari vergelijkt twee verschillende reeksen dagen, dus de refund-totalen kunnen niet overeenkomen zelfs als elk onderliggend getal klopt. Ontwikkelaars op Apples eigen forums hebben gezien hoe Sales-cijfers en Financial Report-cijfers precies om deze reden duizenden dollars uiteenliepen, met een kloof die elke maand groter werd zolang ze hem lieten oplopen.

Googles earnings report is maandelijks, maar draagt zijn eigen timing en zijn eigen tijdzone, en geen van beide is de UTC-klok van je server. De diepere val delen beide stores: een terugbetaling wordt toegerekend aan de datum waarop ze verrekend wordt, niet aan de datum van de oorspronkelijke verkoop. Betaal een aankoop van maart begin april terug en het verlaagt je aprilcijfers, niet je maartcijfers. Leg twee maanden op hun labels naast elkaar en de terugbetaling lijkt uit de ene verdwenen en in de andere opgedoken.

Wat een terugbetaling kost, en in welk rapport je haar leest

Afstemmen is in de kern een boekhoudkundige vraag, dus volg het geld. Bij een terugbetaling geeft de store zijn eigen commissie terug, wat betekent dat het bedrag dat daadwerkelijk je rekening verlaat jouw aandeel in de verkoop is, niet de volle prijs die de klant terugbetaald ziet. Op Google Play is die teruggave een zichtbare regel: het transactietype Google fee refund op je earnings report zijn de servicekosten die naar je terugkomen, naast de Charge refund die naar de koper ging. In de App Store trekt Apple je opbrengsten na commissie af en geeft zijn commissie in dezelfde beweging terug, zodat het Financial Report de aftrek toont netto van Apples deel.

De timing van de kasstroom is waar ontwikkelaars worden verrast. Op Google Play, als je een bestelling terugbetaalt voordat Google je ervoor heeft betaald, ontvang je dat bedrag simpelweg nooit. Betaal je terug na de uitbetaling, dan trekt Google het van een toekomstige uitbetaling af. En als een golf van terugbetalingen je saldo negatief duwt en het minstens 48 uur negatief blijft, debiteert Google de bankrekening die normaal je uitbetalingen ontvangt voor het tekort. Een chargeback is de scherpere versie van hetzelfde gebeuren: op Google Play verschuift, voor bestellingen geplaatst op of na 3 augustus 2026, de chargeback de aankoopprijs plus de kosten van de bank naar de ontwikkelaar, en ze belandt op het rapport van een latere maand dan de verkoop.

Hoe je je refund-rapporten afstemt, stap voor stap

De taak wordt eenvoudig zodra je stopt te proberen elk getal gelijk te maken en in plaats daarvan elk getal toewijst aan de vraag die het beantwoordt. Er zijn maar twee vragen: hoeveel geld is verplaatst, en wie heeft nog toegang.

• Bepaal de vraag voordat je een rapport opent. Voor geld ligt het antwoord in Apples Financial Report en Googles earnings report, punt. Voor toegang ligt het antwoord in je server-meldingen. Stem nooit het ene af tegen het andere.
• Kies de transaction id als je join-sleutel over alle vier de oppervlakken. Het is het ene veld dat een verkoop, haar terugbetaling, de rapporten en je webhook allemaal delen.
• Roep bij Apple, wanneer het Summary Sales Report en je webhook het oneens zijn, het Get Refund History endpoint van de App Store Server API aan op /inApps/v2/refund/lookup/{transactionId}. Het geeft de ondertekende terugbetaalde transacties voor een klant terug, met revocationDate en revocationReason, één transaction id per keer, en bladert door hun historie. Dat endpoint is de doorslaggever.
• Controleer bij Google de Charge refund regels op het earnings report tegen wat de Voided Purchases API voor dezelfde bestellingen rapporteert, en onthoud dat een gedeeltelijke terugbetaling als Partial is gemarkeerd en de oorspronkelijke afschrijving niet op nul zet.
• Richt je op de klok van het rapport, niet die van jou. Die van Apple is een fiscale maand in Pacific-tijd. Googles earnings report heeft zijn eigen maand en tijdzone. Je logs zijn vrijwel zeker UTC. Reken om naar de kalender van het rapport voordat je vergelijkt, anders scheppen de daggrenzen alleen al spookverschillen.
• Verwacht dat de schatting beweegt. Sales and Trends is een schatting en blijft verschuiven naarmate transacties verrekend worden. Stem af tegen het Financial Report, nooit tegen de schatting, en nooit tegen de momentopname van gisteren van de schatting.

Wanneer je server meer terugbetalingen toont dan het rapport

De meest voorkomende paniek is meer REFUND-meldingen op je server vinden dan refund-regels in het verkooprapport voor hetzelfde tijdvak. Het is meestal geen verloren geld. De twee oppervlakken tellen verschillende momenten, een melding kan de rapportregel dagen voorgaan, en een gedeeltelijke terugbetaling of een opnieuw ingediend verzoek kan meer dan één gebeurtenis produceren. Ontwikkelaars hebben precies deze vorm gemeld, duizenden REFUND-meldingen tegen een kleiner aantal regels met negatieve Units voor dezelfde maand. Los het elke keer op dezelfde manier op: neem de transaction ids die je server zag, voer ze door Get Refund History, en laat Apples eigen registratie uitmaken welke daadwerkelijk zijn terugbetaald en voor hoeveel.

De korte versie

Je kunt Apples schatting, Apples Financial Report, Googles earnings report en je webhook niet allemaal op dezelfde dag hetzelfde refund-totaal laten tonen, en je zou moeten stoppen met proberen. Lees elk voor wat het bedoeld is je te vertellen. Vertrouw het Financial Report en het earnings report voor geld, vertrouw je server-meldingen voor toegang, en wanneer twee oppervlakken botsen, verbind ze op de transaction id en laat de Get Refund History of Voided Purchases lookup de knoop doorhakken. Afgestemde terugbetalingen zijn geen gematchte totalen. Het zijn gematchte transacties.