App Store Proceeds Are Not Revenue: Reconciling What Apple Actually Pays You

For the first year of running apps under Virtus Opus I did what most developers do. I looked at the sales chart in App Store Connect, felt good or bad about it, and treated whatever arrived in the bank as the answer. It took one year-end close to discover how little those two numbers had to do with each other, and how much of the difference I could not explain without going back through twelve months of reports.

The problem is not that Apple's reporting is bad. It is that Apple reports the same sale several times, from different points of view, on different calendars, in different currencies. A developer who has spent a career in finance would recognise the pattern immediately: it is the same divergence I described in bookings, billings, revenue and cash, wearing an App Store costume. This post is about taking the costume off.

Four numbers for one purchase

Take a single annual subscription sold to a customer in Germany at a displayed price of €39.99.

The first number is the customer price: €39.99, what the user saw and paid. This is the number most dashboards show by default, and it is the least useful one for a business, because a large part of it never belonged to you. In Germany the displayed price includes VAT, which Apple collects and remits. Strip out 19% and the price before tax is about €33.60.

The second number is proceeds: what is left after Apple's commission. If the developer is in the Small Business Program, or the subscription has been running for more than a year, that commission is 15%; otherwise it is 30%. At 15%, the proceeds on this sale are roughly €28.56. That is the amount Apple owes you, and it is the closest thing in the reports to what you actually sold.

The third number is revenue, in the accounting sense. An annual subscription is a promise to provide the app for twelve months. Under the revenue standards most accountants work with, you earn it over those twelve months, not on the day the customer pays. In the month of sale you have recognised one-twelfth of it, around €2.38, and the rest sits on the balance sheet as deferred revenue.

The fourth number is cash. Apple pays proceeds for a fiscal month roughly a month or more after that fiscal month ends, converted into your bank currency at Apple's rate, net of any refunds and adjustments from earlier periods, and only once the balance for a region clears the payment threshold. A sale made in the first week of a month can easily reach the bank two months later, in a different currency, blended with dozens of other territories and last quarter's refunds.

The sales chart tells you how the product is doing. The payment report tells you what Apple owes you. The bank tells you what you can spend. Only the ledger tells you what you earned, and it needs all three to get there.

Where the gaps come from

Once you know the four numbers exist, almost every reconciliation difference falls into one of six buckets. It helps to know them by name, because the fix for each is different.

Tax

In most territories Apple acts as the seller to the end customer and handles the indirect tax. The customer price includes VAT or GST in many countries and excludes sales tax in others, so a single price tier produces different pre-tax amounts in each market. Any analysis that compares customer prices across countries is comparing numbers with different amounts of tax baked into them. Work from proceeds and the problem largely disappears. Where withholding taxes apply on payments to you, they show up as deductions in the payment report, and they are a separate question for your accountant.

Commission tier

The same product can earn proceeds at two different rates in the same month. A developer outside the Small Business Program pays 30% on a new subscriber and 15% on one who has renewed past a year of paid service. A developer in the programme who crosses the revenue threshold moves to the standard rate the following year. Commission terms also differ by region and have been revised more than once, notably in the EU, so the effective rate is a mix, not a constant. Tracking it as a mix, by month, is the only way to stop it surprising you.

Apple's fiscal calendar

This is the gap that catches almost everyone. Apple's payment reports follow Apple's own fiscal calendar, in which months are made of whole weeks and do not start or end on the first and last day of a calendar month. Your books almost certainly close on calendar months. So the “October” in a payment report and the October in your ledger are not the same period. The difference is usually a few days of sales at each end, which is small in a quiet month and material in a month where a feature or a launch landed in the overlap.

Currency

Proceeds are reported in the currency of each storefront and paid in your bank currency. Apple converts at its own rate on its own date. Your ledger may book the receivable at the month-end rate and the cash at the rate implied by the deposit. Between the two sits a foreign exchange difference that is real, unavoidable and almost always ignored. For a studio paid in dollars but spending in lira, as mine is, that line can be bigger than the profit of a small app.

Refunds and adjustments

Customers ask Apple for refunds, and Apple decides. The refund is deducted from a later payment, not the one that contained the original sale. A month with an unusual number of refunds will therefore show a lower payment for a period in which nothing bad happened, and the period that actually produced the refunded sales will look better than it was. If you want to understand refund rates, match refunds back to their original sale month; the payment report will not do it for you.

