Is ARR Dead?

Live from Schenectady, New York, it's SAS Talk with the Metrics Brothers, Growth and CAC.

And I'm Growth, better known as Ray Reich, founder and CEO of Benchmarkit.

And I'm CAC, better known as Dave Kellogg, EIR at Balderson Capital, independent consultant, and the author of Kelblog.

And together we are the Metrix Brothers.

And we go together like tapas and vino tinto, Ray.

Are we in Spain there, Brother Dave?

We are indeed, as you can tell from my light clothing. Uh, we are indeed, and there's nothing that I like to do more in Spain than—

Talk about the rumors of the death of ARR.

Exactly, my favorite vacation activity.

And that, well, that is our topic for today. Is ARR dead?

Okay, well, that is our topic, Gray, and I'm excited to talk about it. But before diving in, let's hear a word from our sponsor.

The Metrics Brothers is proudly sponsored by Benchmarkit, the B2B AI and software industry's largest, broadest, and most contextualized benchmarking index. Dave Kellogg and Ray Grothright Have put the Metrics Brothers podcast on hiatus for the remainder of 2026. All episodes we have ever recorded are still available on your favorite podcasting app. You can reach Dave at Kellogg and Ray on LinkedIn at Ray Reich. Thank you so much for listening to the Metrics Brothers podcast. Okay, Dave, well, let's get going. I know you did a lot of thinking and work on this, so why don't you kick us off?

You know, it's hard to go online these days without reading some blog or social media post declaring the death of ARR. And in fact, Ray, I may have been a part of starting this trend at your conference at SAS Metricspalooza in October of 2024. I did a talk called The Impact of AI on SAS Metrics. And there were 2 key slides in there that a lot of people were talking about. One was a picture of Atlas holding up the world. And Atlas was ARR holding up the world, which was SAS Metrics. And the next slide after that was Achilles being dipped into the River Styx. And for those who are not Greek mythology fans, remember the Achilles heel is his weak spot because that's where they held him when they dipped him into the waters that gave him immortality. So, he had this little spot on his heel that was his point of vulnerability. And I had basically the ARR being the Achilles heel of SaaS metrics. So, I feel like I was one of the first 2 people to put kind of in plain English that the more SaaS business models changed from annual subscription, the less meaningful ARR became, and in turn, the more broken the foundation for SaaS Yeah, and here it was, a session about AI, and it created this firestorm that's went for 12+ months now of what is ARR, is ARR dead.

And, you know, I can't— Dave, it's, you know, Ben Murray, CJ Govsason, Only CFO, you know, notable, a lot of them, the ones you're going to talk about today, everyone is talking about this because it's so fundamental to how we've established the valuation of SaaS companies.

Correct. And it's, you know, it's also a catchy headline. So I think everyone's realized that as well. So, you know, in my opinion, to net this out, ARR is not dead, but it is wounded. And that's why everyone's talking about it. So let's— the impetus for this post, there are a couple of blog posts I saw that Ray referred to, but maybe the, I don't know, the first impetus was Ben Murray's post where he analyzed 167 public company filings for the definition of ARR and the calculation of ARR. And in these filings, he found that 50% of them mentioned the term ARR. Only 38% defined it and 26% disclosed it. So, 107 companies in his sample, 62% did not define ARR. And for those who did, they broke into 4 groups, each group with a number of subgroup groupings. So, this gets complicated quickly, but Ben broke it really into 4 groups. Those who defined ARR as subscription only, Those who defined ARR as subscription plus variable, those who defined ARR as subscription plus managed services, and those who did variable only. And Bray, I know you've done some work in this area. What's your take on this?

Well, when I started covering variable pricing models and benchmarking that, things like usage-based pricing or value-based pricing, and I did that starting in '22, we asked those companies that had some type of variable pricing How do they calculate ARR? And I was shocked at that moment. In 2022, 78% of companies said they included any variable revenue associated with a subscription agreement they counted as ARR. And I didn't get into the nuances that we're going to get into today, but I was shocked. How can you take variable revenue, which is not guaranteed to be here next month, As annual recurring revenue, but 78% of companies did it, Dave.

