Table of Contents
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.
| Stripe | App Store | |
| Active subscriptions reported | 412 | 190 |
| Subscription revenue reported | $61,800 | $14,200 |
| Delinquent (failed, not yet cancelled) | 18 subs / $2,700 | — |
| Paused | 9 subs / $1,350 | — |
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
| Source | What it gives you | What it doesn't |
| Stripe | Transaction records, full metadata, customer attributes, fees | Churn cohorts, expansion MRR, forecasts |
| Braintree, Chargebee, Recurly | Subscription states, invoicing | Consistent cross-platform MRR definitions |
| Apple App Store Connect | Subscriber reports and events | Customer-level detail comparable to Stripe |
| Google Play | Subscriber reports and events | Turnkey setup — connection may need engineering time |
| Shopify Partners (native dashboard) | Installs, ratings, publish status, lifetime revenue | Any recurring-revenue metric for your app |
| QuickBooks, Xero | Books, expenses, P&L | Subscription-level revenue movement |
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
| If you sell through… | Connect | Why |
| Your own site only | Your billing platform | Single source, no reconciliation needed |
| Site + mobile apps | Billing platform + Apple App Store Connect + Google Play | Mobile subscribers churn on a different curve than web |
| A Shopify app | Shopify Partners + your billing platform | The Partner Dashboard reports lifetime revenue, not MRR |
| Migrating billing platforms | Both, through the overlap | Keeps the transition from reading as a churn spike |
| A processor with no native connector | Open API or CSV import | Roughly a day of engineering for the API path |
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.
| Baremetrics | ChartMogul | |
| Native billing sources | Stripe, Braintree, Chargebee, Recurly, Apple App Store, Google Play, Shopify Partners | Stripe, Chargebee, Paddle, Recurly, Braintree, PayPal, GoCardless, and more |
| Unified MRR + segment by source | Yes | Yes |
| Native dunning on unified sources | Yes — Stripe, Braintree, Recurly | No — via third-party partners |
| Financial forecasting from accounting data | Yes — Forecast+ with QuickBooks or Xero | No |
| Export unified data to a warehouse | No | Yes — Snowflake, BigQuery, Redshift, S3, Azure (Pro and above) |
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.
Frequently Asked Questions
-
Why doesn't my MRR in Stripe match what my finance team is reporting?
Stripe is a payment processor first, so its MRR figure counts active subscriptions — including paused accounts and unresolved delinquent intervals — rather than collected recurring revenue. Finance teams typically strip those out, which is where the gap opens. Baremetrics recalculates MRR from subscription states and separates new, expansion, reactivation, contraction, and churned MRR into distinct categories, so the reported figure reflects revenue you actually collected.
-
Which subscription analytics tools can unify more than one billing source?
Baremetrics and ChartMogul both connect multiple billing sources and normalize them into a single MRR figure, with the option to segment back out by source. The practical difference is coverage and what happens next: ChartMogul reaches more native billing platforms including PayPal and GoCardless, while Baremetrics adds native failed-payment recovery and financial forecasting on top of the unified data. Check each vendor's current plan details for how many sources your tier includes, since that varies and changes.
-
Can I see MRR separately for app store subscribers versus customers who buy directly on my site?
Yes. Every metric can be filtered to a single connected source, so you can compare retention, ARPU, and expansion MRR for App Store or Google Play subscribers against your direct billing customers. This matters because mobile and web subscribers rarely behave alike, and a blended number hides that. Teams typically use the split to decide which acquisition channel deserves more spend.
-
If the same customer subscribes through two platforms, do I get double-counted?
No. Baremetrics matches customer records across connected sources on email address, so someone with a website subscription billed through Stripe and a second subscription through the App Store is merged into one customer paying you twice, rather than two customers paying once each. Customer count is the denominator for ARPU, LTV, and churn rate, so counting one person twice pushes ARPU down and understates lifetime value across your whole base. It also means a customer who cancels one of two subscriptions reads as contraction rather than as a churn event, which is what actually happened. The exception is a customer who used different email addresses on each platform — with no shared identifier, those records stay separate.
-
Does connecting a second billing platform mid-year break my historical trend lines?
No. Baremetrics pulls the entire transaction history from a payment processor when you connect it, not just activity from the connection date forward. So adding a source in July backfills that platform's full history rather than starting a new line from zero, and your cohort retention and MRR movement charts get deeper instead of resetting. This is also why connecting a platform you've billed on for years is worth doing even if you're moving off it.
-
Can I export unified subscription data into a data warehouse?
Not with Baremetrics. There's no native push to Snowflake, BigQuery, Redshift, S3, or Azure, so teams that need unified subscription data sitting next to product data in a warehouse will need to build that path through the API. ChartMogul offers native warehouse exports on its Pro and Enterprise plans, which is a genuine advantage for data-mature teams with existing BI tooling.
-
What happens to my revenue reporting when I migrate from one billing platform to another?
Connect both platforms and keep them connected through the overlap period. If you disconnect the old source at cutover, every subscription on it reads as churned and your churn rate spikes for a month that had no real cancellations. Running both sources through the transition keeps subscription histories intact so the migration doesn't show up as a revenue event.
