Why Subscription Revenue Numbers Don't Match Across Platforms

If your MRR in Stripe doesn't match what your finance team reports, the numbers probably aren't wrong: they're answering different questions.

Payment processors, app stores, and billing platforms each apply their own rules about when revenue counts, whether paused and delinquent subscriptions stay in the total, and what a "customer" is. Reconciling them means recalculating from raw subscription states in one place, not averaging the dashboards.

The four reasons the numbers diverge

1. Recognition timing. One platform reports revenue when the invoice goes out; another reports it when the payment clears. Across a month boundary, that alone puts two accurate dashboards thousands of dollars apart.

2. Delinquent and paused accounts staying in MRR. Most subscription management tools count every existing subscription toward monthly recurring revenue, including accounts behind on payment or temporarily paused. The subscription exists, so it gets counted, which is exactly why reported revenue drifts above collected revenue.

3. No shared definition of MRR movement. New, expansion, reactivation, contraction, and churned MRR are distinct categories. Payment processors record transactions; they don't split them into movement types, so an upgrade and a new signup can land in the same bucket.

4. Per-platform customer identity. The same person subscribing through your website and your iOS app is two customer records in two systems, because neither system can see the other. Each platform counts one customer; together they report two. Baremetrics matches records on email address and merges them into a single customer paying you twice, which keeps customer count, ARPU, and LTV from drifting the moment you add a second billing source. The limit is worth knowing: if someone signs up on your site with a work address and buys the app subscription under a personal Apple ID, there's nothing to match on and they stay two records.

What this looks like in numbers

The reason this matters more than a rounding argument is that the errors run in opposite directions. Here's a worked example — illustrative figures, not customer data:

A SaaS company bills through Stripe and the App Store.

Add the two dashboards together and you get $76,000 MRR across 602 customers, or $126.25 ARPU.

Now correct for both problems. Strip the delinquent and paused subscriptions Stripe is still counting: $61,800 − $2,700 − $1,350 = $57,750 in collectible recurring revenue. Then remove the 61 people who subscribe on both platforms under the same email: 602 − 61 = 541 actual customers.

Corrected: $71,950 MRR across 541 customers, or $132.99 ARPU.

So the naive sum overstates MRR by $4,050 and understates ARPU by about 5%. Two errors, opposite signs, one of them flattering — which is why summing dashboards feels close enough right up until you're using ARPU to model payback on acquisition spend.

What each source actually reports

Two caveats that catch people out. Shopify revenue flows into MRR but Shopify fees are excluded, so fee-inclusive net revenue won't reconcile against Shopify's own reporting. And QuickBooks and Xero are accounting sources, not billing sources — connecting one doesn't replace a billing integration, though Forecast+ does require one to model runway and burn.

Which sources to connect

Connect every platform you bill on, even minor ones. A source contributing 3% of revenue still distorts blended churn if it's missing.

Baremetrics normalizes every connected source into one unified MRR and reports 28+ subscription metrics against it, with the option to segment by source. For unsupported processors there are three fallbacks: the Open API (about a day of engineering work), CSV import for historical data and one-off contracts, and manual subscription entry in the dashboard. For the full integration list and setup steps, see How to Connect Multiple Data Sources in Baremetrics.

Separate from revenue sources, a few connectors change what you can do with unified data rather than what goes into it: HubSpot syncs CRM attributes both ways so they're usable as segments, QuickBooks and Xero feed runway and burn through Forecast+, Intercom surfaces subscription context inside support conversations, Slack delivers metric digests, Zapier handles attribute import and export, and an MCP server exposes your metrics to AI tools like Claude and Cursor.

Comparing performance across platforms

Once sources are unified, the useful move isn't the blended number — it's the split. App store subscribers and direct-billing subscribers usually differ on retention, average revenue, and expansion MRR, and the gap is often large enough to change where marketing spend goes. Every metric can be scoped to a single source, and segments can be built from Stripe metadata, Apple and Google subscriber data, HubSpot attributes, Intercom data, or custom attributes pushed via the API.

How the tools compare on multi-source support

Multi-source support is one of the few areas where subscription analytics tools genuinely differ — less in whether they can unify sources than in which platforms they reach and what you can do with the result. 

The honest summary: ChartMogul reaches more native billing platforms, notably PayPal and GoCardless, and can push unified data into a warehouse. Baremetrics goes further once the data is unified — native failed-payment recovery and financial forecasting from your actual P&L, in the same tool rather than bolted on.

Worth knowing that reconciliation quality is a real differentiator here and not just a marketing claim: recurring criticism in ChartMogul's public reviews on G2 and Product Hunt is that its figures don't tie back to Stripe's and need manual correction. That's the failure mode this whole category is supposed to prevent, so it's worth testing on your own data during any trial rather than taking either vendor's word for it.

Where this approach has limits

Being straight about the constraints:

• PayPal and GoCardless have no native connector. Neither do Paddle, Maxio, or Zuora. Revenue billed through them comes in through the Open API — roughly a day of engineering — or by CSV.
• No data warehouse export. If your team's plan is to land unified subscription data in Snowflake or BigQuery alongside product data, Baremetrics doesn't currently offer that path.
• Recover doesn't cover every source. Failed-payment recovery works on Stripe, Braintree, and Recurly only. Chargebee is a supported data source but not a Recover source, and neither are the app stores or Shopify Partners — so revenue from those platforms is unified in your metrics while involuntary churn on them needs handling elsewhere.
• Reconciliation doesn't fix upstream data. If a billing platform has mislabeled subscription states, unifying sources surfaces the problem rather than solving it.