Your refund reports never match across Apple, Google, and your server, here's how to reconcile them

Pull the refund count from App Store Connect, then pull it from your server, and the two numbers will not match. Pull a third from your financial report and it will not match either one. This is not a bug in anyone's system. Apple and Google each report refunds through more than one surface, every surface counts a different moment in the refund's life, and your server sees a fourth. If you have ever tried to reconcile refund reports and given up because the totals drift apart, here is why they drift, which number to trust for which job, and how to line them up by transaction instead of by month.

Why one refund shows up as three different numbers

A single refund passes through several systems before it settles, and each system writes it down at a different instant. Your server hears about it first, as an event. A fast analytics report estimates it next. The accounting report records it last, once the money has actually moved. Same refund, three timestamps, three totals. The mistake is treating any two of them as if they should be equal on the same day.

Apple gives you two report families, plus your webhook

Apple reports refunds in two places that are not the same tool and are not meant to tie out on a given day. Sales and Trends is the fast, estimated view: daily reports land the next day, weekly reports on Mondays, monthly reports about five days after the month ends, generally by 8 a.m. Pacific. It estimates sales and proceeds in USD using a rolling average of the previous month's exchange rates, which makes it good for spotting a trend and wrong for tying out a payout. Payments and Financial Reports is the settled view: generated once a month on Apple's fiscal calendar, available by the first Friday of the current fiscal month for the prior fiscal month, and generated only if there were purchases or refunds in that period. It uses the finalized exchange rate applied to your payout. That report is the accounting record. Alongside both, your server receives the App Store Server Notification REFUND the moment Apple grants a refund, keyed to a single transaction id.

Google splits the same way

Google Play mirrors the split. The earnings report is the accounting record, generated monthly and typically available by the 5th of the following month, and it lists refunds as their own transaction types: Charge refund for the money returned to the buyer and Google fee refund for the service fee Google hands back, each tagged Full or Partial. The estimated sales report is the low-latency analytics view that shows what buyers paid before taxes and fees, and Google says plainly it is suitable for analytics and not recommended for accounting. On the server side you get the real-time Real-time Developer Notification and can read a refund back from the Voided Purchases API.

How Apple shows a refund inside the report, and the negative-line trap

Open the Summary Sales Report and a refund does not quietly subtract itself from a sale. It appears as its own row. The Units and the Customer Price on that row are negative, which is how you spot a refund at all, and the Developer Proceeds figure does not behave the way the price does. The report is not inherently net of refunds. It lists refund lines next to sale lines, and it is your job to bucket them. Sum the Units column by eye and you will either double count or miss the refunds entirely, because a minus one refund line sits in the same column as your positive sales.

The practical rule is simple: find refunds by the negative Units, add those rows up on their own, and never assume the report already netted them out for you. A featured snippet count of your refunds is the count of negative-Unit rows, not the arithmetic sum of a column.

The fiscal calendar is why your monthly totals never line up

Here is the single biggest reason a careful spreadsheet still refuses to balance. Apple's financial reports do not run on calendar months. They run on a 4-4-5 fiscal calendar, where most fiscal months are four weeks and every third one is five weeks. A developer comparing a Financial Report against a plain January-to-January window is comparing two different spans of days, so the refund totals cannot match even when every underlying number is correct. Developers on Apple's own forums have watched Sales figures and Financial Report figures diverge by thousands of dollars for exactly this reason, with the gap widening every month they let it accrue.

Google's earnings report is monthly, but it carries its own timing and its own timezone, and neither is your server's UTC clock. The deeper trap is shared across both stores: a refund is attributed to the date it settles, not the date of the original sale. Refund a March purchase in early April and it reduces your April numbers, not your March ones. Line up two months by their labels and the refund appears to have vanished from one and materialized in the other.

What a refund costs, and which report to read it in

Reconciliation is really an accounting question, so follow the money. On a refund the store returns its own commission, which means the amount that actually leaves your account is your share of the sale, not the full price the customer sees returned. On Google Play that return is a visible line: the Google fee refund transaction type on your earnings report is the service fee coming back to you, sitting next to the Charge refund that went to the buyer. On the App Store, Apple deducts your post-commission proceeds and gives its commission back in the same motion, so the financial report shows the deduction net of Apple's cut.

The cash-flow timing is where developers get surprised. On Google Play, if you refund an order before Google has paid you for it, you simply never receive that amount. If you refund after the payout, Google deducts it from a future payout. And if a wave of refunds pushes your balance negative and it stays negative for at least 48 hours, Google will debit the bank account that normally receives your payouts for the shortfall. A chargeback is the sharper version of the same event: on Google Play, for orders placed on or after August 3, 2026, the chargeback moves the purchase price plus the bank's fees onto the developer, and it lands on a later month's report than the sale did.

How to reconcile your refund reports, step by step

The job gets simple once you stop trying to make every number equal and instead assign each number to the question it answers. There are only two questions: how much money moved, and who still has access.

• Decide the question before you open a report. For money, the answer lives in Apple's financial report and Google's earnings report, full stop. For access, the answer lives in your server notifications. Never reconcile one against the other.
• Pick the transaction id as your join key across all four surfaces. It is the one field that a sale, its refund, the reports, and your webhook all share.
• For Apple, when the Summary Sales Report and your webhook disagree, call the App Store Server API Get Refund History endpoint at /inApps/v2/refund/lookup/{transactionId}. It returns the signed refunded transactions for a customer, with revocationDate and revocationReason, one transaction id at a time, and pages through their history. That endpoint is the tiebreaker.
• For Google, cross-check the Charge refund lines on the earnings report against what the Voided Purchases API reports for the same orders, and remember a partial refund is tagged Partial and will not zero out the original charge.
• Align on the report's clock, not yours. Apple's is a fiscal month in Pacific time. Google's earnings report has its own month and timezone. Your logs are almost certainly UTC. Convert to the report's calendar before you compare, or the day boundaries alone will create phantom mismatches.
• Expect the estimate to move. Sales and Trends is an estimate and will keep shifting as transactions settle. Reconcile against the financial report, never against the estimate, and never against yesterday's snapshot of the estimate.

When your server shows more refunds than the report

The most common panic is finding more REFUND notifications on your server than refund rows in the sales report for the same window. It is usually not lost money. The two surfaces count different moments, a notification can precede the report row by days, and a partial refund or a resubmitted request can produce more than one event. Developers have reported exactly this shape, thousands of REFUND notifications against a smaller count of negative-Unit rows for the same month. Resolve it the same way every time: take the transaction ids your server saw, run them through Get Refund History, and let Apple's own record settle which ones actually refunded and for how much.

The short version

You cannot make Apple's estimate, Apple's financial report, Google's earnings report, and your webhook all show the same refund total on the same day, and you should stop trying. Read each one for what it is built to tell you. Trust the financial report and the earnings report for money, trust your server notifications for access, and when two surfaces fight, join them on the transaction id and let the Get Refund History or Voided Purchases lookup break the tie. Reconciled refunds are not matched totals. They are matched transactions.