The Mental Mapping from Annual to Monthly and Usage-Based SaaS Metrics

A guy walks into a bar and orders a $17 Martini.  Is it MRR (monthly recurring revenue)?

The potentially surprising answer:  maybe, and often yes.

• If he’s a tourist who happened to walk in, then no, it’s not MRR.
• If he’s lived here for two years and comes in every Thursday for a Martini, yes.  He represents $68 of what I’d call empirical MRR [1].
• If he just moved in next door, says every Thursday he drinks a Martini, and he’s selected our bar as his new spot, then I’d also say yes.  I might call this intentional MRR, much like signing up for a SaaS service on a month-to-month basis [2].
• If the bar’s in a club with a $2000 annual membership and a quarterly food and beverage (F&B) minimum of $221, I’d say yes.  It’s contractual MRR.  I’d probably even call it $2,884 of ARR, not MRR, to reflect the annual nature of the contract [3].

I’m writing this post to help readers who (like me) grew up in an annual subscription SaaS world adapt to the new and increasingly popular world of usage-based pricing [4], including month-to-month contracts and variable fees [5].

In this new world, people still use terms like ARR and MRR.  For example:

But what does this mean in a usage-based world?  Specifically, what does “recur” mean?  Why does the phrase “recurring revenue” appear exactly zero times in Snowflake’s 10-Q?

And what’s the impact on your other SaaS metrics?  What’s your CAC ratio if I don’t know what your ARR is because I don’t know what the recurring means?  What’s your churn rate? What if a customer fluctuates across months: do I count churn each month they shrink and expansion each month they expand?  If ARR is a forward-looking metric [6], what do ARR-based metrics like net dollar retention (NDR) mean [7] in a world without fixed forward commitments?

What Does Recur Mean?
So many questions.  But since I like to start with the basics, let’s go back to our bar and think about Martinis and the meaning of the word recur.  In the annual world, “recur” seemed pretty clearly defined.  Unlike perpetual software license revenue, which was largely one-shot in nature [8], SaaS subscription revenue would recur.  A customer would purchase a subscription to a service for a time period.  At the end of the period the customer could, and usually would, renew the subscription to the service.  Hence, the revenue recurred.

The subscription period varied typically as a function of contract size and target market.  A $200/month product might have a month-to-month contract with monthly billing, whereas a $2,000/month product might have an annual contract with up-front billing, and a $20,000/month product might have a three-year contract with annual billing [9] [10].

The important point here seems forgotten by time:  recur didn’t mean a company gets $10K per month from a $120K annual contract [11].  Recur meant the $120K contract had a fixed duration and periodically came up for renewal [12].  Recur never meant contractual.  The revenue didn’t recur contractually across contract periods.  The fact that it might, however — unlike perpetual license — meant that it recurred.

I’ll say it again.  Recur never meant contractual.  Which is why I think the Martini revenue in the second and third examples is MRR.  There’s no contract that says the guy has to come in every Thursday.  But, empirically, he does.  There’s no binding commitment that our new neighbor will come in every Thursday going forward, but he said he would.  That’s as “recurring” as an annual SaaS renewal.

The Usage-Based Model
To make our Martini bar more reflective of usage-based SaaS, let’s change our example a bit:

• After a few trial visits, you are no longer admitted to the bar until you sign a contract.
• The bar sells credits, which you can buy purely à la carte but they now cost $20.
• If you buy 20 credits or more, they cost $17.  More volume discounts exist beyond that.
• Overage credits can be purchased at $19, a price designed to incent purchasing more regular credits up front, possibly even hitting the next discount level where they are $16.
• Unlike many other bars [13], unused credits may be rolled over into the next year’s agreement.

Our customer signs a deal for 52 credits at $884 to cover his weekly Martini.  Some weeks he either brings a friend or has a hamburger and spends two credits, so his monthly credit usage ends up looking like this:

He’s spent 32 credits in the first half of 2022, on pace to spend 64 on the year, well above his 52 credit plan.

What is the MRR?
If you come from the annual world, you might be tempted to break the 52 purchased credits across the year (especially if they don’t rollover) and say his baseline spend is one credit per week, thus 4.3 per month.  At $17/credit, that’s MRR of $73.66.  But he spent 15 credits in 1Q, so you might bill him for 2 overage credits ($38) and then spread that across the three months to arrive at MRR of $86.30.

I think the psychological issue here is that you’re fighting to stay in the MRR mindset, thus allocating the credits by month, and then applying overages as you go along.  You’re doing that, I believe, because you view the baseline as “recurring,” but not the overage.  You’re stuck on MRR, and that’s potentially based on the faulty notion of recurring that’s discussed above.  Now imagine doing this with multiple products and a hybrid pricing model that includes both monthly subscriptions and multiple different consumption fees (e.g., compute, storage, API calls).

