It’s Not as Simple as You May Think
Hello, Natalie here to talk with you a bit about “ARR”. I recently read an article by Nick Franklin, CEO at ChartMogul, titled “What is ARR? It’s not as simple as you may think.”
The core SaaS metric/acronym of ARR has become quite confusing over the past couple of years. It’s a battle for the ages between the SaaS old-guard purists and the new breed of software companies who generate their revenue and take payment in a different format.
Everyone wants to report ARR even if they don’t really have it. So, what is it exactly?
In his article, Nick takes the position that the traditional definition for ARR is out of date and the most popular and broadly useful one today is Annualized Run Rate, calculated as MRR x 12.
We define ARR differently at Bigfoot, taking the more traditional view that ARR is (wait for it…)
Annual Recurring Revenue!
ARR is the most applicable revenue scale metric to apply to companies selling annual or multi-year software subscriptions/licenses primarily to mid-market/enterprise customers. It should be scoped to the recurring revenue components of the products/services a company delivers, removing one-time revenue capture associated with those products/services. ARR is a time-based revenue metric.
For us, Run Rate is a different metric, one worth conveying, but not one to call ARR.
Run rate is a simple revenue forecasting method that takes recent results and multiplies them to annualize this recent performance for forecasting purposes. DO NOT apply a run rate to revenue streams that are not recurring (and thus not all that forecastable) in nature. That’s just misuse and untrustworthy.
Annual Run Rate = Last month’s recurring revenue (“MRR”)* 12 or last quarter’s recurring revenue * 4
The Run Rate metric has been around for a long-time across industries. It seems that it has only recently made its way into SaaS. It’s possible that a lack of broader financial sophistication paired with a desire to re-engineer metrics to provide maximum benefit to a company (and its investors) is what’s causing today’s confusion (and obsession) with run rate in SaaS.
See, run Rate is a bit of a momentum metric. Of course every company, if they’re growing with some consistency, wants to use their most recent results to convey their revenue and growth. This is especially true in SaaS where growth is the golden goose and earnings and EBITDA just don’t carry much weight when it comes to driving valuations.
Calculating your nnual Run Rate revenue and calling it your “ARR” can cause some problems.
Here’s an example calculation of “ARR” as a revenue run rate:
MRR in September: $20,000
“ARR”: $20,000 * 12 months = $240,000
MRR in Q3: $75,000
“ARR”: $75,000 * 4 quarters = $300,000
There’s a $60k delta right there. That’s like 25% of revenue, so I’d call that material!
It’s evident MRR dropped later in Q3 to bring down the run rate from where it was earlier in the quarter. Calculating run rate made that easy to surface, which is great, but which run rate # will the company put forth and stand behind?
There are many problems with the reliability of this metric that may produce an inaccurate picture of revenue and dilute your true quality of revenue.
Here are a few:
- Annual Run Rate doesn’t account for future churn as it assumes that monthly contracts will last a full year but in reality customers might cancel their subscription before ARR materializes
- Similar to churn, Annual Run Rate doesn’t account for future expansion revenue. If existing customers deliver additional revenue, Annual Run Rate might be understated and wrongly capture lower estimates
- Outlier months due to seasonality or one-time sales from promotions the company cannot sustain might positively impact Annual Run Rate and throw off monthly estimates
My main point being that there are just too many factors in play that can compromise the quality of Run Rate. I’m not saying that traditional ARR cannot be gamed (it can), so do your homework there too 🙂
At the end of the day, we should all want calculations and underlying numbers that give us results we can trust and use to make decisions. Just because we can cherry pick and manipulate what we include in the calculation, doesn’t mean it’s good or acceptable practice.
We’re not anti run rate at Bigfoot. It has valuable uses and provides indicators. If you don’t have a lot of historical data, fine use a run rate to communicate your revenue. If you’re growing extremely fast (with strong retention), go ahead and run rate that revenue.
At the end of the day, it comes down to using a chosen metric to convey the clearest picture of performance reality and clearly communicate what it is you’re measuring and putting forth for others to consume. It’s not about gaming the metrics to gain an advantage.
Here’s some additional reading making the case for broadening the scope of ARR to include recurring(esqe) revenue streams that are increasingly taking hold across B2B software.
https://www.saastr.com/is-it-really-arr-in-2021-yes-as-long-as-nrr-is-100/
https://www.linkedin.com/posts/kyle-poyar_saas-finance-activity-6798957269112377344-QloO/
I tend to agree with the concepts here given the evolution of how software companies are monetizing beyond (or instead of) subscriptions. If a revenue stream is recurring, I’m fine to consider it in ARR.
But, I’m still not in the camp of ARR being a run-rate metric for the vast majority of software companies. If you’re growing at 100% with NRR of 100%+, I can live with it. If you aren’t, stick with reporting traditional ‘ol ARR (Annual Recurring Revenue).
Have more questions about ARR? Let’s chat: grab some time
For More Content: subscribe to our monthly newsletter (no fluff!)
