Why don't my Stripe and RevenueCat MRR numbers match?

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

Stripe and RevenueCat rarely agree on MRR because they're measuring different things: Stripe reports what it processed as a payments ledger, while RevenueCat reports subscriber-level entitlement state pulled from the App Store, Play Store, and Stripe combined. Timing differences, proration handling, trial treatment, and currency conversion each shift the number independently. The fix isn't picking a "correct" tool — it's knowing which layer each one reports on and reconciling at that layer.

The two tools are answering different questions

Stripe's MRR (or the MRR you compute from Stripe's subscription objects) answers: "based on active subscriptions in my Stripe account, what's the normalized monthly value?" It's a payments-processor view. It knows about invoices, proration, coupons, and tax — because it generated them.

RevenueCat's MRR answers: "based on entitlement state across every store I'm connected to, what's the normalized monthly value of active subscribers?" It's a subscriber-state view. It's built to unify Apple, Google, and Stripe subscribers under one entitlement model, which means it has to make judgment calls Stripe never has to make, like how to treat a grace period or a pending renewal from Apple's server notifications.

Neither tool is lying. They're built for different jobs, and MRR is a derived metric — small definitional choices compound into visible gaps.

Where the mismatch actually comes from

1. Store-only vs. all-store data. If you sell through App Store Connect and Google Play in addition to Stripe, RevenueCat is aggregating all three. Comparing "RevenueCat total MRR" to "Stripe MRR" is comparing a portfolio number to one slice of it. This is the single most common cause of a "mismatch" that isn't actually a mismatch — it's an apples-to-oranges comparison. If this is your situation, see why App Store revenue looks lower than Stripe revenue for the specific cut Apple takes and how it shows up in reporting.

2. Timing of recognition. Stripe recognizes a subscription as active the moment the invoice is paid. RevenueCat recognizes entitlement based on the receipt or webhook it receives from the store, which can lag by minutes to hours, especially on Apple's server-to-server notifications. At any given snapshot, a handful of subscribers can be "active" in one system and "pending" in the other.

3. Trials. Whether a trialing user counts toward MRR is a configuration choice, not a fixed rule. Stripe's raw subscription list includes trialing subscriptions with a future current_period_start; whether you include their eventual value in MRR depends on how you compute it. RevenueCat has its own trial-conversion logic and typically excludes trial revenue from MRR until conversion. If one of your tools counts trials and the other doesn't, that alone can be a meaningful percentage of the gap on a small app. We cover this tradeoff directly in should trial users count in your metrics.

4. Proration and upgrades/downgrades. Stripe prorates mid-cycle plan changes and reflects that in invoice amounts immediately. RevenueCat's MRR calculation for a given subscriber may use the plan's list price rather than the prorated invoice amount for that specific period, so a customer who just upgraded can show different values in each tool for one billing cycle.

5. Refunds and chargebacks. Stripe reflects refunds close to real time. RevenueCat depends on receiving the refund notification from the store or from Stripe's webhook, and Apple in particular can be slow or inconsistent about surfacing refund events. See do refunds reduce MRR: the honest answer — the short version is yes, eventually, but "eventually" isn't the same timestamp in both tools.

6. Multi-currency conversion. If you charge in multiple currencies, both tools convert to a base currency for reporting, but they may use different FX rates or update frequencies. On a small portfolio this is usually a rounding error; on a portfolio with meaningful non-USD revenue it can be a real gap. If this applies to you, how to handle multi-currency MRR walks through the mechanics.

7. Gross vs. net. Some Stripe-based MRR calculations use gross subscription value; others net out Stripe's own processing fees or applied discounts. RevenueCat generally reports gross subscriber value before store fees. If you're comparing a fee-adjusted Stripe number to RevenueCat's gross number, that's a structural gap, not a bug. For the deeper version of this, see Stripe gross volume vs. net revenue: what's the difference.

How to actually reconcile the two

Don't try to make the numbers match exactly — try to explain the delta. A practical process:

1. Isolate by source. Pull Stripe-only MRR and compare it against RevenueCat's Stripe-app-store filter (RevenueCat lets you segment by store). If those two agree closely, your gap is entirely coming from Apple/Google subscribers, not a Stripe-vs-RevenueCat data problem.
2. Check trial inclusion settings in whatever tool computes your headline MRR. Make this explicit and consistent across every product you run, not just the one you're staring at today.
3. Snapshot at the same moment, ideally right after your billing cycle settles, not mid-cycle when proration and pending renewals are still in flux.
4. Track the gap over time, not just once. A stable 3-5% delta that doesn't grow is a reporting-methodology difference. A widening delta is a signal something's actually broken — a webhook silently failing, a connector losing auth, or refunds not syncing.

If you run more than one or two products, doing this reconciliation manually every week doesn't scale — which is the exact problem SoleOS's Stripe and RevenueCat connectors exist to solve, by normalizing both into one metrics layer with the same MRR definition applied consistently. Disclosure: SoleOS is written by its own team, so take that as a vendor's framing, not a neutral review. If you only run one product and check numbers monthly, native dashboards in Stripe and RevenueCat are probably enough — you don't need a third tool to reconcile two you already trust. You can see exactly how the normalization works in the metrics dictionary, or read more about tracking Stripe and RevenueCat together for the connector-level detail.

What "good" reconciliation looks like

You're not aiming for Stripe MRR to equal RevenueCat MRR to the dollar. You're aiming to be able to say, in one sentence, why they differ and by roughly how much — "RevenueCat is $340 higher because of 12 active Apple subscribers Stripe doesn't see, minus a $60 gap from trial handling." Once you can say that sentence, the mismatch stops being a mystery and becomes a known, stable offset you can ignore in your weekly check-in.

Frequently asked questions

Which number should I report as my "real" MRR?

Whichever one matches the definition you've committed to and can explain. Most solo founders with store-based apps report RevenueCat's cross-store MRR as the headline number and use Stripe as the audit trail for web-only or B2B subscriptions billed directly. Pick one, document the definition, and stay consistent across months so trend lines stay meaningful.

Is a 5-10% gap between the two tools normal?

For a portfolio selling across Stripe and app stores, yes — trial timing, refund lag, and FX conversion alone can produce that range without anything being wrong. Get concerned when the gap grows month over month rather than staying roughly flat, since a growing gap usually means a sync issue, not a definitional one.

Does RevenueCat include Stripe subscriptions or just mobile?

RevenueCat supports Stripe as a source alongside Apple and Google, so if you've connected it, RevenueCat's MRR can include web subscribers too. Whether it does depends on your RevenueCat project setup — check your app's configured entitlements and sources before assuming the totals are apples-to-apples.

Can I just trust Stripe and ignore RevenueCat?

Only if you sell exclusively through Stripe with no mobile app store subscriptions. The moment you have iOS or Android subscribers, Stripe literally cannot see that revenue, so it's not a matter of trust — it's a visibility gap that RevenueCat (or an equivalent store-side tool) is built to close.

How do I check this across many products without doing it manually each week?

Connect each product's Stripe and RevenueCat accounts to a tool that normalizes both into one MRR definition and flags widening gaps automatically — that's the specific job SoleOS's connectors do, though for one or two apps a shared spreadsheet with the same checklist works fine too. See SoleOS vs a spreadsheet for where the line usually gets crossed, or try the live demo to see the reconciliation view with sample data.