Clouded Judgement 3.22.24 - ERR vs ARR and the Conundrum of AI Revenue Streams Today
Every week I’ll provide updates on the latest trends in cloud software companies. Follow along to stay up to date!
ARR (Annual Recurring Revenue) vs ERR (Experimental Runrate Revenue)
ARR (Annual Recurring Revenue) is one of the most popular SaaS (Non-GAAP) metrics. However, it’s also one of the most loosely used metrics, and is frequently misused. In it's truest form, ARR is used by pure SaaS business models to describe the aggregate annual value of the entire customer set. Customers sign contracts with annual increments (one, two, three, etc year deals), and the spend is predictable across the course of the contract. At contract expiration these customers either renew (sign another contract with same annual value), expand (sign another contract with higher annual value), contract (sign another contract with lower annual value), or churn (stop being a customer and spend goes to zero).
Many laude the SaaS business model because ARR is inherently predictable - you know what you’re revenue will be over the coming 12 months, and sometimes even further out than that. On top of that, churn and expansion tend to be quite predictable with low volatility. Enterprise software businesses strive for 90-95% gross retention (generally the percent of revenue that sticks with you vs churns altogether), with net expansion in the 120%+ range (the aggregate change in expansion - contraction - churned revenue). For SaaS businesses that target smaller SMB customer segments, gross retention is typically in the mid to low 80’s with net expansion in the ~105% range. With stable gross retention and net expansion figures, it’s actually quite easy to model SaaS businesses. And the predictability into the future gives investors comfort.
Many investors laugh (and some rightly so) at the fact that software companies’ valuations are often described as a multiple of revenue. At the end of the day, shouldn’t profits / cash flow be the true valuation driver? Why do software companies get “credit” simply for revenue? It largely has to do with what I described above. Software SaaS revenue streams are generally highly predictable and long dated (a 90% gross retention implies your customers stick with you for 10 years on average). And once a customer has paid back the initial acquisitions costs to acquire it, all future streams of revenue can loosely be described as a cash flow annuity. This all ultimately means that once software businesses transition from growth mode (ie majority of customers still paying back their CAC) to “maturity mode” (ie most customers have already paid back their CAC and are now spitting off profits) that the overall business will transition from high growth burning money, to lower growth generating profits. That’s at least the promise of SaaS that investors have bought in to when valuing software businesses with revenue multiples… If you were to truly value any business (software included!), you’d build a DCF (discounted cash flow) analysis. This analysis does two things. First, it models out the annual cash flow of a businesses (say 10 years out), and discounts the future value of those cash flows back to present value (this is why software businesses are sensitive to interest rates - as rates go up, so does the discount rate). Second - it will look at the terminal value of the business (say the cash flow in year 10), make an assumption around what top line growth will be and what FCF margins will be at maturity, apply a multiple to it, and discount that back.
What you’ll find for most Software businesses - the majority of the value of a DCF sits in the terminal value (our outer years of FCF). So what are the true assumptions we’re making when valuing software companies with revenue multiples? It’s the assumptions in the terminal value. Namely, retention!!
Ok - so this was a long winded intro all to say one of the biggest assumptions software investors make when valuing software companies is that RETENTION will be stable and revenue is RECURRING. And a big assumption around ARR is that RETENTION will remain stable!
So how is ARR misused? The biggest culprit is describing non recurring revenue as ARR. And there’s many flavors of this. The most egregious is to take truly one time revenue, “annualize” it, and call it “ARR.” Let’s look at consumption revenue - this is also not technically recurring! It’s probably better described as re-occurring vs recurring. This is why the consumption players (Snowflake, Mongo, Confluent, Azure, AWS, etc) so more variability in the macro slowdown. When Snowflake went public I think they had a slide in one of their earlier quarterly presentations that very explicitly stated “we are NOT a SaaS model.”
The reason it matters that ARR is misused, is that the biggest downstream effect of misused ARR is the retention. For true ARR, retention is usually stable and predictable, so it’s “ok” for most of the present day valuation to be based on outer years / terminal value. For “fake” ARR, retention can vary wildly. And as I described above, a lynchpin of SaaS valuations lies in the retention, and assumptions made around it. If retention deteriorates, the terminal value may very well be 0.
This brings me to AI (everything leads to AI these days…). As I mentioned, there are many ways ARR is misused today. The two most common are annualizing non-recurring revenue (say multiplying monthly revenue x 12), or taking reoccurring revenue can calling it ARR. When it comes to AI there is now another BIG culprit in misused ARR which I’m calling ERR (we use this term internally). ERR stands for Experimental Runrate Revenue. A huge portion of AI revenue today is truly experimental! There’s very little organization maturity around the procurement of AI solutions. Every buyer is kind of scrambling to figure it out. It’s surprising how “open” budgets are for AI solutions in an otherwise tight budget environment. Customers are experimenting on two vectors - functionality and vendor. There may be some functionality a company is looking for, and they’ll quickly move to buy a solution. And because the AI (particularly generative AI) space has so recently come on the scene, there aren’t a huge number of vendors! But this is changing - many categories are becoming commoditized leading to massive pricing pressure. And revenue some AI vendors thought was ARR was actually ERR as their customers are now moving to alternatives.
Buyers are also experimenting on vendors. A buyer might want to build some product / feature and will turn to the quickest / most available solution to build a prototype or watered down version. Once that prototype version has been built and validated, buyers will then ask themselves “what tools to we actually want to build this functionality on when deploying to production.” They’ll look at things like cost, scalability, compliance, etc. The most common product group put in this category is vector databases. Companies will often times build out early functionality with a dedicated vector database, but then when it comes time to scale it out and deploy to end customers they’ll go with MongoDB (or some other larger player) who they already have an enterprise relationship with (know it scales, already through security review, know the costs, etc).
To summarize - we’re seeing a lot of experimental revenue in the AI space that doesn’t appear to have the same retention qualities of true ARR. It’s important for founders to recognize, and be intellectually honest with themselves, about the quality of their revenue. Do you have ARR or ERR? Headcount planning, budgeting, fundraising, etc can often be largely based on a top line plan. And mistaking ERR for ARR can lead to wildly swinging top line plans and poor decisions today (with real consequences in the future).
Quick Macro Update
We also got an update from the Fed this Wednesday that sent the markets higher. The TLDR is the Fed expects to have 3 rate cuts this year. They expect GDP to grow 2.1% (ie strong economy / no recession) which is up from their projection of 1.4% in December, unemployment to be 4.0% which is down from their prior projections of 4.1%, Core PCE inflation to be 2.6% which is up from their prior projection of 2.4%, and the fed funds rate to end the year at 4.6% which is the same as their prior projections. You can see this data in the table below:
Top 10 EV / NTM Revenue Multiples
Top 10 Weekly Share Price Movement
Update on Multiples
SaaS businesses are generally valued on a multiple of their revenue - in most cases the projected revenue for the next 12 months. Revenue multiples are a shorthand valuation framework. Given most software companies are not profitable, or not generating meaningful FCF, it’s the only metric to compare the entire industry against. Even a DCF is riddled with long term assumptions. The promise of SaaS is that growth in the early years leads to profits in the mature years. Multiples shown below are calculated by taking the Enterprise Value (market cap + debt - cash) / NTM revenue.
Overall Stats:
Overall Median: 6.3x
Top 5 Median: 19.1x
10Y: 4.3%
Bucketed by Growth. In the buckets below I consider high growth >27% projected NTM growth (I had to update this, as there’s only 1 company projected to grow >30% after this quarter’s earnings), mid growth 15%-27% and low growth <15%
High Growth Median: 10.9x
Mid Growth Median: 9.6x
Low Growth Median: 4.5x
EV / NTM Rev / NTM Growth
The below chart shows the EV / NTM revenue multiple divided by NTM consensus growth expectations. So a company trading at 20x NTM revenue that is projected to grow 100% would be trading at 0.2x. The goal of this graph is to show how relatively cheap / expensive each stock is relative to their growth expectations
EV / NTM FCF
The line chart shows the median of all companies with a FCF multiple >0x and <100x. I created this subset to show companies where FCF is a relevant valuation metric.
Companies with negative NTM FCF are not listed on the chart
Scatter Plot of EV / NTM Rev Multiple vs NTM Rev Growth
How correlated is growth to valuation multiple?
Operating Metrics
Median NTM growth rate: 13%
Median LTM growth rate: 17%
Median Gross Margin: 75%
Median Operating Margin (12%)
Median FCF Margin: 10%
Median Net Retention: 110%
Median CAC Payback: 38 months
Median S&M % Revenue: 42%
Median R&D % Revenue: 25%
Median G&A % Revenue: 16%
Comps Output
Rule of 40 shows rev growth + FCF margin (both LTM and NTM for growth + margins). FCF calculated as Cash Flow from Operations - Capital Expenditures
GM Adjusted Payback is calculated as: (Previous Q S&M) / (Net New ARR in Q x Gross Margin) x 12 . It shows the number of months it takes for a SaaS business to payback their fully burdened CAC on a gross profit basis. Most public companies don’t report net new ARR, so I’m taking an implied ARR metric (quarterly subscription revenue x 4). Net new ARR is simply the ARR of the current quarter, minus the ARR of the previous quarter. Companies that do not disclose subscription rev have been left out of the analysis and are listed as NA.
Sources used in this post include Bloomberg, Pitchbook and company filings
The information presented in this newsletter is the opinion of the author and does not necessarily reflect the view of any other person or entity, including Altimeter Capital Management, LP ("Altimeter"). The information provided is believed to be from reliable sources but no liability is accepted for any inaccuracies. This is for information purposes and should not be construed as an investment recommendation. Past performance is no guarantee of future performance. Altimeter is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration does not imply a certain level of skill or training.
This post and the information presented are intended for informational purposes only. The views expressed herein are the author’s alone and do not constitute an offer to sell, or a recommendation to purchase, or a solicitation of an offer to buy, any security, nor a recommendation for any investment product or service. While certain information contained herein has been obtained from sources believed to be reliable, neither the author nor any of his employers or their affiliates have independently verified this information, and its accuracy and completeness cannot be guaranteed. Accordingly, no representation or warranty, express or implied, is made as to, and no reliance should be placed on, the fairness, accuracy, timeliness or completeness of this information. The author and all employers and their affiliated persons assume no liability for this information and no obligation to update the information or analysis contained herein in the future.
Great read this week! Are there historical parallels for cloud etc that can help inform how to value ERR?
Excellent explainer and post!