Timing and thresholds

Apple pays each region's balance only when it exceeds a minimum. Small storefronts can accumulate proceeds for several months before they are paid. That is not lost money, but it is a receivable, and if nobody is tracking it, it looks like revenue that never turned into cash.

Annual plans and the revenue you have not earned yet

The bucket with the biggest effect on how a studio understands itself is not on that list, because it is not a reconciliation difference at all. It is the gap between proceeds and revenue on annual subscriptions.

In what twelve paywalls taught me I described annual plans as a cash flow instrument: the customer pays for a year up front, and the studio gets the cash early. That is true, and it is exactly why proceeds flatter a growing app. A month in which a paywall change pushed more users toward the annual plan will show a spike in proceeds that is almost entirely deferred revenue. Next month the spike is gone and the chart looks like a decline, when nothing has declined at all. The reverse is also true: an app whose annual cohort from last year is now renewing at a worse rate will show healthy proceeds until the renewal month, and then a cliff that was entirely predictable from the deferred revenue balance.

Keeping a simple deferred revenue schedule — annual proceeds by month of sale, released one-twelfth at a time — turns those spikes and cliffs into a smooth line that actually describes the business. It also gives you the single most useful forward-looking number an app studio has: how much revenue is already contracted for the next twelve months. That figure belongs in any runway model, and it is far more reliable than a projection from last month's downloads.

Whether proceeds or the customer price is the right top line in your statutory accounts — whether you present revenue gross of Apple's commission or net of it — is an accounting judgment that depends on the facts of the arrangement and the rules where you report. For management purposes I use proceeds as revenue and treat Apple's cut as never having been mine, because that is how the economics work. For the statutory accounts I follow what the accountant decides, and I make sure the reconciliation can produce either view.

A monthly reconciliation that takes an hour

None of this needs software beyond a spreadsheet and the reports Apple already provides. What it needs is a fixed routine, run every month, as part of the same discipline I described in the five-day close. Mine runs in four steps.

First, download the financial report for Apple's fiscal month, not the sales and trends data. The sales data is an estimate built for watching the product; the financial report is what Apple will actually pay. Second, map each line to a calendar month in the ledger, accruing the few days of sales that fall outside Apple's period from the daily sales data, and reversing the accrual when the next report arrives. Third, book the proceeds as a receivable from Apple in the reporting currency, split annual subscriptions into the deferred revenue schedule, and record refunds against the month they appear in, with a note of the original sale month for analysis. Fourth, when the payment lands, clear the receivable against the deposit and post whatever is left over as an exchange difference or a threshold balance carried forward.

At the end, three balances should make sense on their own: the receivable from Apple, which should roughly equal the last one or two fiscal months of unpaid proceeds; the deferred revenue balance, which should move with your annual plan sales and renewals; and the exchange difference, which should be explainable by the movement in rates. If any of the three keeps growing without a reason, something is being double-counted or missed.

Why it matters more than it seems

For an app that makes a few hundred dollars a month, this can look like overkill. I would argue the opposite. Small apps are exactly where the gaps are proportionally largest — a single refund, a threshold balance, an exchange movement can be most of a month's earnings — and exactly where developers make keep-or-kill decisions on the strength of a chart. In the carrying cost of an iOS app I argued that each app needs its own ledger to answer whether it is worth keeping alive. That ledger is only as good as the revenue line at the top of it, and the revenue line is only as good as this reconciliation.

It matters more again the day the studio becomes something else. If an app is ever sold, a buyer's first question will be whether the revenue in the pitch ties to the money in the bank. If the studio raises money or takes on a partner, the same question comes from an investor. If a tax office asks, it comes with a deadline. Each of those conversations goes very differently depending on whether the answer is a reconciled sheet built month by month, or a weekend spent rebuilding a year from exported reports — the same lesson as keeping one source of truth before anyone asks for a dashboard.

The App Store makes selling software remarkably easy. It does not make understanding what you sold easy, and it was never meant to. That part is the developer's job, and it is one hour a month.

If you run an app or a small portfolio of apps and want help setting up the reconciliation, the deferred revenue schedule or the per-app ledger behind it, I am glad to help.