Yeah, it doesn't surprise me, Ray. One of the features of my talk was what does recurring mean anyway? And if you go back to the history of all this, recurring actually meant might recur, right? Because on-premises revenue definitely would not recur because you bought a professional license or perpetual license, whereas SaaS revenue might recur because you might renew. In fact, if you wanted to keep using the service, you had to renew. So, but in the end, Ray, it doesn't surprise me because people don't want to not count things. And if ARR is the primary metric for a SaaS company, which it tends to be, people don't want to leave out something important from it. The other thing I'll say is, is it kind of empirically recurring? Like if you've got a regular customer at your bar who comes in and drinks every Tuesday night, there's no contract, right? It's just purely usage-based, i.e., how many martinis he or she drinks. But in fact, you'd probably call that person a regular, and that would honestly be kind of empirically recurring revenue. So, I'm not surprised at the result you found in your research. I think maybe for internal reporting, Ray, people might actually split kind of subscription plus variable and do different analysis on subscription only versus the variable part. But I think when you go into a kind of external metric, like what do you talk to investors about, public or private, and you have to boil it down to one number, ARR, I think it's very painful to leave stuff out of that, basically. And I think that's why people include it.

Yeah. Well, the other thing is just how inconsistent the definition and calculation formula is of ARR. Is that something we want to talk about today?

Yeah, we can. I mean, I think what— because Ben did some work to uncover the definitions and he breaks those 4 groups into numerous subgroups based on different variables. We don't have time for that today, but one of my favorite quote definitions of ARR was MRR times 12, which is particularly helpful for people who don't define MRR. And I have seen that done fairly often, Ray, where people go, oh, you got a definition of ARR, it's MRR times 12. And then you say, what's MRR? And they're like, huh?

But Dave, doesn't that hearken back to the early days of Salesforce when they did a lot of the month-to-month agreements and they came up with the— well, I don't know if they came up with it, but they reported MRR, monthly recurring revenue, And they multiplied it by 12 to get ARR. That's where it started, right?

Yeah, well, I don't mind multiplying. I don't mind multiplying MRR times 12 to get ARR in most instances. That's not my issue. My issue is then you have to define MRR and they weren't doing it, right? They just kind of kicked the can down the road and said, we've got a very precise definition of ARR. It's MRR times 12. And you go, what's MRR? They have no definition, right? That was the case I'm worried about. Yeah, you're correct on the history of the array. SaaS is a reminder for those who forgot, Salesforce originally did monthly pricing and monthly billing. And it was the customers who said, stop. I'm using this system. I'm going to keep using the system. I'm probably going to use it for 10 years. I don't need 120 invoices to process. Let's just do annual contracts or longer than annual contracts. So, it reflected the mindset of the buyer as much as the company. So, in any case, so Ben Murray has done some great work on this. I encourage people to read that post. We'll do a roundup of the posts we're talking about at the end. But another guy who's done some great work here is CJ Gustafson. He has a post entitled How Public Companies Define ARR, and it starts with a nice pithy quote. He's an excellent writer, which is, ARR should be a clean, consistent metric, but in reality, it's a choose-your-own-adventure exercise where each company tweaks the definition to fit its narrative. And then, in his own inimical style, CJ goes deep on the wide variety of ARR calculations, how people annualize, is it 365, times a daily revenue? Is it 12 times a monthly? Is it 4 times a quarterly? Or going the other direction, is it half a 2-year contract or a third of a 3-year contract, which brings into questions of flattening for ramped contract? And he talks about the limitations of these. Like one of my favorite limitations is amplifying growth due to seasonality. So, like retailers get like 40% of the revenue in Q4, right? So, if you say the year is 4 times Q4, you're going to get 160% of the actual result, right? So, there's all the dangers of the annualization process. CJ talks about subscription versus overage, where I know your opinion is different than mine. So, you may want to talk about it in a minute. And he talks about really the recurringness of consumption revenue. Do you include it? Do you exclude it? You know, is it— can you take it to the bank or not? And often you can, right? Just because it's not a contract doesn't mean they're not going to keep buying it. So, but let me go back to you here, Ray, for thoughts.

Well, I want to meld a couple things we've talked about in the last 3 or 4 minutes. And that's the definition of MRR. The most creative one that I saw Ben Murray uncovered was one company said it's our monthly run rate revenue, not recurring revenue, monthly run rate revenue times 12, which is a little bit similar to the amortization model except it's using monthly versus daily. But I was shocked at that. That's what kind of liberty these public companies are taking with the concept.

