Google Play

Google Play earnings reports explained

earnings vs estimated sales, and where the money actually is

Reevee TeamJuly 16, 2026
5 min read

Google Play gives you two financial report families that sound interchangeable and absolutely are not: the estimated sales report and the earnings report. Pick the wrong one for the wrong job and you'll either book revenue that never existed or spend a day hunting a discrepancy that's working as intended.

Here's what each one actually is, why they disagree, and where your money is at any given moment.

The estimated sales report: fast, gross, and not for accounting

The estimated sales report is Google's low-latency view. Per Google's documentation, it can be used "to view low latency information about app, in-app product, or subscription sales" — data is captured daily and posted within a few days into monthly CSV files.

Three properties define it:

  1. It's gross. It "contains the amount paid by buyers and doesn't deduct taxes or Google fees from the totals." The numbers in this file are what customers paid, not what you'll receive.
  2. It's in buyer currency only. It "doesn't contain converted amounts in your payout currency." A row for a Japanese purchase is in yen, full stop.
  3. It's incomplete by design. It doesn't account for withholding taxes or chargebacks.

Google's own guidance: use it "for analytics or trend analysis," but it's "not recommended for accounting." It's the right file for "did the price test move conversion?" and the wrong file for "what do I tell my accountant?"

The earnings report: the one that matches your bank

The earnings report is the financial record. Per Google: "The earnings report is generated once per month, and is typically available by the 5th of the following month," and your payout arrives several weeks after the report becomes available.

Where the estimated sales report is one-row-per-sale-ish, the earnings report is transaction-ledger shaped: "Each line in the report represents a type of transaction, like when you charge a customer money or pay Google a fee, along with the original and converted amounts." A single purchase typically expands into multiple lines — the charge, the Google fee, taxes — and refunds, rebills, and adjustments each get their own lines too.

Critically for anyone outside the US: each line carries both the buyer-currency amount and the converted amount in your merchant (payout) currency, along with the currency conversion rate used. This is the only place Google tells you the actual FX rate applied to your money — the estimated sales report never converts at all.

One documented gap: the earnings report "does not include chargebacks." If you reconcile to the cent, chargebacks are a category you have to pick up from payout-level data.

Why the two reports never match

If you sum the estimated sales CSV and compare it to the earnings report for the same month, you will get different numbers every single time, for reasons Google documents:

  • Fees and taxes. Estimated sales is pre-fee, pre-tax; earnings is the full ledger including Google's fee lines and tax lines.
  • Withholding taxes and chargebacks. Excluded from estimated sales; withholding shows in earnings, chargebacks in neither.
  • Currency. Estimated sales in buyer currency; earnings converted at the actual rate. Any FX movement between the sale date and conversion shows up as pure discrepancy.
  • Timing. Estimated sales data posts on a rolling daily basis; earnings is cut once per month. Transactions near month boundaries can land differently.

Neither report is wrong. They're answering different questions: "what sold?" versus "what am I owed?"

RTDN: the real-time layer

Reports tell you about money after the fact. For entitlement state — did this subscription renew, cancel, go into grace period, get voided — Google provides real-time developer notifications (RTDN). Per the Play Billing docs: "Real-time developer notifications (RTDN) is a mechanism to receive notifications from Google whenever there is a change in a user's entitlement within your app."

Delivery is via Google Cloud Pub/Sub — you either receive pushes to an HTTPS endpoint you control or poll a Pub/Sub subscription. Notifications cover subscription events, voided purchases, and one-time product events (e.g., ONE_TIME_PRODUCT_PURCHASED, ONE_TIME_PRODUCT_CANCELED). The point, per Google, is that they "allow you to react immediately to subscription state changes, avoiding the need to poll the Google Play Developer API."

The mental model that keeps everything straight: RTDN is state, reports are money. An RTDN tells you a renewal happened within seconds; the earnings report tells you weeks later exactly what that renewal was worth after fees, taxes, and FX. You need both, and they will never be the same number at the same moment.

Where the money actually is

Google's payout rhythm is simpler than Apple's, because it runs on calendar months. Per the Google payments center: payouts for a given month's activity begin around the 15th of the following month — orders processed, refunded, or charged back from the 1st through the end of a month are paid out together in the next month's cycle. Google doesn't send payouts on weekends or holidays, so the exact date shifts around the 15th.

Then there's bank latency: electronic funds transfers take roughly 2–3 business days to appear; wire transfers can take 5–7 business days.

So a subscription renewal on July 3 looks like this: RTDN within seconds, estimated sales row within about a week, earnings report line by roughly August 5, payout initiated around August 15, cash in your account a few business days later. Same transaction, four different timestamps, three different amounts along the way.

Practical takeaways

  • Analytics and dashboards: estimated sales. Books and reconciliation: earnings report. Never swap them.
  • Expect a permanent gap between the two; the gap is fees + taxes + FX + timing, not missing data.
  • Use RTDN for anything user-facing (entitlements, churn response). Don't try to compute revenue from RTDN events — that's what the earnings report is for.
  • Cash-flow planning: month close → earnings report ~5th → payout ~15th → bank a few days later.

Reevee pulls the earnings and estimated sales data into one model, tags what's estimate versus settled, and handles the currency conversion mismatches for you — so the "why don't these match?" investigation becomes a question you can just ask in chat.

Sources

Stop reconciling this by hand

Reevee normalizes both stores into one picture and answers questions about it.

Get started free