MRR is an acronym for Monthly Recurring Revenue, or very simply a measure of your predictable revenue stream. A primary purpose of MRR is to permit performance reporting across dissimilar subscriptions terms.
The MRR reporting challenge is quickly illuminated in the following scenarios:
Using the traditional method of bookings, it is difficult to get a clear sense of performance. Real growth rates and real churn rates are difficult to measure without some form of contract revenue normalization. MRR provides such normalization.
MRR is frequently used in a number of critical subscription performance reports: Momentum, Customer Lifetime Value (uses MRR in the CLV computations) and MRR Cohort.
There are no set rules for the calculation of MRR, but under almost every scenario, MRR is NOT reportable GAAP Revenue.
MRR is a normalized measurement of recurring revenue, most frequently measured with a constant value in each month of the subscription period. GAAP revenue is best computed using a daily recognition model, which is to say the revenue is recognized pro rata each day between the start and end date of the subscription.
The distinction between MRR and GAAP revenue is best understood when viewing the value of the subscription's MRR and GAAP revenues per month side-by-side, shown right.
This image shows the both the MRR and GAAP reportable revenue for a $1200 annual subscription that begins on Feb 13, 2015, and ends on Feb 12, 2016.
The GAAP revenue recognition is computed using a daily computation, the universally preferred (and least error-prone) method for recognizing revenue.
As a normalized measurement, one primary purpose of MRR is to remove the noise or jitter associated with real GAAP revenue when reporting on subscription growth and business momentum. If you were to use the GAAP revenue number, your momentum reporting would show significant fluctuations month-to-month. The change from February to March would indicate growth of 10%, and March to April would indicate roughly a 3% contraction, when in fact this customer represents no subscription change at all - neither incremental growth nor incremental contraction.
While MRR is an approximation of reportable revenue, the real difference is most easily highlighted with simple math. An annual subscription that starts on any day other than the first of the month will span 13 months, meaning the number of months inclusive from start to end is 12 + 1, whereas the annual subscription itself is actually only 12 months in duration.
As is the common practice, the MRR is included in each month in which the term exists, or “spans.” The aggregate of MRR over the term is roughly 8% more than the GAAP revenue in this scenario - $1,300 vs. $1,200. Is that a fair analysis? What if the customer renews? After two terms, the number of reportable MRR months is 25, and the percentage difference drops with each subsequent term and at an infinity number of renewals the numbers are mathematically the same. Before infinity is reality, and 8% or 4% is a material difference.
The difference between GAAP revenue and MRR also exists for a monthly subscription business, that is, a subscription with a one-month term (monthly service paid in advance). While common practice is to recognize revenues for monthly subscriptions on the date of invoicing or billing, proper GAAP accounting would still result in recognition of the revenue over the subscription period, in this case a month. A $100 one-month subscription that starts on Feb 13, 2014 and ends on March 12, 2014 would still have prorated GAAP revenue of $57.14 in February and $42.86 in March.
This is the scenario most likely to lead to communication confusion. When revenue is maintained in a spreadsheet, in almost all cases the revenue recording method is one form of “evenly,” which is typically one of the following:
In the record to the right, we have used a revenue recognition method of evenly over the months starting in the first month. In this case, during the first 12 months the reportable revenue is equal to the MRR.
When recording revenue in a spreadsheet, one of these evenly methods is really all that is reasonable. A daily computation in XLS is an extremely resource intensive computation that relies on advanced formulas. Therefore, no one does it (to be fair, we have seen one daily computation spreadsheet in 6 years).
In the early stages of development of your business culture and nomenclature, it is a natural by-product of this apparent convergence of MRR and revenue to develop a culture where they are discussed and managed the same way, as they appear to be the same.
The reality is that they simply are not the same thing, and over time you will eventually find that while there are rules about how revenue is to be recognized, experts, and arbiters to assist with revenue recognition, little of that exists for MRR. You are largely on your own, and your MRR reporting rules most certainly will diverge over time relative to your revenue reporting.
With convergence, finance people attempt to treat MRR and revenue the same way, which is to say they apply an accounting T philosophy to the “tie-up” in reporting of MRR. The math above shows that is difficult to do, and in practice the rules and exceptions for what is included in MRR (and when it is included) make it nearly impossible.
Further, as a company grows, it will move off a revenue recognition spreadsheet and into and application, and when you move to an application, you almost always transition to the proper GAAP revenue recognition method, which is a daily computation and not an evenly method.
MRR, while representative of revenue, is an imprecise financial expression and should not be confused with “revenue.”
In the real world, MRR is an imprecise measurement and enormous time and money can be wasted trying to ensure that MRR numbers “tie up” and meet the same standards required for GAAP revenue reporting. Our advice? Remember treat subscription analytics more like you do horseshoes - close is close enough.
Obviously you need integrity in your numbers and we aren’t suggesting you “pass” on the significant effort required to develop and maintain good MRR reporting. We hare simply saying that the standard for data integrity is different from that used to report revenues on an income statement.
The examples above clearly demonstrate that MRR is not GAAP revenue, and indirectly highlight a subtlety that frequently causes significant confusion for many organizations and finance professionals.
In the subscription world, the word "revenue" is an imprecise term subject to interpretation.
For most efficient business discussions, consider adopting the term "GAAP Revenue" for discussions relating to accounting and income statement/P&L performance, and "MRR" for subscription metrics and analytics. For maximum communication efficiency, ensure each party who consumes the numbers has a clear understanding of the terminology, as well as the rules for the generation of the underlying numbers.
Finance professionals, specifically CPAs, rarely need education on GAAP Revenue, but many times are new to the subscription model and do need to understand how MRR is different from GAAP revenue. If your business is early stage and your finance person is a bookkeeper, he or she will likely need education on both topics, as will managers in sales, marketing and product functions.
In the finance function, MRR is used in or to:
CMRR is an acronym for contracted MRR or committed MRR.
For term-based subscription businesses with on-boarding processes or delays from booking date to subscription start date, Committed Monthly Recurring Revenue is the value of the Contracted MRR from the booking date through the subscription end date. Like its cousin MRR, CMRR typically excludes revenues that are not recurring. Variable fees are not typically included.
Working with the same 1200 annual subscription with a start date of Feb 13, 2015 and ending Feb 12, 2016, let’s add in an order date of Jan 15 2015. As shown below, MRR is 0 in Jan 2015 and CMRR is $100. When the subscription goes live in Feb 2015, MRR goes to 100 and CMRR stays at 100.
Given the importance of MRR growth in the subscription business model, MRR is more and more a consideration in sales compensation plans. However, measurement of MRR for sales compensation often requires a set of "exception" rules that are more complicated than those for a MRR measurement performed for the purpose of assessing strategic business performance.
The primary issues typically involve the inclusion or exclusion of subscription records, the value of MRR, and the timing of transactions.
Bad AR, write-offs, refunds, and credits are always accounted for in revenue reporting and balance sheets, as they should be in some way in board-level MRR reporting.
However, the sales team is often not accountable for many post-sale financial or contractual changes, including early cancellations, collection issues, bankruptcies, concessions, and settlements. Therefore, changes in MRR performance due to issues such as these are often excepted out of the MRR performance reporting for the sales team.
In addition to complicated "sales exception rules" that factor in or out certain transactions, significant complication can also be introduced based on significant differences in the interpretation of timing of transactions. For instance, a gap in a subscription terms (time between the end of one term and the start of another) would be addressed by finance in revenue reporting, but not likely addressed in a reduction of the renewal booking value within the sales function. And such a situation would likely lead to a difference in reporting.
For example, a customer's subscription is expired and the sales team works for over a month to secure the renewal. Eventually, the renewal comes in. The sales concession to the customer is to start the new term as of the date business terms were agreed upon, in the example below March 28, 2013. However, the customer had access to the service during the gap so the finance team adjusts the records accordingly, recording the subscription and GAAP revenue start date as Feb 12, 2013 and the end date as March 27, 2014. MRR is adjusted down as the $1200 is actually over a term of 13 months (and a few days).
The view of the information from the sale and finance perspectives are thus very different, leading to significant potential complications in measurement and tracking of MRR performance.
Start Date: Feb 12, 2012
End Date: Feb 11, 2013
Start Date: March 28, 2013
End Date: March 27, 2014
Net MRR Change = $0
Start Date: Feb 12, 2012
End Date: Feb 11, 2013
Start Date: Feb 12, 2013
End Date: March 27, 2014
Net MRR Change = $-1.04
Noting again that there are no objective rules regarding the computation of MRR, you are left to decide if it is appropriate to include or not include adjustments in your MRR calculations. Given the complexity of many financial adjustment transactions, it is often the practice that they are simply not included. On the other hand, inaccurate or incomplete bookkeeping practices frequently make it very difficult if not impossible to include adjusting transactions in MRR computations if desired.
At SaaSOptics, we work with many early stage and emerging businesses and we see very common patterns. In the early days of the business where the focus is on cash flow and simple viability, bookkeeping practices are erratic, inconsistent, and often inaccurate. An invoice might be associated with one income account and a credit memo for the invoice associated with a completely different income account (typically based on the use of different sales items in the invoice and credit memo). Broad stroke journal adjustments and use of a generalized non-product specific "credit" sales item are also common.
Recording of financial records in this manner makes it difficult to even have the option to include such transactions in MRR calculations.
Variable, usage, or consumption fees are sometimes included, but only when you can make a strong contractual argument or statistical argument that the revenue stream is predictable or consistent. This is most often the case with "capacity" based subscription pricing models common in telecom and telecom-like subscriptions, where the subscription includes X units/instances/actions per month, term or billing period.
You will be hard pressed to find a MRR data field or function in any GL or finance system. Certain billing platform providers do include MRR tracking, but not for all transaction types (e.g. usage fees do not include MRR). And, unless your finance system has a rev rec module, it will not have a Contract Object, and therefore will not likely track subscription start and end dates, which means "cancellation" actions and churn are not easily reportable.
With the absence of MRR numbers and cancellation data, the common approach has been to turn to a spreadsheet to track and measure MRR and MRR Churn. In fact, SaaSOptics is an application that evolved (conceptually not technically) from such a MRR spreadsheet. While SaaSOptics now has significantly evolved methods for calculating and reporting on MRR, we understand the xls concepts and organizational maturation process well.
To perform core MRR calculations of MRR Churn and total MRR, it is easiest to start with a simple "status" or state spreadsheet. Your xls will include basic information needed to report on the present state of each contract or subscription. This approach works well for a few dozen customers, but its value quickly evaporates as a company grows. Ultimately, this approach does not provide information to report on changes, and what is fundamentally interesting about a subscription company is the change or rate of change.
In short order, most organizations move to a transaction or subscription ledger approach, one that mimics a simple database that captures each subscription action (new booking, upgrade, renewal) as a record in the spreadsheet. To calculate MRR Churn, you need to report on cancellations. A cancellation is the equivalent of the absence of a Renewal. However, measuring a cancellation using an "absence of data" is extremely difficult, especially in a spreadsheet. In other words, you need some form of a cancellation data element that you can clearly record and measure. Therefore, you either tag transactions to indicate the transaction did not renew, or you add a Cancellation transaction with a value (for bookings loss) and a MRR value.
The best-practice approach to creating cancellation records is to record the cancellation in the same period as you would record it if it were a renewal. Doing so enables you to consistently measure renewals and churn, a mathematical must since churn is simply 1 minus Renewal Rate.
By way of illustration, a subscription ends on July 31. If it renews, the start date of the new term is August 1, and therefore the renewal date for MRR calculations is August 1. If it doesn't renew, i.e. it cancels, there is a tendency to report the Cancellation (especially within the Sales function) as of the end date. However, in doing so, you are reporting the cancellation in a different period. The Cancellation should be recorded on Aug 1, which is the same date and therefore in the same period as the renewal had it renewed.
The typical MRR report performance report includes MRR totals broken out by the following classes: New, Renewal, Expansion/Upgrade, Contraction/Downgrade, and Lost as shown in this SaaSOptics MRR Momentum Report.
While the data management and xls formulas become increasingly complicated as your business and reporting needs grow, calculation of New and Lost are typically the easiest and can usually be calculated using a data field or flag to indicate the class of a record. In early stage subscription businesses, you can also use data fields/flags to indicate the class of a transaction. However, as the volume of data grows and the complexity of transactions increases, this becomes increasingly complicated. Mid-term subscription changes for quantity, products, value, and term end dates all create immediate havoc with the formulas used to calculate Expansion, Contraction and Renewals.
|CMRR||How to Calculate MRR||Committed MRR|
|MRR Cohort||Bessemer MRR Growth||Contracted MRR|
For SaaS businesses, audit preparation can be stressful. Here's how to make it easier