I have come to trying to deeply understand accounting and finance rather late in my career. Better late than never, considering I’m now a venture capitalist.
My father was an accountant and CFO of a manufacturing company. I think he would have been impressed how today’s accountants and finance leaders have developed new techniques and terminologies for SaaS, building on the traditions of management accounting. We have some robust methods now to understand the health of a business and to effectively guide business decisions. Over 100 years ago folks like Donaldson Brown, who figured out the Du Pont analysis, gave us tools to understand industrial companies.
Ben Murray, Dave Kellogg, Kyle Poyar and others have given us the tools to understand SaaS in a really refined way. We can benchmark SaaS with precision. It’s a mature business model now, not just a mature technology.
While the move from on-prem to cloud for applications was initially driven by a shift in technology deployment model embraced by new vendors (like Salesforce, SuccessFactors and Workday), what investors really loved was the predictability and margin clarity of the subscription revenue. We take this for granted now, but the reason why the likes of SAP and Oracle got on the cloud bandwagon a while back was for the business model revenue valuations, not really the tech disruption.
SaaS’s most important term is ARR. Annual Recurring Revenue, almost everything hangs off this. Churn, customer life time value, cohort analysis etc. We have ratios now for everything.
ARR isn’t a GAAP metric, so we don’t have an accounting body telling us what it can and can’t consist of. Formal revenue recognition is a different matter, ASC 606 anyone?
Here is my simple definition of ARR.
Revenue: Is there Money?
Annual: Yearly (can be monthly x12).
Recurring: Happens consistently.
Money: Stating the obvious, but does the deal create an obligation to pay something on a given date? I’ve seen some contracts that don’t actually create an obligation to pay money, but are based on number of users post go live. If the customer doesn’t go live, there is no revenue. This could become ARR at some point in the future, but it isn’t immediately.
The recurring element of ARR is where we get some of confusion. When a contract is over multiple years, it is clearly recurring within the contract time frame. It is also recurring where there a very high probability that the user will renew the contract (for instance a monthly contract that has been running for 18 months and has auto renewal is very likely to be renewed again). There is an element of judgement involved in determining what is genuinely ARR.
But I really like this definition from Scott Taback.
There are two forces at work messing up the cosy world of ARR.
We now have a definition creep problem
One of them is simply term discipline. Unless we are disciplined, definitions bloat. A TLA creates a sense of abstraction. I try and avoid saying ARR, I say the words instead, just to remind myself of what it means.
Instead of seeing ARR as a component of total revenue, many founders (and a few investors) use it as a synonym for total revenue. If a business has being going for less than a year, has contracts that can be cancelled after a month or two, lots of POCs, and services, and they are lumping it all into ARR, I would be really concerned as an investor. The question I regularly ask is what % of your revenue isn’t ARR- it’s a powerful heuristic to test the overall robustness of the financial discipline.
The second problem is more complicated. It’s to do with AI.
We are in a phase of technology and business ferment. SaaS took about a decade to figure out its accounting techniques, and has been the dominant design since then. Today this design is beginning to creak at the seams.
Please have a look at this post from Dave Kellogg,
The concept of ARR is already challenged by monthly-varying pricing, e.g., usage-based pricing.
AI will exacerbate that problem, bringing new forms of value-based pricing, e.g, unit-of-work or outcome-based pricing.
There are two schools of thought on dealing with this: (1) split the ARR baby into baseline and variable, then analyze the baseline as if nothing has changed, and (2) spend is truth, where we substitute trailing spend for ARR. I’m in the second camp.
AI will, gasp, require us to think about cost, something we don’t really like to do in the software business and something we’ve historically been able to kind of ignore.
All the heavy lifting is going to move to the pricing model.
In short, to know ARR we used to read contracts. In the future, we’re going to read invoices, instead.
Please look through the slides too
Kyle Poyer is saying something similar.
AI startups are increasingly throwing this off.
What's not classic ARR -- but often treated as such:
- Experimental revenue from AI products (not in production)
- Contracts w/ a 3 month opt-out where 70-80% opt-out
- Usage-based or pay-as-you-go pricing
- Payments or FinTech revenue
- Success-based pricing (see: Intercom, Zendesk)
- Professional services revenue
We're moving away from charging for *access* to software and to a model of charging for the *work delivered* by AI & software.
This might mean greater volatility. Variable margin profiles. Seasonal revenue. Project-based, non-recurring use cases. Experiments that don't move forward 🤯
Most of the founders that pitch me today have a lot of AI technology in their story. Some of it is really exciting, but whereas for the last decade we have been able to comfortably rely on the SaaS accounting model to predict revenues, measure performance and estimate value, we are moving into a world that less certain.
I’m thrilled to see the rapid revenue growth of AI companies like 11x (see Jason Lemkin’s post here), but we can’t blindly use the accounting techniques of classic SaaS to evaluate them. There is nothing wrong with doing paid proof of concepts and pilot projects, but be modest about what you label as ARR. A six-month 100k POC is still a POC.
The accounting models for AI are going to be quite different from classic SaaS. I think they will build on SaaS, in the same way as SaaS builds on traditional management accounting. But we don’t yet really know what good looks like, never mind how to measure it precisely. We will have to spend more time really understanding the business model. More imagination, more risk. Bring it on. Just don’t tell me all your revenue is going to be ARR.
Regular readers will know that I usually drop in a song at the end of the post (I do this often enough for it to be considered recurring).
Here’s Adam and the Ants, from 1981.
Stand and Deliver.
I'm the dandy highwayman who you're too scared to mention / I spend my cash on looking flash and grabbing your attention.
I read a post yesterday and I can't find it about 23andme yesterday talking about this - the reality that high momentum that isn't sustainable isn't a great ending. I wrote about this last Nov but even my thinking has evolved since this post https://www.megbear.com/post/fundamental-shifts - I am now of the belief that not just the business model but the organizational structure of software is going to have to change to create predictable and sustainable growth. There is a lot to unlearn here.