Well, the craziest one I saw was the Confluent one. which he called an Andy Reid offense, which is— it's actually 2 different definitions depending on which product line. That platform-based was based on contracts over a 12-month period, and their cloud ARR was annualizing the last 3 months. So, that's one where even across products within a company, they're using different definitions of ARR. Yeah.

And then, I'm not CJ, but I'd like to think that I have a little bit of humor and insights. And so, I kind of did my own version of this, and that is SaaS pricing is evolving faster than investors can package the forecastable revenue to justify the higher valuations. I.e., we just don't know how exactly to keep these revenue multiples high, but we're going to come out with a definition that does.

Okay, okay. Uh, yeah, I think CJ said a similar quote, by the way, which was the SaaS industry has evolved way faster than the accounting frameworks to try to measure it.

Yeah.

And I think you're both saying the same thing kind of there, but you're a little bit implying intent, which is to keep multiples high. So why don't we go on now before we kind of free-for-all on this, talk about Notable, because the Notable Capital, formerly GGV, I have some friends there, including Glenn Solomon, and he and his colleague Laura Hamilton wrote a blog post, I think once again called Is ARR Dead? Yeah. Is ARR Dead or Is It Just Evolving? A Look at Consumption-Based Pricing. And by the way, most of the blog posts, including this podcast, That headline with ARR dead just quickly bridged to really a different topic, which is the evolution of pricing models, because pricing is kind of the underpinnings from which we get ARR. And in the old days, just as a reminder, ARR was easy because we signed annual contracts and you'd pay me $120 a year. It should be $10 a month for a user. And we knew what ARR was. By the way, in that model, ARR was actually forward-looking, which I think is important.

Right.

Because I would book 100 units of revenue on day 1 and say, over the next 12 months, I can expect to get $10 a month from Ray, $120 across the year, which made ARR a forward-looking metric. And a lot of the consumption-based models where you're— anytime you're annualizing trailing anything, you are not forward-looking, right? You're annualizing a past number. So, I do think Regardless of how the definitions all shake out, and I don't think they will for quite some time, the interpretation of this is very important because it's not just that there's a lot of different definitions of ARR, but fundamental things like, is this a forward-looking or backward-looking metric, and how far backward-looking does it go, all affects interpretation.

This is where I'm going to bring in a little bit of my, I guess, 30 years of experience in recurring revenue software business. Because in this article, they did a nice summary of that software pricing, as you said, and it included consumption-based and outcome-based. So, 2 things. I'm extremely cautious, if not even skeptical, of outcome-based pricing. I just think it's too hard unless the platform or the agentic AI service captures the actual outcome. And that outcome doesn't have changing baselines. And what I mean, Dave, I've seen a lot of companies say, well, I'm going to take a percentage of cost savings. But cost savings in year 1 might have been 20% off the baseline. But what are the cost savings in year 2? Is it off the baseline from the starting point? Or is it off the baseline from the end of year 1 or year 2? So, I actually believe that most outcome-based pricing is going to be very hard to implement. And even usage-based pricing, Dave, I believe that over time, usage-based pricing becomes subscription pricing because the buyers, especially the CFOs, Once they have proved the value of the software, they need predictable budgets. And they're going to ask that vendor to, hey, give me a guarantee of what my cost is going to be next year. And in fact, Megan Gill, who we had on this podcast, actually said a lot of their AE's time was just spent going into existing customers who had usage-based billing and renegotiating what their minimum contract was for the next 12 months.

