Why doesn't RevenueCat MRR match my App Store payouts?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

RevenueCat MRR and your App Store payout will almost never match, and that's by design, not a bug. RevenueCat estimates recurring revenue from active subscriptions at gross (pre-Apple-commission) price, recognized close to real time. Apple pays out net of its 15-30% commission, on a monthly delay, batched by territory and currency, with refunds and chargebacks netted out separately. You're comparing an estimate of subscription value to a cash-settlement report — they're answering different questions.

The four gaps that cause the mismatch

1. Gross vs. net. RevenueCat's MRR field is typically gross revenue — what the customer paid — not what Apple actually sends you. Apple keeps its commission (30% standard, 15% for Small Business Program members and after year one of a subscription) before the payout hits your bank account. If you're comparing RevenueCat's headline MRR number directly to a payout, you're off by that commission rate before anything else.

2. Timing. RevenueCat recognizes a renewal the moment the subscription event fires. Apple settles payouts roughly 30-45 days after the end of the month in which the sale occurred, and batches everything by the reporting currency and territory. So this month's RevenueCat MRR won't line up with this month's bank deposit — it lines up with a deposit that hasn't landed yet.

3. Proration and upgrades/downgrades. When a user switches plans mid-cycle, Apple prorates the remaining value. RevenueCat generally reflects the new plan's full value going forward rather than the prorated in-between amount, which creates small but real discrepancies in any given period, especially for apps with several tiers.

4. Refunds, billing retries, and grace periods. Apple can refund a user weeks after the original purchase, and that refund shows up in a payout report in a completely different period than the original RevenueCat renewal event. Failed renewals that enter a billing retry or grace period may still count as "active" in RevenueCat for a window even though no cash has moved yet. None of this is RevenueCat lying to you — it's forecasting active subscription value, not accounting for settled cash.

Which number should you actually trust?

Neither one, alone. Use RevenueCat MRR for subscriber health: churn, trials, upgrade paths, engagement with your subscription tiers. Use App Store payout reports (and eventually your bank statement) for cash-basis accounting: what you can actually spend, pay taxes on, or run payroll from. If you only ever look at one, you're either overestimating your bank balance (RevenueCat) or underestimating your subscriber momentum (payouts, which lag).

The practical move for a solo founder is to stop expecting them to match and instead track the relationship between them over time. If RevenueCat MRR is growing 8% month over month and your payouts, once currency and timing are normalized, are also trending up at roughly that rate net of Apple's cut, you're fine — the gap is structural, not a problem. If the gap widens suddenly (payouts flat while RevenueCat MRR climbs), that's worth investigating: rising refund rates, a spike in failed renewals stuck in grace period, or a reporting error somewhere.

A simple reconciliation habit

You don't need a finance team to sanity-check this monthly:

1. Pull RevenueCat gross MRR for the month.
2. Multiply by (1 - your blended Apple commission rate) to approximate expected net.
3. Compare that to the payout Apple actually reports for the matching sales period, not the calendar month you're currently in.
4. Note the delta and whether it's explained by refunds, currency, or timing you already expected.

If you run more than one or two apps, doing this by hand every month gets old fast, especially once you add Stripe for a web product and Play Console for Android. That's the exact reconciliation problem covered in more depth in tracking Stripe and RevenueCat together — the same gross-vs-net, timing-lag logic applies across both platforms, and the metrics dictionary spells out the exact formula SoleOS uses for each source so you're not guessing at what "MRR" means in a given screen.

Where a portfolio view actually helps

Disclosure: SoleOS is built by the same team writing this post, so take the following as informed rather than neutral. If you run one app and check RevenueCat and App Store Connect directly once a week, you almost certainly don't need another tool layered on top — the raw dashboards are enough, and a spreadsheet can hold your monthly reconciliation notes just fine (see SoleOS vs a spreadsheet for where that stops working).

Where it gets harder is once you're running several apps across App Store, Play Store, and Stripe, and you want to see gross MRR trends per app next to actual payout trends without opening five dashboards and doing the math each time. SoleOS connects to RevenueCat, App Store Connect, Play Console, and Stripe read-only (see what SoleOS connects to for exact scopes) and surfaces both the subscriber-based number and the settlement-based number side by side per project, so the gap is visible instead of silently confusing you. It won't tell you which number is "correct" — because neither is wrong — it just stops you from mentally averaging two incompatible figures into a made-up truth. You can see this laid out with sample data in the live demo, no sign-up required, or check pricing if you're past the demo stage.

Frequently asked questions

Is RevenueCat MRR always higher than my App Store payout?

Usually, yes, because RevenueCat's default MRR figure is gross of Apple's commission and recognized before the cash settles. Once you normalize for the commission rate and the settlement delay, the two should track each other directionally even if they never match exactly in any given calendar month.

Should I use net revenue in RevenueCat instead of gross?

RevenueCat can show net-of-commission figures if you configure it correctly per product and store. That gets you closer to payout reality, but timing lag and refund/grace-period effects still remain, so don't expect an exact match even then.

How do refunds affect this comparison?

A refund reduces the App Store payout in the period Apple processes it, which can be weeks or months after the original sale that RevenueCat counted as a renewal. If you see MRR holding steady while payouts dip, check your refund rate for the prior period before assuming something's broken.

What if the gap is much bigger than expected?

Check three things first: currency conversion assumptions, whether you're comparing matching sales periods (not calendar months), and your Small Business Program status with Apple, which changes your commission rate from 30% to 15% after enrollment or after a subscriber's first year.

Does this same gap exist between Stripe and RevenueCat?

Yes, for similar reasons — gross vs. net, timing of payout batches, and refund handling all differ between the two. It's covered specifically in tracking Stripe and RevenueCat together if you're running both a web and mobile product side by side.