A deep dive into the messy reality of recurring revenue in Stripe and how to calculate it in a way that helps you run your business accurately.
If you’re evaluating MRR analytics tools for your SaaS business, you’ve probably noticed something: everyone claims to calculate MRR accurately, but dig deeper and you’ll find wildly different approaches. Some tools show MRR changes instantly when a customer applies a coupon, others wait until the next billing cycle. Some include prorations, others don’t.
After building ClearSync and calculating MRR for hundreds of SaaS businesses, we’ve learned that there’s no “correct” way to calculate MRR, only opinionated ones.
This article explains our approach, the edge cases we handle for you, and why these decisions matter for understanding your MRR.
ClearSync’s Core Philosophy: Use The Right Data Source For The Job
A lot of tools that calculate MRR from Stripe pick one path, subscriptions or invoices, and force every calculation through it. We take a different approach.
ClearSync uses a hybrid model:
Invoices for historical accuracy (as Stripe only shares 30 days of Subscription data)
Subscriptions for real-time precision
Invoices tell you what customers actually paid, including discounts, prorations, and taxes.
Subscriptions tell you what’s happening right now: current prices, quantities, and discounts as soon as they change.
ClearSync imports your historical invoices to give you a picture of how your subscriptions changed over time and reconstructs MRR history from the invoice data. Going forward, we look at your subscription AND invoice data to give you an up-to-date and accurate view of your subscription and MRR changes.
By looking at invoices and subscription changes, we get the best of both worlds:
Accurate subscription and MRR change history constructed from invoice data
Instant updates from webhooks for real-time visibility that can be used in real-time campaigns (Think: downgrade save campaigns or CSMs being in the loop the second their customer adds on a new product)
Consistent logic applied every time
This hybrid foundation lets us calculate MRR with both speed and fidelity and it’s what makes our approach to applying MRR to edge cases so reliable.
Now, let’s get into how ClearSync handles MRR calculations that aren’t so straightforward.
The Mechanics: How ClearSync Calculates MRR
Once you understand the philosophy, the rest comes down to how we calculate MRR and where we draw the boundaries. Let’s get into the nuances of each decision we made as we decide how to calculate MRR from your Stripe data.
1. Prorations
Prorations in Stripe can be complicated. We built ClearSync to automatically interpret Stripe proration configuration scenarios to derive accurate effective dates and MRR amounts.
Stripe’s choices: Prorate Immediately vs Prorate at Period End
When a customer upgrades from a $50 plan to a $100 plan in the middle of a billing cycle, Stripe gives them two options:
Option 1: "Prorate Immediately"
Stripe generates a new invoice right away
The invoice includes prorated credits and charges for the partial period
The customer is billed the difference immediately
While effective immediately, the invoice might be paid later
Option 2: "Change at Period End"
Stripe schedules the change for the next billing cycle
No new invoice is generated yet
The customer continues on the old plan until their renewal date
No immediate billing, instead it's a planned upgrade at next renewal
How ClearSync Handles Each Scenario
ClearSync processes the change when billing starts, which isn't always when a button is clicked. So, if your company chooses to prorate immediately, we will show that adjustment and upgrade/downgrade MRR immediately. If you choose to prorate at the period end, we will show that MRR adjustment at the next invoice. We take the stance that:
The credits and charges when prorating immediately are accounting adjustments, not recurring revenue.
The $100/mo ongoing plan is what actually recurs, so that’s what counts as MRR.
This approach respects your company’s timing choice but keeps your data consistent by normalizing recurring MRR only and eliminating mid-cycle noise.
Stripe Proration Option | Stripe Behavior | What ClearSync Does | When MRR Updates |
---|---|---|---|
1. Prorate Immediately | Generates a new invoice with credits/charges for unused period. | Detects new invoice → separates prorated vs non-prorated lines → counts only recurring line(s) as MRR. | Immediately |
2. Change at Period End | Defers changes until next billing cycle | No invoice yet → waits for renewal → applies MRR change then | Next billing cycle |
2. One-Time Charges
This might seem obvious, but it's worth stating explicitly: one-time charges are not MRR. Stripe allows one-time charges to be attached to a subscription, which can cause confusion.
Setup fees, consulting hours, hardware, or penalties often appear on subscription invoices. We do not count these one-time line items as MRR because they are not recurring revenue.
Why this matters: If you have a $1,000 setup fee on a $100/month subscription, including that setup fee would show $1,100 MRR for that customer. But next month, they're only paying $100. Your MRR calculations would be completely wrong. The following month, it would look like your customer had a downgrade when in fact they’re healthily renewing at the same price.
If a customer has a $500 setup fee and then cancels after one month, we don’t want it to look like you gained $600 MRR ($100 subscription + $500 fee) then churned $600 MRR, making it look like you lost a much bigger customer than you actually did. This customer simply has an MRR of $100/month.
3. Billing Intervals
Different businesses bill on different cycles: monthly, quarterly, annually, weekly, and custom cycles. To compare subscriptions fairly, we normalize every interval to a monthly rate to calculate monthly recurring revenue and compare it equally against any subscription, no matter its billing interval.
The following table shows how we calculate MRR for weekly, quarterly, annual, and custom billing cycles. For example, a weekly billing cycle gets multiplied by 4.33 (the average number of weeks in a month) to calculate MRR. Quarterly prices get divided by 3 since there are 3 months per quarter. This gives you an accurate apples-to-apples comparison of MRR per customer, no matter their billing interval.
Billing Interval | Example Subscription | Conversion | Monthly Recurring Revenue |
---|---|---|---|
Weekly | $100/week | 52 ÷ 12 = 4.33 | ($100 * 4.33) = $433 |
Quarterly | $300/quarter | ÷3 | ($300/3) = $100 |
Annual | $1,200/year | ÷12 | ($1,200/12) = $100 |
Custom | e.g. every 6 weeks | Interval ÷ count | Calculated dynamically |
4. Discounts
Stripe's discount system allows you to apply coupons at multiple levels:
Invoice-level discounts: Apply to the entire invoice amount (e.g., "20% off everything")
Line-item discounts: Apply to specific products (e.g., "50% off the monthly add-on")
Subscription-level discounts: Inherited by all invoices for that subscription
If you don’t handle them carefully, you’ll double-count or miss them.
Consider this invoice:
Base plan: $100/month
Monthly add-on: $50/month
Line-item discount on add-on: -$25 (50% off the add-on specifically)
Invoice-level discount: 20% off the total
Customer pays: $100 (Base: $100, Add-on: $25 after 50% off, then 20% off the $125 total = -$25, final = $100)
If you simply apply the invoice discount to the total of all line items, you might get:
Line items: $100 + $50 = $150
Apply 50% to add-on: $100 + $25 = $125
Apply 20% to total: -$25
Total: $100 ✓ Correct
But if you mistakenly apply the invoice-level discount to items individually before combining them, or if you double-apply the invoice discount, you can end up with the wrong number.
Our approach:
First, identify which discounts are invoice-level vs line-level
Apply line-level discounts to their specific items
Sum all line items after their individual discounts
Then apply invoice-level discounts to the total
Never count the same discount twice
This ensures we never double-count discounts and we don't miss line-item specific discounts that wouldn't be visible at the invoice level.
Percentage vs Fixed Discounts
Discounts can be percentage-based ("20% off") or fixed amount ("$10 off"). For percentage discounts, the math is straightforward regardless of billing interval. But fixed-amount discounts need special handling.
Consider: A customer has a $120/year plan with a "$10 off" coupon. That $10 discount applies to the annual billing period, not per month. So:
Annual bill: $120 - $10 = $110
Monthly MRR: $110 ÷ 12 = $9.17/month
Compare this to a "$10 off per month" coupon structure on the same annual plan:
Annual bill: $120 - ($10 × 12 months) = $0 (customer pays nothing!)
Monthly MRR: $0
The distinction matters because Stripe's fixed-amount coupons specify a fixed amount for the billing period, not per month. You need to normalize this to monthly just like you normalize the subscription price itself.
We convert the discount amount to monthly using the same billing interval conversion, then subtract it from the monthly MRR. This ensures fixed discounts are properly normalized regardless of whether the subscription is weekly, monthly, quarterly, or annual.
And when a discount ends or changes, ClearSync automatically creates a new MRR event, typically an Upgrade, to reflect the increase in recurring revenue once the full price resumes. This ensures your MRR timeline reflects real business changes, not just Stripe coupon mechanics.
5. Tiered Pricing
Some SaaS businesses use Stripe's tiered pricing feature, as shown below for an example customer with 25 users:
Tier | Pricing | Example Subscription |
---|---|---|
1–10 users | $10/user | 10 × $10 = $100 |
11–20 users | $8/user | 10 × $8 = $80 |
21+ users | $6/user | 5 × $6 = $30 |
Total | — | $210/month |
The customer with 25 users doesn't pay 25 × $10 = $250/month. They pay:
10 users × $10 = $100
10 users × $8 = $80
5 users × $6 = $30
Total: ($100+$80+$30) = $210/month MRR
Your MRR math needs to understand the tier structure and calculate the total based on the current quantity. You can't just multiply unit_amount by quantity, that would give you $250 instead of $210.
Additionally, some tier structures have flat fees:
Tier | Pricing | Example |
---|---|---|
1–10 users | $50 base + $5/user | - |
11–20 users | $100 base + $4/user | - |
21+ users | $200 base + $3/user | $200 + (25 x $3) |
Total | — | $275/month |
The customer with 25 users pays: $200 base + (25 × $3) = $275/month in this scenario.
ClearSync takes into account your tiered billing structure and applies the math accordingly. If you have even one customer on tiered pricing and your math doesn't handle it, that customer's MRR will be wrong. If they're a large customer, the error could be in the thousands of dollars per month.
6. Invoice Statuses
Not all invoices are created equal when it comes to MRR. Stripe invoices can have different statuses that tell us whether the bill represents actual recurring revenue or something else entirely.
Here's how we handle each invoice status:
Paid Invoices: These are the gold standard: the customer paid and the money is in your account. We calculate MRR from these invoices.
Open Invoices: These are bills that have been generated but not yet paid. We still calculate MRR from them because they represent the subscription's current recurring value, even if payment is pending. The customer is committed to paying this amount.
Draft Invoices: These are invoices that haven't been finalized yet, they're still being edited or haven't been sent to the customer. We don't calculate MRR from draft invoices because they don't represent a finalized billing commitment.
Voided Invoices: These are invoices that were canceled after being created. They contribute $0 to MRR because they represent billing that was reversed or never finalized. During historical import, we treat voided invoices as definitive churn. If an invoice was voided, that subscription effectively ended for that billing period.
Uncollectible Invoices: These are invoices that Stripe has marked as bad debt: the customer won't pay and Stripe has given up trying to collect. We treat these as churn and set MRR to $0 from that point forward, since the recurring revenue has been lost.
Past Due Invoices: These are invoices where payment failed or is late, but Stripe is still trying to collect. We don't treat these as churn because the customer might still pay. We keep the MRR unchanged and wait for resolution: either the customer pays (invoice becomes paid) or it becomes uncollectible (then we record churn).
This approach ensures your MRR reflects the reality of your recurring revenue, not just the billing mechanics of your payment processor.
7. Trial Periods
Trials can be surprisingly complex:
Free trials: Should show $0 MRR during the trial, then create a "New" subscription transaction when they convert to a paid plan.
Paid trials: A customer pays $1 for a 30-day trial before the regular $100/month kicks in. Is that $1 MRR or a one-time charge?
Our approach: We look at the invoice amount during the trial period and if it’s recurring to determine if it’s MRR or not. If the invoice shows $0 due, it's a free trial with $0 MRR. If it is more than $0, we check if it's a recurring charge at a discounted rate (which counts as MRR) or a one-time trial fee (which doesn't count as MRR).
When a free trial converts to paid:
Previous MRR: $0 (during trial)
Current MRR: $100 (full subscription)
MRR Change: +$100 (categorized as "Upgrade", not "New" because the subscription already existed during the trial, it's an upgrade from free to paid.)
8. Refunds and Credits
Refunds show up as negative line items on invoices. Are they negative MRR?
Our approach: No. Refunds are adjustments to past charges, not necessarily changes to future recurring revenue. We exclude negative line items from MRR calculations entirely by checking if the amount is less than zero and skipping them.
However, if a customer gets a discount that reduces their monthly bill going forward, that does affect MRR as a downgrade. The difference is:
One-time refund: "Sorry about the outage, here's $50 back" → Not an MRR change
Ongoing discount: "We're reducing your monthly price by $50 going forward" → MRR changes, regardless of whether a refund occurred
9. Taxes
This one is straightforward but worth stating explicitly: taxes are not included in MRR calculations.
When a customer pays for a $100/month subscription and sees a $108 charge on their credit card (for 8% sales tax), their MRR is still $100, not $108.
Taxes are pass-through amounts, vary by location, and can change independently of your pricing. Including them would inflate your metrics when the only thing that changed was the government’s rate.
Stripe already separates amount and tax amount, so ClearSync simply uses the pre-tax figures, the same standard investors and accounting teams use for ARR/MRR reporting.
To Summarize: What ClearSync Explicitly Excludes in MRR Calculations (And Why)
To summarize what doesn't count as MRR in ClearSync:
Prorated amounts: We normalize to showing the new MRR when billed, not showing the noisy adjustments in between.
One-time charges: We don’t include one-time charges like setup fees, consulting, hardware, etc.
Draft, Void, and Uncollectible invoices: Draft and canceled billing does not count towards MRR
Trial periods: Free trials show as $0 MRR until paid conversion
Refunds: We don’t count refunds as MRR unless it’s a credit that reduces the bill permanently going forward
Taxes: Taxes vary by location and aren’t core business revenue, so they are not part of your MRR
Why Our MRR Approach Matters For Your Business
Our opinionated approach to MRR means:
Cleaner MRR trends: No spikes from mid-cycle upgrades or proration noise
Apples-to-apples comparison: All billing intervals normalized to monthly
Tiered pricing support: Multi-tier plans calculated correctly
Proper discount handling: Complex coupon structures don't break calculations
Reliable forecasting: Your MRR × 12 actually predicts annual revenue
Accurate historical data: Complete picture from day one of your Stripe account
Fast real-time updates: Subscription changes reflected immediately via Stripe’s webhooks
In the End, MRR is a Business Decision, Not a Technical One
The "right" way to calculate MRR is ultimately up to you. Stripe's out-of-the-box MRR definition and reporting don't think like a SaaS business, which is where ClearSync comes in.
We've designed ClearSync based on three principles:
Use the right data source for the job: Invoices for historical accuracy, subscriptions for real-time data and precision accuracy going forward
Recurring over one-time: Only truly recurring revenue counts as MRR; prorations, one-time charges, taxes, refunds, and certain discounts don't
Predictable over reactive: Changes appear at billing boundaries for clean trends, not mid-cycle for noisy spikes
Whether you use ClearSync or build your own MRR calculation logic, understanding these edge cases and making conscious decisions about how to handle them is what separates accurate analytics from misleading numbers.
MRR is one of your most important business metrics. Make sure you understand not just the number, but how it's being calculated and what assumptions are baked into it.
When you're forecasting next quarter, reporting to investors, or making pricing decisions, you need to trust your MRR. That trust comes from understanding your MRR calculation methodology.
Want to see how ClearSync calculates your MRR? Connect your Stripe account and get instant visibility into your subscription analytics, with the confidence that every edge case is handled correctly.