You open Stripe. The dashboard says $18,400 MRR. You screenshot it and post it in your team Slack.
Two weeks later your accountant sends you a different number. Your investors ask why the figures don't reconcile. You go back to Stripe and the number has quietly changed.
This is not a Stripe bug. It is a misunderstanding of what Stripe is built to do — and what it is not. Stripe is exceptionally good at moving money, handling card networks, and managing subscriptions at scale. It is not a revenue analytics platform.
What Stripe Actually Shows You
When you look at MRR in the Stripe dashboard, you are looking at the sum of all active subscription amounts normalized to a monthly value. Stripe computes this in real time from the current state of your subscription objects.
That sounds correct. The problem is in the word "current." Stripe shows you a snapshot of subscriptions as they exist right now, not a carefully calculated financial metric that follows accounting logic. The moment any of the five conditions below apply to your account, the snapshot diverges from your actual recurring revenue.
Five Ways Stripe Distorts Your MRR
1. Failed Payments Still Count as Active Revenue
When a customer's card fails, Stripe does not immediately cancel the subscription. Instead, it enters a dunning cycle — retrying the charge over several days or weeks depending on your configuration.
During this entire retry window, the subscription remains in active status. Stripe continues to include that customer's monthly amount in your MRR figure.
If you have $20,000 MRR and 8% of your payments are failing, that is $1,600 that Stripe is counting as revenue you have not collected and may never collect.
The real impact: Failed payment rates of 5–10% are common in SaaS. For a $20,000 MRR business, this single distortion alone can overstate revenue by $1,000–$2,000 every month.
2. Annual Contracts Without Normalization
If a customer pays $1,200 upfront for an annual plan, Stripe records a single charge of $1,200. Depending on how the subscription is structured, this may appear as $1,200 in one month or be normalized to $100 per month — inconsistently.
The correct rule: every annual contract should be divided by twelve regardless of when the cash was collected.
Annual contract MRR = total contract value ÷ 12
A $2,400 annual contract is $200 MRR. Not $2,400. Not $0 in months two through twelve.
3. The Grace Period Problem: Cancelled But Still Counted
When a customer cancels, most SaaS products give them access until the end of the current billing period. But in many Stripe configurations, the subscription stays in active status until the billing period ends — so a customer who cancelled on the 3rd is still included in your MRR on the 20th.
A cancellation event should reduce MRR on the date of cancellation, not on the date the billing period expires.
Churned MRR = full MRR of all customers who cancelled, booked on cancellation date
4. Refunds That Don't Reduce MRR
When you issue a refund in Stripe, the cash leaves your account. But refunds do not automatically reduce your MRR figure. Stripe's MRR calculation is based on subscription status, not on cash flow.
If you issue refunds regularly — for billing errors, customer goodwill gestures, or dispute resolutions — the gap between your Stripe MRR and your actual net revenue grows month by month.
5. Timezone Errors on Month Boundaries
Stripe stores all timestamps in UTC. If a subscription renews at 23:00 UTC on March 31st, Stripe calls it March. In your local timezone it might be April 1st at 01:00.
A business processing 500 renewals per day has roughly 16 per hour. Timezone misalignment of two hours means ~30 transactions per month are attributed to the wrong period — a permanent MRR variance that has nothing to do with actual business performance.
A Worked Example: Before and After
Stripe shows: $33,400 MRR
| Distortion | Amount |
|---|---|
| Failed payments in dunning (7.2%) | −$2,405 |
| 2 annual contracts not normalized | −$1,800 |
| 11 cancelled subscribers still active | −$980 |
| Refunds not reflected in MRR | −$320 |
| Timezone boundary corrections | −$115 |
| Total corrections | −$5,620 |
Real MRR: $27,780 — nearly 17% less than Stripe reports. For a business at this size with normal payment failure rates and a mix of monthly and annual contracts, this range of distortion is typical.
How to Calculate Clean MRR from Stripe Data
Step 1: Pull all active subscriptions. Export every subscription with status active or trialing. Do not include past_due or unpaid in your base MRR — these belong in your at-risk bucket.
Step 2: Normalize all amounts to monthly.
Monthly plan $99 → MRR = $99Annual plan $999 → MRR = $999 ÷ 12 = $83.25Quarterly plan $270 → MRR = $270 ÷ 3 = $90
Step 3: Apply cancellation date logic. For every subscription with a cancel_at or canceled_at timestamp within the current month, remove it from MRR regardless of when the billing period ends.
Step 4: Subtract refunds. Pull all refunds issued in the current period and subtract from gross MRR to get net MRR.
Step 5: Standardize all timestamps to UTC. Ensure every event is evaluated against UTC month boundaries.
Step 6: Reconcile.
MRR(end) = MRR(start) + New MRR + Expansion MRR − Contraction MRR − Churned MRR + Reactivation MRR
If this does not reconcile to the cent, you have a double-count, a missed event, or a timezone error somewhere.
Why This Matters More Than You Think
There is a difference between a vanity number and an operating number. Stripe's MRR is a vanity number. You cannot use it to answer the questions that actually matter:
- Why did revenue drop $350 last Tuesday?
- Which customers are most likely to churn next month?
- How much of my MRR is genuinely at risk right now?
- What is my real net revenue retention after refunds and failed payments?
To answer those questions you need a number you can trace — every dollar back to a specific Stripe event, every change back to a specific date and cause.
What Dnoise Does Differently
Dnoise connects to your Stripe account with a read-only restricted API key. It reads your full billing history — not just the current state of your subscriptions — and recalculates MRR from source events.
Every number is traceable. If your MRR drops $350 on a Tuesday, Dnoise shows you the three subscription events that caused it, the exact timestamps, and the event IDs you can verify directly in Stripe.
Failed payments are separated from clean revenue automatically. Annual contracts are normalized. Cancellations are booked on the cancellation date. Refunds are tracked and subtracted. All calculations run on UTC.
The result is an MRR number you can take to a board meeting, put in an investor report, or hand to your accountant — with a full audit trail attached.
See your real MRR in minutes.
Connect Stripe and Dnoise shows your failed payment rate, revenue at risk, and anything recoverable — with every number traced back to source events.
See live demo Connect Stripe — freeSummary
Stripe is not lying to you. It is showing you exactly what it was built to show: the current state of your subscription objects. The problem is that this is not the same as your actual recurring revenue.
The five distortions — failed payments in dunning, unnormalized annual contracts, grace-period cancellations, untracked refunds, and timezone boundary errors — are all structural. They affect every Stripe account.
For most SaaS businesses at $10k–$100k MRR, the gap is 10–20%. That is not a rounding error. That is a business decision made on incorrect data.