Why the numbers differ from the Stripe dashboard
SadAnalytics and Stripe rarely disagree by accident. Almost every gap traces back to one of the definitions or rules below.
How SadAnalytics defines MRR
Stripe's own MRR figure follows Stripe's rules; SadAnalytics follows the rules below. See MRR in the glossary for the full rule. The short version: SadAnalytics counts subscriptions that are active or past due, plus a trialing subscription only once its trial has been prepaid, and it excludes paused subscriptions entirely. Any of those differences will move the figure away from a number you eyeballed in Stripe.
SadAnalytics also separates the headline subscriber count (which includes past-due and trialing customers) from the paying-subscriber count used for ARPU and lifetime value. If you are comparing a subscriber count to Stripe, make sure you know which of the two SadAnalytics figures you are looking at.
Trialing subscriptions
An unpaid trial contributes $0 to MRR, not the plan's eventual price, and is surfaced separately as trial MRR. If a customer prepaid at the start of their trial, a background step links that payment to the trial (matching an unlinked charge from the same customer within a few days of the trial's start) and counts it in MRR from day one; an unlinked prepaid trial still shows as $0 until that step catches up.
Paused subscriptions
A paused subscription is excluded from MRR completely, not counted at a reduced or zero rate inside it. SadAnalytics reports its value separately as paused MRR so it is not simply invisible, but it will never appear inside the headline MRR figure the way it might in a raw Stripe total.
Refunds
A fully or partially refunded charge never counts toward starting or qualifying a detected subscription (see below), though a refund on a charge already inside a real recurring pattern does not break that pattern. If a refunded renewal gets re-charged a few days later, SadAnalytics keeps the original cadence and treats the re-charge as a one-off payment with the same amount and interval, so the subscription's MRR contribution does not change either way.
Detected subscriptions
Stripe's own subscription objects are not the only source of recurring revenue SadAnalytics counts. When a customer pays the same amount, in the same currency, on a regular cadence, but without a Stripe subscription behind it (a one-time payment link or invoice paid again each month, or a plain charge run on a schedule), SadAnalytics can recognize the pattern and count it as a detected subscription. This means SadAnalytics' revenue can be higher than what Stripe's own MRR-style reporting shows, on purpose.
A customer needs at least three unrefunded charges of the same amount before SadAnalytics will count them this way, so a brand-new recurring buyer will not show up as a detected subscription until their third payment.
Exempted accounts
Any email address listed under Exempted accounts in Settings, then General is deliberately deleted from SadAnalytics everywhere: subscriptions, payments, invoices and the customer row itself. Stripe keeps its own record of that customer regardless, so if you compare a raw Stripe total against SadAnalytics for an account you have exempted (typically your own test purchases, or a staff account), SadAnalytics will always be lower, on purpose.
Currency conversion
SadAnalytics reports every figure in a single "primary currency," the currency it saw most often in your payment data. Amounts in other currencies are converted to it using a cached exchange rate, refreshed at most once a day, but only once you add a free exchange-rate API key in Settings, then General. Saving a new key fetches rates straight away. Without a key, subscriptions in a currency other than the primary currency are left out of MRR outright rather than mixed in unconverted, which will make SadAnalytics' MRR read lower than a simple sum of every Stripe charge regardless of currency.
See multi-currency and exchange rates for how to turn conversion on.
The incremental sync window
A scheduled background sync is incremental: it re-checks every customer and subscription in full, but it only fetches payments and invoices from the earlier of when your last sync started, or 90 days ago. A refund or a recovered payment from further back than that will not appear until the next full sync (a manual "Sync now" always runs full).
The Historical data limit in Settings, then Data Sync only bounds how far back customers, payments and invoices are pulled on a full sync; subscriptions themselves are always fetched with no date limit at all, so a subscriber who signed up before your chosen window still counts fully in MRR.