Yeah, I mean, look, so much of the noise in Silicon Valley is generated by investors that reflects the investor-based viewpoint, and investors love consumption-based pricing and love outcome-based pricing. Customers, not so much, right? And there's these arguments that every time we change the pricing model, it better aligns the vendor and the customer, right? When SaaS came along saying, hey, annual subscriptions are much better than perpetual licenses because we're going to align the vendor and the customer. And it did at some level, right? In the good old days of perpetual, you could sell somebody a $10 million deal and you didn't actually care if they use the software or not. And you'd have a maintenance stream of whatever, $2 million a year after that. But you care a little, but not much. And then SaaS came along and said, hey, we're going to renew the whole deal every year or every couple of years, and therefore we're aligned. Like, we need you to be successful, otherwise you won't renew. And I suppose that was partially true. But then people would buy too many products, they'd buy too many seats, or they'd buy an addition, or I should say get sold too many products or an addition above what they needed. So, the problem never entirely goes away, right? So, this alignment thing is kind of a quest and it's kind of about trade-offs. You know, consumption-based actually aligns with the vendor's cost structure a lot now, particularly in the— either in infrastructure as a service or in AI, where costs are significant, right, and margins are low. Consumption-based pricing is actually very important. 'Cause it's like running a buffet, and if I have an all-you-can-eat buffet, some people could bankrupt me, right? So I need to be careful about all-you-can-eat, 'cause SaaS general subscriptions are all-you-can-eat, right? Here's, you get 500 users and everything they want to do, knock themselves out. But in infrastructure as a service or in AI inferencing, that will potentially bankrupt a vendor. So you need some sort of consumption-based to the model. So it aligns them, but maybe not in the way people want it, right? And then outcome-based pricing, It theoretically aligns them, but I also agree with your point, Ray, and it's a good one, which is after I've got those savings in year 1, they're the new baseline. So if I'm pricing as a function of savings, it gets very tricky very fast, and I still can't go back to the original cost because now there'd be other alternatives, right, I could use to have reduced that cost. Maybe not as much as your system did, but if I was spending 100 units and you did it for 30, is my new baseline 90 because I could have improved a little bit, or is my baseline 30 because that's what I did last year?

You know, I took your martini example. If people haven't heard it, you definitely got to search Kellogg for, you know, is buying a martini every once a week subscription or not? But my pub, the Irish pub around the corner, I was trying to—

Is it recurring or not? Just to be fair rates, is it recurring or not? It's definitely not a subscription unless it is a club. But is it recurring? Anyway, back to your Irish pub.

I tried to convince the owner of the Irish pub to put me on a subscription-based agreement. I could come in and have as many Guinness as I wanted. He thought that was a better idea. And he said, I'll charge you on outcome-based, how you feel when you walk out of here.

Okay. So, on outcome, let's talk about this. So, the other thing I want to talk about on outcome-based pricing is what I call Kellogg's 3 Rules of Pricing because I think the VCs look at big savings and they get super excited. Wait, my AI SDR can wipe out 10 SDR jobs. At $80K a year each, let's just say, costs somebody $800K a year. So, I can charge $700K and they'll still be saving $100K, right? That's kind of the VC view on things. And the issue is that you are potentially creating $800K worth of savings, right? And people will spend some, you know, up to maybe, I don't know, $700K. I'm not going to do the math for ROI. But they'll spend a lot of money to save it. You know, they'll spend $500K certainly to save $800K. So, the issue is there's another rule in pricing. So, value to me is an upper bound on pricing. The lower bound is alternatives. If there's 5 other richly funded VC-backed startups with AI SDRs, they're all creating $800K in value. But they may be bidding. They may be in a pricing war where one guy's bidding $50K, one's bidding $40K. I mean, they may sell it for $25K, right? That competition alternatives is the lower bound. And pricing usually ends up somewhere in between. And I just think it's important to remember this because people, they seem to forget that second part. They just look at the value and go, oh my God, we can save $800K. And it's like, yeah, but who else is out there and what are they charging?

Yeah. Well, I like your third rule of pricing. Can I talk about that?

Yeah, please go ahead. Yeah, that's it.

And you say, always hook pricing to things that go up. So, if you think about outcome-based pricing and you're reducing expenses, often that's going down. Maybe you can save them more money as they grow. But I really love that. Things that go up, the number of users and seat-based pricing, we always thought they were going to go up. Not anymore, right? API calls. Hopefully the company's growing and more API calls. But to me, that is critical.

Yeah, look, it's one of the 3 critical rules. I often joke that that was a secret passed on to me by the elders because if you go all the way back to mainframe software, it was priced by the MIP, which is a unit most of you probably won't know, but it's called MIPS, actually, million instructions per second. So, a 1 MIPS computer. And pricing was priced as a function of MIPS, i.e., as a function of the power of the CPU. Why? Because it always went up. Why do we like users for Salesforce? Because companies are always hiring salespeople, right? And AI is actually breaking— something's going up in the age of AI. It might be margins. But a lot of expenses are going down, to Ray's point. So, in any case, yeah, those are the 3 rules of pricing, which I think is always important to remember because the ARR conversation quickly becomes a pricing conversation. And there's 2 sides to it. is, okay, how do we turn this into ARR? My answer, by the way, is just spend is truth. So, I like just like annualizing last quarter, basically. There's some risk with that seasonality, et cetera. But my opening volley is spend is truth, that I don't want to get all wrapped around what might happen. The other alternative reality is just that minimums are truth, right? A lot of people follow that and then they have to split minimum— sorry, subscription and overage. But in any case, part of the conversation is how do we take this very complicated pricing model that's generating invoices and turn that into something called ARR? The other part of it is simply how much do we charge? And when it comes down to how much do we charge, those 3 rules really help, which is value, which AI is creating a lot of, is the upper bound. Alternatives are the lower bound. How many other people are fighting who can also create that same value, which case it becomes a pricing war. And then finally, in general, we'd like to hook pricing models to things to go up, that 2 things that go up.

