The MRR Source of Truth: Standardizing Revenue Data from Your Billing System
Are you sure you’re reporting your MRR correctly? If your billing system is the revenue source of truth, you may have some hidden reporting issues hurting your financial reports and analyses. But there’s a way to fix it. Here’s everything you need to know about cleaning up billing data to be an MRR source of truth.
While there are plenty of advantages to a product-led growth model in SaaS, there’s one glaring back-office challenge you always have to contend with — determining your true monthly recurring revenue (MRR).
The dashboards in Stripe or Chargebee will spit out an MRR number for you. But how much do you really trust it?
Billing system architecture is so complex and such a black box that it’s almost impossible to know how those platforms arrive at your MRR.
Your next step to make sense of SaaS billing data may be to invest in a third-party subscription management system that promises deeper insight into your metrics. But even those won’t go far enough to give you true visibility into your revenue data.
To build an MRR source of truth from billing system data, you need to get to the most atomic level of visibility — and a platform that can standardize the process for you.
Table of Contents
The Data Granularity Problem with SaaS Billing Systems
Data granularity is the key component for building an MRR source of truth from your billing system. But getting to the most granular level of insight into your billing data gets increasingly difficult as your business matures.
We see companies experience the data granularity problem with MRR reporting in three phases.
Phase 1: Stripe as MRR Source of Truth
Founders at pre-seed or early seed stages can likely get by with the directional insight of basic MRR dashboards native in a platform like Stripe. You can’t fully customize what’s included or not included in the calculation, but you can rely on the basic tracking of what you’re billing customers and what you’re collecting against that.
Phase 2: Subscription Management Tool as MRR Source of Truth
Companies graduate from basic Stripe dashboards when they reach a significant amount of revenue and want a tool more suited for tracking MRR. They invest in a subscription management tool like ChartMogul, Profitwell, or Baremetrics. Those tools apply a one-size-fits-all approach to ingesting billing data and give you a couple of toggles for MRR (e.g. whether or not you want to include cancelations or discounts in the calculation). But the calculation is still a black box and not flexible.
Custom Build as MRR Source of Truth
You outgrow subscription management tools when your business model starts to have nuances that don’t fit their one-size-fits-all calculations. Maybe you have added complexity from a referral program. Or you might have high volumes of discounts or credits that don’t fit an out-of-the-box formula.
At this stage, you want to get to the most granular view of a customer to understand the individual specifics of invoices, subscriptions, credit memos, discounts, and refunds. For finance teams, this level of granularity is the only way to trust MRR calculations.
Traditionally, finance teams have had to build a custom MRR source of truth in that third stage of maturity to get the right level of granular visibility. That would mean pulling all of the data out of the billing system through APIs, dumping it into a data warehouse like Snowflake, and mapping the customer-level subscription data manually.
But you shouldn’t have to do all that heavy lifting just to understand your MRR.
That’s why we’ve built the most nuanced and flexible billing system integrations — to automate as much of the grunt work as possible while giving you control over the nuances of your MRR calculations.
5 Steps to Creating Your MRR Source of Truth
Creating a true MRR source of truth for financial analysis and forecasting means transforming and translating the chaos of SaaS billing data into subscription details at the customer level.
To help companies do that, our standardized approach dives down to subscription item level in billing system data. We pull the amount associated with the given period you’re charging, what you’re invoicing them for, and the exact second associated with the charge.
With all of that data on hand, we start to go through the process of defining MRR with your inputs. Here’s how it works.
1. Differentiate Between Historical and Current/Future Revenue
The first step to creating an MRR source of truth is defining what you’re trying to calculate. When you’re starting with a data dump of subscription item details, you need to separate your historicals from your current/future months.
For historicals, you’ll define revenue — both recurring and non-recurring — with past invoices. This is the typical approach because your invoices will capture the ebbs and flows of revenue.
Moving forward, you want to reflect what you believe you’ll invoice and collect against. The source should be subscriptions, or the previously paid invoices for future months like an annual invoice paid at once, because that’s what gives you an end date one, six, twelve, months out (depending on your pricing model).
Once you understand the source for each side of the revenue equation, you can dig deeper into the details of each.
2. Translate Historical Invoices into MRR and Non-Recurring Revenue
The next step of creating your MRR source of truth is defining which historical invoice details should be included as recurring revenue and which are only scheduled revenue.
There are four primary categories to decide whether or not to include in MRR:
- Paid invoices. It is generally accepted to include paid invoices in your MRR calculation.
- Refunded invoices. Some may say to always include refunds as revenue and leave the reporting details to the collections side of things. Others will say revenue should drop because you refunded the revenue. We typically recommend not including refunds in MRR, but it depends on your business.
- Credited invoices. Credits typically follow the same logic as refunds. If you don’t include refunds in MRR, you likely shouldn’t include credits.
- Open payments. You should include open payments in MRR on two conditions. First, the payment status should not be “failed.” And second, the subscription should still be active. If payments fail or subscriptions are canceled, don’t include in MRR.
These toggles are where you start to see differences in reporting between Stripe itself, a tool like ChartMogul or Profitwell, and Mosaic.
You’ll find that Stripe often overstates MRR because their calculations include refunded invoices. And we’ve found that ChartMogul calculations are often on the conservative side as they under-report certain line items.
The data from a tool like ChartMogul will be directionally correct. But if you aren’t comfortable with the uncertainty in the numbers, you need an approach like Mosaic’s to better control what’s included and excluded from MRR.
We’ve found cases where companies were misreporting MRR by 10%, 20%, and even 30+% to the board because of issues in how their subscription management tools were calculating revenue. That’s the kind of miscalculation that will hurt your credibility in the eyes of stakeholders.
3. Project MRR Forward Based on Subscription Status
Generally speaking, if a subscription is active, you project MRR forward by taking the amount you’re anticipating to collect until whatever the subscription end date is. But there can be a lot of nuance to how this plays out depending on your business model.
If you’re a month-to-month business, technically you don’t have any subscriptions that would create recurring revenue. Instead, it looks like every customer churns at the end of the month and starts over again. But you wouldn’t want to forecast it this way.
Some customers will create an assumption that, for example, a customer will stay on for 12 months. So, to calculate MRR, they project every customer out 12 months. But mixing synthetic and actual data like that can lead to reporting issues down the line.
We recommend focusing on actuals for reporting. Your reports will show each customer churn monthly. But on the planning and forecasting side, you can use a three-month average customer lifetime to better project MRR forward. Additionally, using Mosaic’s Planning features enable you to decide which forecasting method makes the most sense versus relying on a hard-coded approach in your actuals.
Payment terms are another complicating factor in projecting MRR forward. If you have net-30 payment terms, do you want customers who haven’t paid yet to show up as churn? Or do you want to give them a 30-day grace period to smooth out reporting? There’s technically no right or wrong answer, but consistency is key.
4. Decide How You’ll Treat Discounts in MRR
Discounts are one factor that can significantly change MRR numbers between native billing system dashboards, subscription management tools, and a platform like Mosaic.
In our approach, you’ll need to decide whether or not each of the following will reduce MRR:
- Forever discounts. We believe these types of discounts should reduce MRR because you’ll never recognize the discounted recurring revenue.
- Repeating discounts. We don’t include repeating discounts in MRR because the subscription amount will stay static for the life of the discount.
- One-time discounts. These should not impact your MRR amount. For example, if you have a six-month contract and just one month is discounted, the actual recurring amount is the same throughout the life of the deal.
Platforms like ChartMogul and Profitwell have toggles to let you control whether or not discounts roll into MRR. However, the MRR reporting doesn’t show you how much is discounted versus what’s not — you just get one number.
Mosaic can calculate both net MRR and gross MRR metrics, enabling you to build metrics in the Metric Builder feature to fully calculate your discounts.
5. Define the Relationship Between Cancelations and MRR
The other major factor that can drastically change MRR calculations is how you treat cancelations.
We generally recommend customers align cancelations with their actuals rather than presuming renewals in their metrics. This means canceling MRR as of the cancel date as opposed to when the active service actually flips to canceled.
The caveat here is that you should treat cancelations according to what makes sense for your business model. If you believe presumed renewals make the most sense for your business, that won’t hurt your MRR reporting — you should just make sure you have documentation that helps tell the story around the numbers because if a presumed renewal cancels, you’ll see a big dropoff in MRR.
Again, this goes back to being consistent in how you report to reduce the confusion when reporting to your key stakeholders.
Spend More Time Analyzing and Less Time Manipulating Billing Data
The complexity of data architectures in billing systems like Stripe and Chargebee can’t be understated. If you try to dig down to the level of granularity described above manually, you’re bound to sink so much time into aggregating and making sense of data that you won’t actually have time to add strategic value to the business.
Mosaic’s standardized approach to integrations with Stripe, Chargebee, SaaSOptics/Maxio, and Ordway allows you to spend more time analyzing data and collaborating with business partners rather than getting stuck deep in the weeds of billing system data.
Our granular level of insight into billing data will help you understand deep strategic topics like:
- The MRR differences between customer cohorts
- How specific product initiatives are translating to revenue
- Whether or not customers are gaming your pricing system
- The impact of your referral program on recurring and non-recurring revenue
Coming to conversations with your business partners with deep insight into topics like these will help you build trust across the business. When partners have questions about MRR data, they’ll feel confident that you can answer even the most complicated ad hoc questions.
How sure are you that your MRR numbers are right? Reach out for a demo of Mosaic and we’ll help you verify your data at the most granular level possible.