the ambiguity of ARR
this blog in a Tweet
ARR should mean "annual[ised] recurring revenue" but it is getting bastardised in a chase for flashy metrics. Don't get dragged into the nonsense or you'll lose credibility with the investors you actually want.
what is ARR?
The proper meaning of ARR is "annual[ised] recurring revenue".
Each one of those three words is important, so let's take them one by one.
annual[ised]
To annualise something means to approximate an annual equivalent of a point-in-time number. Most sensibly, it would be taking a monthly recurring revenue number and multiplying it by 12. The logic of doing so is to extrapolate the latest numbers to illustrate what scale the business would be at if it had been operating at its current velocity for the past 12 months (or will continue to operating at its current velocity of the next 12 months). It is particularly useful for fast-growing start-ups because it lacks both the lag of a "last 12 months" revenue figure, and the flakiness of a "next 12 months" figure.
recurring
Originally it was mainly B2B startups who spoke about ARR.
It was a way to strip out the noise of one-off income streams like implementation fees and professional services, and get to the nub of the core, high margin, recurring software income. With business customers typically less fickle than consumers, it was a relatively good bet to call this revenue "recurring" as you could reasonably expect long term contracts, often with high renewal rates.
But the concept seems to have weakened as business models - and morals - have evolved in an increasingly frenetic fundraising environment.
The most ironclad type of "recurring" is contracted revenue, for example a multi-year contract. In this case, revenue is nailed on: there is no new decision point for the buyer, and the seller can safely assume the revenue will come again this time next year, absent some catastrophic service failure that gives rise to a termination of the contract.
In the middle is subscription revenue that operates on a shorter timeline - typically annually or monthly. Here, there is risk that customers churn at the end of the billing cycle, but the default position is that the customer continues to pay as long as the product continues delivering value. In the SaaS era, this tends to be the most common definition of "recurring" and is broadly defensible.
The least bankable type of "recurring" is transactional revenue, where the customer has to actively come back and buy again in order for the revenue to recur. This can absolutely happen, for example with a very loyal customer of a high-frequency consumer product, but the relatively unknowable nature of the repeat purchase typically pushes it outside the perimeter of "recurring", unless the behaviour is highly predictable and repeatable. In the AI era, it could be argued that token consumption is mostly transactional and so its "recurring" nature is questionable until the behaviour is proven.
revenue
This is the income to the company providing the service, earned over the period to which the income relates.
This ought to be relatively straightforward, with two exceptions.
The first is where the company is facilitating transactions between third parties (e.g. marketplaces). In this instance, "revenue" is the take rate of the transaction, not the total transaction value itself, which is more accurately defined as Gross Merchandise Value/Volume ("GMV"). Mixing up the two inflates true revenue by 1/take rate.
The second - which is more common - is the conflation of cash income, and revenue. More on that below.
how to fudge it
The fight to “build in public” with impressive ARR charts showing up-and-to-the-right growth on LinkedIn posts is leading to the misuse - deliberate or otherwise - of the ARR acronym.
The sneakiness shows up in a few ways.
First, I would question whether it’s right to call a lot of this revenue “recurring” - particularly in a pro/consumer context with minimal contractual commitment. Is it annual “recurring” revenue if churn is 10% each month? What about if you sell 1-year contracts and haven’t yet had a churn opportunity (i.e. you’re less than 12 months post-launch) to understand long-term behaviour? Is your recurring revenue actually just experimental transactional stuff that has no hope of sticking around?
Second, revenue ≠ cash. Revenue is recognised over the period the product or service is delivered. If someone buys an annual subscription for £120 and pays up front in January, your cash income in January may be £120, but your revenue is only £120 / 12 = £10. This may seem like accounting semantics but it really matters if you’re annualising from monthly numbers. What we often see is the full £120 being included in a monthly figure that then gets multiplied by 12. So that customer signing up in January all of a sudden shows up as £120 x 12 = £1,440 of ARR, which is obviously wrong - by a mile.
Third is the nonsense ways of "annualising". One version of this is ignoring seasonal purchasing patterns: annualising a run-rate revenue number from November for a gift wrapping service is obviously stupid as there is massive seasonality in the revenue profile. Another flavour is annualising a very short period of time, like today's revenue multiplied by 365. The bigger the number of periods you're "guesstimating", the more off you're likely to be.
...and why not to
The irony of all of this is that the founders often know the game they’re playing. Nobody could run a business this way because pretty quickly you’d get punched in the face by the lack of drop-through from ARR to actual revenue. But it’s all a song-and-dance to flex to investors, peers, competitors and other commentators online.
FWIW, the investors you actually want on your cap table see through this nonsense in an instant, so I’d advocate being more up front and transparent about where the cracks are showing. I’d rather have a self-aware founder with a nuanced understanding of their business, its problems and how to fix them, than a hype (wo)man focused on winning the LinkedIn pantomime.