You know, Dave, I can't believe it. Here you are, you're in Spain, I'm in Pennsylvania, but we're already up on our 20 minutes. We didn't get to talk about how this whole changing ARR definition impacts SaaS metrics, nor do we talk about how some of these pricing models impact the forecastability of revenue, which ARR was supposed to manage. So we got a couple more episodes in us, maybe.

We may.

I think we did touch on it. Look, to me, we could do an episode on it if you want, but the way it affects SaaS metrics is just know what you're counting, right? If your company— make sure your company has a definition of ARR that you think is good and make sure everyone understands it and make sure they understand what it's measuring. Favorite example, I've used it a lot, is Snowflake's NRR. It's a perfectly good calculation. But it's comparing trailing 12 months to the trailing 12 months before that. It is a deeply backward-looking metric. And as long as you understand that when you're doing analytics, that's all that matters in my mind. So really, it's an interpretation question. The definition question becomes an interpretation question. And then, on the other point I do think it's worth 30 seconds to talk about here, Ray, which is there's really 2 conclusions from this whole dialogue. One, get a good definition of ARR and make sure you understand it, make sure people understand it when interpreting things. And 2, get really good at forecasting. Because in the old days, if you wanted to know what ARR was, you called up legal and pulled out a pile of contracts and read them. And in the new days, you're going to call up the data science team and say, How much usage is there going to be? And we need a good forecast for what's going to happen in the coming quarter. And you may, on top of that, use as a lower bound certain contractual minimums. But the heart of the exercise is going to be forecasting.

And Dave, I don't usually do this, but on March 18th, 2021, I wrote an article that I posted on LinkedIn called APR, Annual Projected Revenue. And that's all about you need to get really good at forecasting the future if you're looking backwards at variable revenue streams.

Yeah, and to me, so I have not read that yet, so thanks for the reference. I just have 2 points on that. One, for a public company, it'll come out in guidance, right? Like, there is a way to communicate how you feel about the future in a public company. It's called guidance. RPO doesn't really solve this problem because RPO has no built-in time frames, right? So, our RPO could be 10 years out. So, it's a good metric. People should know what it is. But at the end of the day, you need a really strong forecasting team, and that did not used to need to be a competency in SaaS finance. And now it definitely, definitely does.

Yeah, well, I think it's a good place to leave, but I think we just want to reemphasize some great reference materials out there. We've got Ben Murray's LinkedIn post, Please Don't Tell Me ARR Is Dead. He has another one, which is the slides that he presented at SAS Metrics Executive Summit, which is all about defining and reporting ARR and those 167 companies he analyzed. The data's in there. We have the Notable Capital blog post, Is ARR Dead or Just Evolving? And then CJ Gustafson's post on how public companies report ARR. All good material, and we use it for source material here.

Okay, well, thanks everyone, and thanks, Ray.

Thank you, Dave.

The Metrics Brothers AI, SaaS, and More is a production of The Metrics Brothers Growth and CAC and a member of the Benchmarket Podcast Network. By accessing this podcast, you acknowledge that The Metrics Brothers make no warranty, guarantee, or representation as to the accuracy or sufficiency of the information provided Or the humor content of the jokes told. Ray, information, opinions, and recommendations presented are, according to our spouses, probably wrong and provided for information purposes only. This podcast should not be considered professional or, for that matter, unprofessional advice. We disclaim any and all liability for any direct, indirect, undirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of or God help you reliance. upon the information presented here. Ray Grothreich is based in New York City and available on X @RayReich. Dave Kellogg is based in Silicon Valley and available on X @Kellogg. Schedectady, which is French for unspellable, is not our actual production location. Thanks for listening.