App Store Connect says you sold $9,412 last month. The Google Play Console says $3,108. You add them up, feel pretty good about $12,520 — and then the deposits land: $6,580 from Apple, $2,210 from Google. Nobody stole from you. Every missing dollar has a name: VAT, commission, refunds, withholding, currency conversion, and eventually income tax. The problem isn't the gap itself — it's that most indie developers have no ledger that explains it, so they can't answer the three questions that actually matter: Is my pricing right? Am I on the correct commission rate? Is my cash-flow forecast real?
This guide walks through the full waterfall from sticker price to take-home, explains why the payout never matches the report, and gives you a monthly reconciliation routine that takes about 30 minutes once it's set up.
Three Numbers, Three Different Answers
Every app business has three revenue numbers, and conflating them is where the confusion starts:
- Gross sales — what customers paid, as shown in analytics dashboards. This is the vanity number. It includes tax where the store collects it, and it's usually an estimate that gets trued up later.
- Developer proceeds — what the store says you earned, from the monthly financial reports (Apple) and earnings reports (Google). This is net of commission, tax the store collects and remits, refunds, and chargebacks. It is the number your accounting should be built on.
- The payout — the bank deposit. Proceeds minus any withholding tax, adjusted for currency conversion, and subject to minimum payment thresholds and the store's payment calendar.
If your books record only the bank deposit, your revenue is silently understated and shifted by a month or more. If they record gross sales, revenue is overstated by 30–50% and doesn't match any money you ever receive. The entire art of app-store bookkeeping is wiring these three numbers together so each month closes with zero difference between reported proceeds and received cash.
The Waterfall from Sticker Price to Take-Home
Take a €9.99 subscription sold in a country with 20% VAT, at the standard 30% commission. Here is the honest version of what happens:
| Step | Calculation | Remaining | % of sticker price |
|---|---|---|---|
| Sticker price | — | €9.99 | 100% |
| VAT collected & remitted by the store | €9.99 ÷ 6 | €8.33 | 83% |
| Store commission (standard rate) | 30% × €8.33 | €5.83 | 58% |
| Refunds & chargebacks (assume 3%) | 3% × €5.83 | €5.65 | 57% |
| Income tax at an effective 30% | 30% × €5.65 | €3.96 | 40% |
Roughly 60% of the sticker price never reaches your pocket. A US sale in a state that doesn't tax digital goods starts from a higher base, and a developer on a reduced commission rate keeps meaningfully more (the same VAT-region sale at 15% commission nets €7.08 before refunds — about 71% of sticker). The precise percentage depends on your sales mix, but the structural lesson holds everywhere: gross revenue is not your money. It's the store's money passing through your dashboard.
None of this is hidden. Apple's and Google's program terms spell out every deduction. What's missing from most indie businesses is the tracking — a place where each layer of the waterfall is a recorded, auditable fact instead of a monthly surprise.
The Commission Rate You're Actually Paying
The single most expensive bookkeeping-adjacent mistake in this space is being on the wrong rate. Both stores halve their commission for smaller developers, and enrollment is not automatic everywhere:
Apple's App Store Small Business Program cuts the commission from 30% to 15% on paid apps, in-app purchases, and subscriptions. Eligibility is measured in proceeds — sales net of Apple's commission and certain taxes and adjustments, not gross — and requires that you earned no more than $1 million across your account and all Associated Developer Accounts (any account you own, control, or are owned or controlled by) in the previous calendar year, and no more than $1 million so far in the current year. Two details trip developers up:
- If you cross $1 million mid-year, the standard 30% rate applies to future sales — sales already made at 15% aren't clawed back, and you can re-qualify the year after your proceeds fall back under the threshold.
- Rate changes take effect 15 days after the end of the fiscal month in which your enrollment is approved, so a delayed enrollment costs real money every week it sits in your to-do list.
Google Play's reduced tier applies 15% to the first $1 million you earn each calendar year, with the 30% rate kicking in on earnings above that — you enroll by grouping your associated accounts in Play Console and accepting the terms. One structural difference worth knowing: on Google, all auto-renewing subscriptions are charged the 15% service fee from day one, regardless of program enrollment. On Apple's standard rate, a subscriber pays the 30% rate for their first 12 months and 15% from year two onward — a quiet argument for retention that only matters once you graduate out of the reduced program.
If you're under $1 million and not enrolled in Apple's program, fixing that is plausibly the highest-ROI ten minutes of your year: the enrollment flow lives in App Store Connect under Agreements, Tax, and Banking.
Why the Deposit Never Matches the Report
Even with the correct rate, proceeds and payouts diverge for reasons that are all mechanical — and each one deserves a line in your books:
Payment calendars are not monthly. Apple pays within 45 days of the end of each fiscal month, and its fiscal months don't align with calendar months — a fiscal month can end December 27, with payment arriving January 29. In practice the gap runs about 33 days. Google pays on the 15th of the following month (slipping to the next business day when the 15th falls on a weekend). If you're on accrual accounting, December's revenue is January's or mid-February's cash, and your books need a payout clearing account to bridge the two.
Minimum thresholds delay small payouts. Apple only pays once your proceeds exceed a minimum payment threshold that varies by banking country and currency. A slow month can mean no deposit at all, with the balance rolling forward — which looks like a missing $30 unless you're tracking it.
Refunds and chargebacks are deducted before proceeds. The stores claw back the full transaction, and your refund rate quietly varies by product and region. Booked correctly this is contra-revenue in the month the refund hits the report, not a mystery deduction from the deposit.
Taxes flow through two different doors. For VAT and many sales taxes, the stores act as the merchant of record for tax purposes — in the EU, for example, Google charges, collects, and remits the VAT, so your proceeds are computed on the tax-exclusive base and you generally don't file VAT returns in those countries. Separately, non-US developers face US tax withholding on any US-source amounts, which can run at a 30% flat rate if you haven't filed a W-8BEN or W-8BEN-E in App Store Connect (or the Play Console equivalent). Treaty rates — or simply the fact that payouts often come from the stores' international entities — can reduce that to zero. Either way, withholding shows up as a gap between reported proceeds and the deposit, and it's usually recoverable as a credit — if you record it.
Currency conversion is a real cost. Stores pay out in the currency of your banking arrangement, converting per-territory proceeds along the way. The FX spread is an expense with no invoice, so the only way to see it is to compare reported proceeds per currency against the deposit.
The Accounting Question Most Indies Get Wrong
Should your revenue line show gross sales or net proceeds? For the overwhelming majority of indie developers, the answer is net. Under the revenue-recognition frameworks that apply to US GAAP (ASC 606) and IFRS 15, the test is whether you are the principal in the sale — whether you control the good or service before transfer to the customer — or an agent whose performance obligation is fulfilled when the store makes the sale. When the store is the merchant of record, collects the tax, sets up the payment rails, bears the refund mechanics, and pays you a per-transaction net amount, the store is the principal and your revenue is your proceeds. Booking gross and showing the commission as an expense inflates revenue, distorts any margin ratio you compute, and misstates taxes if anyone ever looks.
The second error is timing: booking the bank deposit as that month's revenue. The deposit settles last month's (or last fiscal month's) proceeds. The correct pattern is:
- Accrue revenue when the sales occur, using the store's estimates if actuals aren't out yet.
- True up to actuals when the monthly financial report lands, posting the estimate-to-actual difference (there almost always is one — currency, refunds, and late adjustments see to that).
- Clear the deposit against the receivable when the payout arrives, with any residual going to withholding, FX, or threshold roll-forward — each its own account.
That last clause is the whole game: when every residual has a named account, a nonzero difference is impossible to miss and takes minutes to explain.
A 30-Minute Monthly Reconciliation Workflow
- Download the actuals. From App Store Connect, pull the monthly financial report (the detailed one that covers every territory, with settlement dates). From Play Console, pull the earnings report. These — not the analytics dashboards — are your source documents.
- Record proceeds by territory and currency. One revenue line per store, with territories and currencies tracked underneath. This is where the audit trail lives: the day you need to answer "why did EU proceeds drop 12% in March," you'll want VAT, commission, and refunds broken out, not one blended number.
- Post the estimate-to-actual adjustment. Difference between what your dashboard projected and what the report says: usually refunds, currency, and mass-payout adjustments.
- Book refunds and chargebacks as contra-revenue in the report month, and watch the rate over time — a rising refund rate is a product signal wearing an accounting costume.
- Reconcile the payout to the receivable. When the deposit lands, match it to the report. Withholding goes to a tax-receivable account (it's often creditable); FX differences go to a currency expense; a short deposit below the minimum threshold stays in the clearing account until next month.
- Verify your commission rate quarterly. Check your Small Business Program enrollment in App Store Connect and your tier in Play Console — especially if you're approaching $1 million in proceeds, where both stores change the rate on future sales. Model the graduation before it happens: crossing the line can reprice your entire margin structure mid-year.
Six steps, one sitting a month. The payoff isn't just clean books — it's that pricing decisions, rate enrollments, and cash forecasting all start running on proceeds instead of the vanity number.
Track the Whole Waterfall in Plain Text
This is exactly the kind of multi-layer reconciliation where plain-text accounting earns its keep. A beancount ledger gives each layer of the waterfall its own account — income:appstore:ios, income:playstore:android, expenses:refunds, assets:receivable:payouts:apple, assets:tax-withheld — so the monthly entry is the explanation, and every figure ties back to a downloaded report you can re-derive years later. Because the ledger is text, the store reports can sit next to it in version control, and the reconciliation becomes a diff instead of a spreadsheet archaeology project. If you want the machinery for importing bank statements and store data, the documentation covers the import pipeline in depth.
Simplify Your Financial Management
App-store revenue is the most reconciled-against-you income most developers will ever have: commissions, taxes, refunds, and payment calendars all take their cut before the money reaches you. Keeping books that mirror that waterfall — instead of a single "app income" line — is what turns a confusing payout into a transparent, auditable system. Beancount.io offers plain-text accounting that's transparent, version-controlled, and AI-ready, so every store report, adjustment, and deposit stays traceable. Get started for free and make your take-home as legible as your code.