Trailing Spend Calculations to the Rescue
Let’s send in the external financial reporting team to save us.  What do they see?  Simple.  They see quarterly revenue of 15 credits x $17/credit = $255 in 1Q22. They would not report it as baseline and overage revenue, but aggregate it to F&B revenue [14].

This is a better way to view things.  The problem is less that it’s usage-based pricing and more that it’s monthly-varying pricing.  Much like our bar, a customer’s monthly spend bounces around so we’re never quite sure what’s fluctuation vs. churn/expansion and we don’t know what they’re going to spend in the future.  MRR thus becomes an inferior unit to quarterly spend.

What is the Net Expansion?
When we think about expansion (or churn) let’s stick with trailing spend and not fuss about trying to first calculate MRR and then see how it changes.  With that in mind, what is customer A’s net expansion in 2Q22?  $34, right?  He spent $289 in 2Q22 and $255 in 1Q22, and the difference is $34.

Wrong.  At least in the traditional SaaS world where the correct answer is unknown.  Why?  Because we don’t have last year’s 2Q21 data in the spreadsheet and in the traditional SaaS world, churn is a year-over-year metric [15].  Monthly SaaS tends to silently slip your brain into a quarter-over-quarter mindset, as you see with metrics like lazy NRR, which is quarterly, compared to NRR, which is annual [16].  Note that this is not a bad thing — in the usage-based world, you need to watch customers and their usage like a hawk — it’s just a different thing if you grew up in the annual SaaS world.

Let’s provide the 1Q21 data we need and then answer the question.

Customer A used 13 credits in 2Q21 and 17 units in 2Q22, so he expanded by 4 units.  But, he negotiated a better price per credit in 2022 ($17 instead of $18) so his spend went from $234 in 2Q21 to $289 in 2Q22, an expansion of $55, reflecting a net expansion rate of 124%.  Had the customer’s spend been the other way around and shrunk to $234 from $289, it would be churn of $55, reflecting a churn rate of 19%, or a net expansion rate of 81% [17].

What is Net Revenue Retention?
Isn’t net expansion rate the same thing as NRR?  Well, as I’m using the terms here, no.  Above, we calculated net expansion rate using year-over-year quarterly spend.  In the traditional world, NRR is supposed to be a year-over-year ARR comparison.  But in the monthly SaaS world, we don’t really have ARR [18], so what can we do?

We can rely on trailing spend calculations to save the day.  For example, we can define NRR, as Snowflake does, to be trailing one-year spend divided by trailing year-before-that spend for customers who started on or before the first month of the year-before-that period.  Here’s how Snowflake says that:

We need more data in our Martini bar example to calculate NRR, so here it is:

Let’s calculate NRR for customer A as of 12/31/22 using the Snowflake NRR formula.  In the trailing year (2022), he spent $1,131.  In the year before that (2021), he spent $936.  Thus NRR is 121% (= 1311/936).

Please note that this makes NRR — and every other metric that substitutes trailing spend for ARR/MRR — more backward looking than their ARR/MRR counterparts.  Why?  Because in an annual subscription world, NRR would compare 2023 to 2022, not 2022 to 2021.  That is, NRR would compare the ARR value of the renewal we signed on 12/31/22 for the coming year (2023) to the one we signed on 12/31/21 for the then-coming year (2022).

Before moving to other topics, let’s quickly review how other leaders calculate NRR.  Twilio defines NRR in line with how I defined net expansion rate, above (i.e., quarter over prior-year quarter).  Note that, oddly, when calculating it for a year instead of comparing two trailing 12-month periods, they instead use a (presumably unweighted) average of the quarterly rates.

Datadog, often described as a usage-based pricing leader (e.g., in the OpenView Usage-based Playbook) seems to rely more heavily on subscriptions than the hype suggests.

Datadog calculates NRR using a rather traditional ARR-based formula.

Finally, Hashicorp, a company known for both land-and-expand and usage-based pricing, defines NRR as follows, which includes their definition of ARR (which is roughly annualized spend):

So, basically, in a monthly or usage-based SaaS world where ARR doesn’t really exist, you can either look at trailing spend or annualizing periods.  And, as we’ve seen, there really aren’t any standards here so caveat emptor when comparing the NRR reported by different companies.  Personally, in the absence of actual ARR, I prefer tracking actual spend as it reduces the risk associated with annualizing seasonally strong (or weak) periods and getting an over- or under-stated result [19].

What is Implied ARR?
All public SaaS companies report revenue.  Few report ARR.  Thus, long ago public investors and financial analysts created new SaaS metrics to try and approximate the SaaS leaky bucket:

• Implied ARR, which estimates the size of the ARR pool and is calculated by multiplying last-quarter’s (subscription) revenue by 4 [20].
• Billings.  Revenue plus change in deferred revenue, which is designed to estimate bookings (i.e., new sales).  If payment terms and contract lengths are constant, this one works pretty well, but can break when they’re not.

