Docs

Google Play Billing Fee Split: What to Track

Google Play now separates its service fee from the billing fee — track revenue by fee category before the split distorts your margin reporting.

Revenue

Google Play has split what used to be a single blended cut into two separate charges: a service fee (10% on the first $1M annually, rising for non-recurring purchases) and a billing fee (5%, charged only when a developer uses Google Play’s own billing system) in the US, EEA, and UK from 30 June 2026. From 1 October 2026, developers using alternative billing must also report every transaction and successful download to Google and pay the applicable service fee on it — alternative billing was never free of Google’s cut, it just used to look that way in a dashboard that didn’t separate the two charges out.

The tracking risk here isn’t the fee structure itself, it’s dashboards and revenue reports built on the old assumption that “Play’s cut” is one flat number. A finance view that still reports a single blended take rate will misstate margin for any app using alternative billing, either overstating the saving from skipping Play’s billing system or missing the service fee obligation entirely once the October reporting requirement takes effect. Both are the kind of error that looks fine until an actual reconciliation or audit catches it.

Data Points to Track

  • Billing path per transaction — Google Play Billing versus alternative billing — captured at the point of purchase, not inferred later from settlement data
  • Service fee tier applied per transaction, distinguishing the 10% base rate from the higher non-recurring rates (15% new install, 20% existing install)
  • Billing fee applied separately from the service fee, since the 5% billing fee only applies when Play’s own billing system is used and shouldn’t be blended into a single “Play cut” figure
  • Net revenue by billing path, reported side by side rather than as one combined margin number, so the actual cost difference between paths is visible
  • Alternative billing transaction reporting status, tracking submission success or failure against Google ahead of and after the 1 October 2026 enforcement date

Setup Steps

  1. Tag every purchase event with billing path at the moment of transaction, so fee category can be attributed correctly without reconstructing it from later settlement files.
  2. Update the revenue event schema to carry fee category and rate applied, replacing any single blended “Play fee” field that no longer reflects how the charge actually works.
  3. Build a reporting view that splits net revenue by billing path, so alternative billing’s real margin impact — after its own service fee obligation — is visible rather than assumed.
  4. Confirm the alternative billing transaction-reporting pipeline to Google is wired up and tested ahead of the 1 October 2026 requirement, and log submission outcomes as their own event stream.
  5. Recompute historical margin dashboards that assumed one flat Play fee, and flag the split date clearly so past and future reporting aren’t compared as if the fee structure hadn’t changed.

Actionable Insights

If a margin dashboard still shows alternative billing as categorically cheaper once the October reporting requirement is fully reflected, check whether the service fee obligation on those transactions is actually being captured — a gap here understates cost, not overstates it. If billing-path revenue splits reveal the fee difference between paths is smaller than assumed, that’s useful input for deciding whether the operational overhead of running alternative billing is still worth it for a given app. And any spike in failed alternative billing transaction reports is worth treating as urgent — it’s a compliance gap with a hard enforcement date, not a data-quality nice-to-have.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert