Combined MRR for Stripe and RevenueCat, without double counting

If you sell a subscription on the web through Stripe and in your app through RevenueCat, you have two dashboards, two MRR figures and no single answer to "how much do we make a month?". Adding the two numbers together feels right. It is often wrong.

Here is how to get one combined MRR you can trust, and the five places where the quick sum goes off.

1. Both dashboards can see the same subscription

RevenueCat can track purchases made through Stripe, so a customer who subscribes on your website can appear in RevenueCat as well as in Stripe. If you add the two MRR figures, that subscription is counted twice.

The fix is to pick one source of truth per subscription. When a subscription is visible in both, count it once, from the system that actually bills it. RevenueCat stores the Stripe subscription ID on these purchases, so you can match on it:

-- Stripe, plus RevenueCat subscriptions Stripe doesn't bill
select id, customer_ref, mrr from stripe_subscriptions where active
union all
select id, customer_ref, mrr from revenuecat_subscriptions
where active
  and (store <> 'stripe' or stripe_subscription_id not in (
    select id from stripe_subscriptions
  ));

Only App Store, Google Play and other store purchases come from RevenueCat; web purchases come from Stripe.

2. One person, two subscriptions

The opposite case: a customer pays for your web plan in Stripe and separately subscribes in your iOS app. These are two real subscriptions and both belong in MRR. But they are one customer.

If you count customers by source, you report two. That inflates subscriber counts and deflates ARPU. Join them on your own user ID, the one you pass to RevenueCat as the app user ID and set as metadata.user_id on the Stripe subscription, and sum their MRR into one customer.

3. "Monthly" has to mean the same thing

MRR is only comparable if every subscription is normalized the same way:

Weekly plans are common in apps and easy to get wrong. Multiplying by 4 understates them by about 8%.

Decide, and write down, the rest of the definition too: discounts applied or not (applied is usual), tax excluded, trials excluded until they convert, one-time purchases excluded.

4. Gross or net of store fees

Apple and Google keep 15% to 30% of each subscription. Stripe keeps a few percent. If one dashboard shows gross and the other net, the sum is neither.

Use gross MRR, before fees, for growth and comparison. It's what customers pay and it doesn't jump when you qualify for a lower App Store commission rate. Track fees separately if you need net revenue.

5. Currency

App stores pay out in many currencies, and your Stripe account may bill in several. Convert each subscription into one reporting currency, and do it with a rate that doesn't change every time you open the dashboard. A good rule is the reference rate on the day each billing period started. Then last month's MRR stays put when exchange rates move this month.

Putting it together

A combined MRR you can defend has:

• one row per paid, non-trial subscription, counted once across sources,
• every amount normalized to a month the same way,
• gross amounts, after discounts and before tax and fees,
• one reporting currency, converted at a fixed rate per billing period,
• customers merged across sources by your own user ID.

With that, combined MRR should match what Stripe and RevenueCat show for their own subscriptions, and any difference should be explainable by a written definition.

Doing it without the SQL

Joinsight does all of this when you connect Stripe and RevenueCat: deduplication on the Stripe subscription ID, customer merging on user ID, normalization, and conversion at the ECB reference rate of the day each period started. You get combined MRR with the web and mobile split, movements per customer, and, once the snippet is installed, which pages and campaigns brought each customer. The exact rules are on the metric definitions page.