ASC 606 for Indie App Developers: Should You Record App Store Revenue Gross or Net?

Open App Store Connect or the Google Play Console and you'll see a number that feels like your revenue. Last month it said $10,000. Your bank account received $7,000. Neither number is wrong — but only one of them belongs on your income statement as "revenue," and getting that decision backward can quietly distort your gross margin, misstate your growth rate, and hand a lender or investor a picture of your business that isn't true.

This is the principal-versus-agent question, and under U.S. GAAP's ASC 606 revenue recognition standard, it's not optional paperwork — it's the rule that decides whether you report $10,000 in revenue and a $3,000 cost of sales, or just $7,000 in revenue with nothing else to say. For an indie developer selling through Apple's App Store or the Google Play Store, the answer usually surprises people.

The Question Every App Developer Eventually Asks​

The trigger is almost always the same: a founder is putting together a pitch deck, applying for a small-business loan, or just trying to answer "how much did I actually make this quarter," and realizes they've been recording whatever hit their bank account as "sales." That number is net of Apple's or Google's commission — meaning it already has the platform's cut subtracted out.

The problem is that netting your revenue against a platform fee isn't a stylistic choice. ASC 606 has a specific test for exactly this situation, and it hinges on one question: who controls the thing being sold before it changes hands with the customer?

The ASC 606 Control Test, in Plain English​

ASC 606's five-step revenue model requires you to identify the performance obligations in a contract and determine who is satisfying them. When a marketplace or platform sits between you and the end customer — Apple, Google, Etsy, DoorDash, Uber — accounting standards call this the principal versus agent assessment, and PwC's revenue guide notes that app store sales are a textbook example of arrangements that require this careful look.

• Principal: you control the good or service before it transfers to the customer. You recognize the full, gross amount the customer paid as revenue, and the platform's commission becomes a cost of sales (an expense), not a reduction of revenue.
• Agent: the platform controls the offering and you're just arranging the sale on someone else's behalf. You recognize only the net amount you keep as your fee.

Three indicators decide which one you are, per the Deloitte and PwC frameworks:

1. Fulfillment responsibility — who is on the hook if the app doesn't work, the subscription doesn't deliver, or a customer complains? That's usually you, the developer, not Apple.
2. Risk before transfer — who bears the risk that the "inventory" (your app, your content, your subscription tier) doesn't sell or satisfy the customer? Again, typically you.
3. Price-setting discretion — who sets what the customer actually pays? You choose your app's price tier; the platform doesn't negotiate it with you deal by deal.

Because most indie developers control the product experience, own the customer relationship for support and updates, and set their own pricing, they land on the principal side of the test — meaning the correct accounting is to record the gross amount the customer paid as revenue, and treat Apple's or Google's cut as a cost of revenue line, not an invisible haircut.

The Numbers Behind the Cut​

Knowing you're the principal only matters if you know what's actually being deducted. The platform fee structures shifted meaningfully over the past few years, and most developers are still budgeting off outdated assumptions:

Plus flat annual costs most people forget to allocate anywhere: Apple's $99/year developer program fee, and Google's one-time $25 registration fee. Small, but they belong somewhere in your chart of accounts too — usually a general operating expense, not cost of sales.

Recording It Correctly: A Worked Example​

Say a customer buys a $9.99 in-app subscription through Apple, and you're under the standard 30% rate. Apple collects the $9.99 from the customer, keeps $3.00, and eventually deposits $6.99 to your bank account. Recording $6.99 as "revenue" understates your top line by 30% — which matters enormously if you're comparing your growth rate to a competitor who sells direct, or explaining your margins to a lender.

The correct entries recognize the full sale, then separately book the commission as an expense:

2026-07-18 * "Apple" "iOS subscription — gross sale"
  Assets:Receivable:AppStore          9.99 USD
  Income:AppSales                    -9.99 USD
 
2026-07-18 * "Apple" "30% App Store commission"
  Expenses:CostOfRevenue:PlatformFees 3.00 USD
  Assets:Receivable:AppStore         -3.00 USD
 
2026-07-20 * "Apple" "Payout received"
  Assets:Checking                     6.99 USD
  Assets:Receivable:AppStore         -6.99 USD

Notice the receivable account nets to zero once the payout clears, but your income statement still shows $9.99 in revenue and $3.00 in cost of revenue — a 70% gross margin on that sale, not a mysteriously missing 30%. This is exactly the kind of transaction plain-text, version-controlled ledgers handle well: the gross sale, the platform fee, and the payout are three distinct, auditable events instead of one blurred bank deposit.

Why the Dashboard Number Isn't Enough​

Even once you know the rule, applying it manually is harder than it sounds. Standard App Store Connect and Play Console reports show aggregated totals, not the subscriber-level, transaction-level detail ASC 606 technically wants — proceeds, refunds, and currency conversion often land in a single lump sum days or weeks after the actual sale. That gap is exactly why a growing number of subscription-app businesses use platform APIs or tools like RevenueCat to reconstruct per-transaction detail rather than trying to reverse-engineer it from a monthly summary PDF.

Skipping this step has a real cost. One widely cited example: a developer looked at $3,400 showing in their dashboard for the month, and after commissions, taxes, and other platform deductions, only $1,294 was spendable — a 60%+ gap between the "revenue" they thought they had and what the business actually kept. Developers who make hiring or spending decisions off the dashboard number, instead of the reconciled figure, are budgeting against a number that was never real.

Common Mistakes That Distort Your Books​

• Recording only the net deposit as revenue. This is the most common error and the one this article is about — it understates both revenue and cost of sales, flattening your gross margin picture into something meaningless.
• Ignoring refunds and chargebacks. Apple and Google both process customer refunds on your behalf, sometimes weeks after the original sale — if you're not reconciling by transaction, refunded revenue can sit on your books indefinitely.
• Mixing the $99 Apple developer fee or $25 Google registration fee into cost of sales. These are fixed operating costs, not transaction-level commissions — they belong in a different expense bucket entirely.
• Forgetting the EU's separate fee schedule. If any portion of your user base is in the EU and you've opted into Apple's alternative terms, that revenue has a different commission structure than the rest of your business and needs its own account.

Keep Your Finances Organized as You Scale​

Whether you're a solo developer with one app in the store or running a small studio with a handful of subscription products, the gross-versus-net decision compounds every month you get it wrong — by the time you're raising a round or applying for financing, an understated revenue line is a hard thing to explain away. Beancount.io gives developers a plain-text, version-controlled ledger built for exactly this kind of multi-step transaction — gross sale, platform commission, and payout as three separate, auditable entries instead of one blurry bank deposit. Get started for free and see why developers who already think in code prefer accounting that works the same way.