You might wonder, in a monthly or usage-based SaaS world, if you couldn’t just use implied ARR and then calculate SaaS metrics like the CAC ratio off that.  Sometimes the answer is yes:  CAC ratio (and magic number) and CAC Payback Period are often calculated off changes in implied ARR.  Sometimes the answer is no:  you can’t do NRR because you can’t get the cohorts, and you can’t do churn rates because you don’t see the offsets between new-logo, expansion, and churn ARR.  But the real reason is that these tend to be investor metrics, not calculated by public companies but calculated for (or about) them by financial analysts.  Internally, since they have all the non-disclosed ingredients, I think they look at the real thing.

Conclusion
Well, this turned out to be a lot bigger than I’d thought when I came up with the Martini bar analogy. Hopefully (particularly if you were raised in the annual SaaS world) you’ve appreciated this walk over the long and rickety bridge that connects traditional SaaS metrics to the world of monthly and usage-based SaaS.  I think I’ve answered all the questions I posed at the top, though admittedly in a somewhat unstructured way.  If you think I missed one, or this post has prompted another, please let me know.

# # #

Notes
[1] Let’s pretend every month has four Thursdays to keep MRR simple here.  (Later we’ll use 52 weeks per year.)

[2] Arguably deserves the MRR moniker more than the month-to-month SaaS service, where the customer might must just be trying it out.  In this example, the customer has stated this will be their Thursday night Martini spot.  He’s ours to lose.

[3] I am somewhat fanatical that ARR isn’t just MRR multiplied by twelve.  Why?  Because if al your contracts are month-to-month, I think it’s misleading to talk about ARR.  Conversely, if all (or the majority) of your contracts are annual, I think it’s silly to talk about MRR.  Yes, math wise, one is 12x the other, but the choice of unit does make an implication about the nature of the contracts.

[4] At least for now.  The downturn may well reveal the Achilles’ Heel of usage-based models — it’s great when usage is always going up.  When it’s not, well, not so much (and those annual commitments start to look a whole lot better).

[5] Also known as consumption-based pricing.  I tend to use the terms interchangeably.

[6] While I’m not sure people think about this way, in reality, ARR is a forward-looking metric.  It’s about what people are promising to pay you in the future.

[7] In the annual subscription world, NDR is also forward-looking.  You’re looking at what customers are promising to pay you in the coming year vs. what they promised to pay you in the then-coming year, one year ago.  

[8] There’s ostensibly considerable irony in the word “perpetual” meaning one-shot, but remember perpetual was describing the duration of the license, not the nature of the revenue.

[9] This varying period made it hard to interpret some SaaS metrics.  Should a company that does exclusively two-year contracts calculate churn rates based on the entire ARR pool or on an available-to-renew (ATR) basis?  It’s a factor of 2 difference with a company that does purely annual contracts, yet people will often unknowingly compare them.  See Churn is Dead, Long Live NDR.

[10] Salesforce started out with months as the contract and billing period, but quickly moved to years to avoid the hassle of monthly invoicing for enterprises, who generally preferred the simplicity of annual contracts, and to avoid running out of cash by billing a year up-front.

[11] That’s just revenue recognition.

[12] Which is why some perpetual license companies first moved to term licensing (e.g., selling three-year term licenses) as a discounting alternative and, while not widely recognized at the time, pretty strongly resembled SaaS companies, with the major exception that they didn’t run the software.

[13] I’m not sure how many companies allow rollover, but I think it’s not that common, though Snowflake is an example of someone who does, provided your next-year commitment is bigger than this year’s.

[14] Or, as Snowflake calls it, “product revenue.”

[15] The standard definition of churn compares ARR/MRR at this year’s renewal to last year’s initial contract or renewal.  Not last quarter’s.

[16] If you say NRR is 108%, it’d sure be helpful to know if that’s classic year-over-year (in which case it’s just OK) or lazy quarterly, which compounds to 136% year-over-year (in which case it’s amazing).

[17] Note the subtlety here that we’ve quietly switched the units of churn to simply dollars (for a period) as opposed to MRR or ARR dollars.  In the rates, the units cancel out.

[18] Except for Implied ARR, which we’ll discuss in a minute.  But I’m not in love with using a calculated or implied metric as an input to a formula.

[19] As a dramatic example, if you annualized December bookings at most software companies, you might get 2-3x the actual annual result as a typical enterprise software company might get 20% of its annual bookings in the last month of the year.  Tracking trailing twelve months of any metric that shows annual (or shorter) seasonality will tend to damp that out.

[20] This works pretty well in enterprise SaaS where new bookings are generally quite backloaded.  Thus, last quarter’s ending ARR is the heavy-majority source of this quarter’s subscription revenue.  (Few contracts stop before quarter’s end because they were backloaded when signed, and few new contracts get signed before quarter’s end.)  This, however does mean that implied ARR is effectively one quarter phase lagged.