Why App Store Revenue Recognition Is Harder Than It Looks

Cody Leach, HubiFi's Head of Product Experience and a CPA, walked through this in a recent CPE webinar, "Accounting for App Store Revenue Recognition." Here's what came out of it.

‍

A brief, useful history

None of the infrastructure behind modern software sales was designed with revenue recognition in mind. Salesforce launched in 1999, HubSpot in 2006, the app stores in 2008, and tools like RevPro and SaaSOptics (built for traditional B2B SaaS) in 2009. Stripe followed in 2010. The FASB didn't finalize ASC 606 until 2014, with the transition period wrapping up in 2018.

‍

In other words, every major platform accountants now depend on was built years before the standard that governs how revenue gets recognized on it. That's why teams end up pulling ad hoc reports, patching together spreadsheets, and reverse-engineering data that was never designed to answer accounting questions.

‍

It also explains why revenue today runs through two very different motions: 

‍

• Traditional B2B SaaS, often called sales-led growth, runs through contract and billing systems like Zuora feeding into a GL. 
• Self-serve, product-led, or direct-to-consumer sales run through the app stores or a processor like Stripe. 

‍

No single billing tool handles both well, so most finance teams end up managing separate systems with separate accounting logic.

‍

A newer wrinkle: AI companies increasingly sell through the app stores, but they're selling usage credits, not subscriptions, which pushes teams toward usage and percent-complete accounting on top of everything else. The app stores are only just starting to adjust their reporting to accommodate it.

‍

The reports you're working with

‍

Google Play is the more manageable of the two. There's a sales report, an estimate that finalizes near the start of the next month, though it can be pulled daily, and an earnings report, released on the 15th, that ties to what actually lands in your bank account. Both include an order number that lets you connect the two. 

‍

One limitation worth knowing: Google doesn't track a customer concept. Every order reference stands alone, which makes churn or AR reporting difficult.

‍

Apple is a different story. The reporting infrastructure traces back to the old iTunes system and hasn't changed meaningfully since 2009.

‍

 There are two key reports: 

• The summary sales report gives you bookings but lacks subscriber-level detail, meaning you have to estimate which service dates apply to which subscription. 
• The payout report shows the cash, but it pays out in batches defined by Apple's own sales calendar, not by calendar month. 

‍

A period like "May 31 through June 27" might get paid out on July 30th, which makes tracing any individual sale through to its payment nearly impossible using the standard UI.

‍

Layered on top of that:

‍

• Apple and Google typically charge 30% on new subscriptions and 15% on renewals, though promotional periods, negotiated rates, and first-million-dollar-in-sales deals can all change that math, and none of it is visible in the underlying reports.
• Foreign currency sales need to be converted using an estimated rate at the time of sale.
• Apple's reports separate a "report date" from an "event date," so transactions can surface several days after the period they actually belong to, creating real cutoff risk.
• Google's sales report sometimes misses refunds entirely, only showing up when the deposit lands short.
• Apple has been known to over or underpay a given currency batch, often for smaller markets with lower transaction volume. Most of that ends up absorbed into FX gain and loss.

‍

Where GAAP actually comes into play

‍

Four areas of GAAP show up consistently in App Store accounting:

‍

ASC 606 

ASC 606 governs the core revenue recognition, but the tricky part for app stores is step three, determining the transaction price. 

‍

Foreign currency sales require an FX estimate at the time of booking. Apple's reports also include VAT, which needs to be carved out, or you'll overstate revenue. 

‍

Lifetime subscriptions and credit-based in-app purchases both require estimates about usage patterns to build an accurate recognition schedule.

‍

ASC 340 

ASC 340 covers how you treat the platform fees. 

‍

You generally have three options: 

1. Treat them as a payment processing expense taken when the payment lands.
2. Treat them as a cost of acquiring the customer and match them against the revenue they generated (matching under 606 treatment) .
3. or take the practical expedient and expense them immediately at the point of sale. Teams doing this manually tend to default to the first option simply because the data is already there. Matching against revenue produces a more accurate margin picture but usually requires automation to execute well.

‍

ASC 326 

ASC 326 (CECL) is less of a concern here since Apple and Google only grant entitlement once payment has cleared, so credit loss risk is minimal. 

‍

The bigger issue is the refunds Google's sales report tends to miss, which can require a small accrual or a look-back adjustment.

‍

ASC 310

ASC 310 covers how you present the receivable, gross or net of the fees you know you'll be charged. This is one of the clearer points of divergence between GAAP and IFRS. 

‍

IFRS generally requires net presentation; GAAP leaves more room for judgment, and in practice, roughly half of companies land on each side.

‍

Where this breaks down at scale

‍

Small App Store sellers can often manage this in a spreadsheet for a while. However, once volume increases, usually somewhere around $15 million in ARR, the process stops holding up. Excel has a practical row limit, and companies selling at real scale end up splitting monthly data across multiple files just to stay under it. 

‍

Some teams shift the problem to engineering and build internal scripts against the Apple and Google APIs. That solves the volume issue but hands the accounting logic to a team that isn't accountable for GAAP compliance, and it still doesn't solve the underlying reconciliation problem.

‍

That reconciliation problem is the real bottleneck: tying bookings to actual cash received. 

‍

Apple's payout batches don't align to calendar months, the underlying reports don't include the level of detail needed to trace an individual subscription through to payment, and even third-party tools built on top of Apple's data have been known to get batch cutoff dates wrong.

‍

There's also a real cost to FP&A. 

‍

Manual processes tend to produce numbers only after month end closes, with none of the segmentation (by state, product, or renewal type) that leadership actually wants. That gap tends to create the familiar tension between finance and FP&A over whose revenue number is the real one.

‍

What this means going forward

As more companies, particularly AI companies selling usage-based credits, move onto the app stores, the accounting only gets more layered. 

‍

Usage tracked in an external system has to be reconciled against credits sold and deferred through Apple or Google, two platforms that don't share a customer concept with each other or, in Apple's case, even with their own operational data. 

‍

Bundled offerings (a subscription plus a credit allotment, for example) start to introduce SSP allocation questions that the app stores were never built to support.

‍

None of this makes App Store selling a bad idea. It's simply worth going in with a clear picture of what the accounting actually requires, and where manual processes are going to reach their limit.

‍

Have questions about App Store revenue recognition, or want to talk through your own reporting setup? Reach out to our team at HubiFi.

‍