CARR, ARR, and the Impact of Usage-Based Pricing

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

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

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

And together we are the Metrics Brothers.

And we go together like SaaS and ARR, Ray.

Now that's a pairing that I can easily understand, and it doesn't make me hungry, Dave.

That's good. Trying to get away from the food metaphors, as you know. But not so fast. Even with something that seems as simple as ARR, we're going to discover there's a lot of nuance on how to calculate it and its cousin CRR.

Spot on there, CAC. ARR is not a FASB GAAP standard metric, and it's especially not standardized in the SaaS industry with those companies using things like usage-based pricing.

Yep, I think it's gonna be a great topic for today's episode. I think we're gonna touch on what is ARR itself, what does the second R in ARR mean, uh, and then how do we think about ARR in the usage-based model, which is really actually quite difficult, uh, as we'll discover in this episode. But before we Before we dive 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 Groth Wright 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 @Kellogg and Ray on LinkedIn @RayReich. Thank you so much for listening to the Metrics Brothers podcast. Okay, Dave. So, as we were prepping for today's episode, right, we don't have 100% common agreement or alignment on what ARR definition is today, let alone tomorrow. But let's start with A couple definitions that I know I had worked on at the SAS Metrics Standards Board as a starting point. Sound good?

Fire away.

So the SAS Metrics Standards Board came up with 2 definitions of ARR-related terms. Number one was CARR. Some people refer to that as committed ARR. We called it the contracted ARR. And the definition was, It's really the contracted annual recurring revenue, whether it's in production or not yet in production. So we closed it this month, but it's not going into production for 3 months or so. So that was contracted. And then annual recurring revenue was basically as you define it in your revenue policy at your company, calculated on an annual basis. And it's really the sum of your subscription recurring revenue on that annualized basis. And it should not include one-time fees or professional services fees, even if they are recurring. So at a high level, that's how we defined it. What say you?

Well, a couple of things. So the first point, CARR, I understand and actually agree with your definition that we sometimes need a distinction between what we've booked And what's actually started, right? So I book it in July, but the start date's October. Well, I've got a gap where it doesn't really belong in ARR, but, but what do I do with it? So people put it in CARR. Personally, as a former CEO, I like to minimize that gap. I have a bookings policy that says I won't take it as a booking unless it's 90 days or less to the start date. And boom, I don't need CARR because it just means ARR means either active live in the pool or coming online in 90 days. So when I was a CEO, We sidestepped it because while I'm okay with your definition, I don't love having the metric. And I know at some companies you have to have it. So if you have to have it, your definition's good and you're touching on the issue, which is, are they live or not?

Yeah.

ARR. My quibble with your definition is you're saying ARR is not a GAAP metric, which I agree with. And you're saying as defined by your RevRec policy, beep, beep, beep. So I feel like you kind of passed the buck here. I'll lay out my objections and let you do it. But, but I don't think you actually define it. My favorite, just to give you shit, at one point you define ARR as 12 times MRR and then don't define MRR. I caught you on that one, Ray. Uh, but, but in any case, I agree with you, that's the sum of the annual subscription revenue. I agree that it excludes one-time fees. Professional services, we're going to go back to definitions again. If I buy platinum support, I would argue that what you're going to say, that's not professional services, probably. Um, I'm going to say it's services, it may not be professional, uh, but I would say platinum support which is really not a software subscription, but a kind of human subscription, does belong in ARR. And I'm not actually sure from your definition if you agree.

Yeah, so I'm going to go, and this is Ray Reich's opinion now, I'm not speaking for the SAS Metric Standards Board, that it starts with how do you build your chart of accounts for your income statement. And my belief is you have a subscription, software subscription line item, You have a variable subscription line item, which is revenue that is driven from usage-based pricing type components in the subscription agreement that you sign. And then you have professional services. Now, if you have recurring professional services, Dave, I would do the same thing. I would have recurring professional services revenue and then variable professional services revenue.

Sounds complicated. Okay, that's interesting. So in my experience, most people don't do it that way. I'll just tell you my experience where we live in different worlds. Our worlds collide at times, but we live in different worlds. In my world, most people don't break the subscription from the variable. They might for internal reporting, but not on a P&L, not in the chart of accounts. I don't, maybe in the chart of accounts, but when I look at their P&L, it just shows subscription revenue or product revenue, right? Snowflake, I mean, one of my favorite quotes is the words, the Snowflake S-1 has the word recurring revenue exactly zero times. Right, they just call it product revenue. Um, so that split I think is reasonable. I just don't know many companies that do it in their public reporting. You may show me some and I'll be happy to learn. I, by the way, I get where you're coming from. I don't think you're insane to come from there, but, but, but I get it. On PS, that's the one I'm going to disagree. I think platinum support is subscription, and, and most of the companies I work with would put it into ARR and they would put it into subscription revenue.

So a couple things. So sometimes I'm guilty of trying to talk about where the market's going versus where it's been. And let me tell you what I mean by that, Dave. So ARR was in the subscription model where a company said, I got a 1-year agreement, I'm paying $100,000 for 100 users. I'm making the numbers up, right? That was easy to know.

Pick 120, it makes it easier to divide by 12, but go ahead.

So you knew what your ARR was. annual subscription commitment was. So as an investor, it's like, oh, you have 100 of those companies. I'm pretty confident if you have a history of retaining 90% of those, I know the baseline next year to start with. And then the growth is easier because I'm starting at a baseline of 90% of what I did last year. So that was the value of ARR and subscription business model. You agree, Dave?

Um, I'm not sure. I mean, certainly ARR came from an annual subscription model of a fixed contract. Yes. So I could agree on where ARR ARR came from, yes.

So, and that's been for 20-some years now. Now, in the last few years, usage-based pricing is becoming a more popular way to price your product. Snowflake's a great example of that. Reduce the friction, you have hyper land and expand. My belief is that is going to continue to become a more and more popular pricing model. So going forward, less percentage of your total revenue is going to be contractually committed and truly recurring, and more of it's going to be variable in nature, which is based upon usage. And as CJ Gustafson— you, you brought this up— calls recurring, it's not guaranteed to be here over the next 12 months, but it's going to reoccur based upon usage of the software, which is why I believe even at an income statement level We should start seeing more companies doing subscription revenue and variable revenue.

Yeah, look, I think companies are going to track it internally. I'd be surprised if people break it out externally. For a public company to break that out means one thing: you're going to ask a ton of questions about it, and they don't like tons of questions. I think Snowflake, you know, as the kind of number one fan-loved usage-based pricing company, never broke it out. And as mentioned, they never even mentioned subscription revenue. I think they literally call it product revenue. And they're just like, we're not going to tell you which it is. And by the way, the other thing I think you're breaking, Ray, is, is you're assuming a model that says baseline plus overage, roughly conceptually. That's what you're saying. There's some baseline commitment and then there's overage. But what do you get to these points-based consumption models where you buy 30,000 points and you get to use them over the next 18 months? And do you have rollover credits or not? And, and, right, all of a sudden that's not that model, right? Or let's just do an AI, an outcome-based model where I saved you 10 SDRs. So you're going to pay me, you know, a quarter of savings you reaped. So, so I want to argue that the model you're going to— you may be one step ahead of the market. I'm going to argue if you go 2 steps ahead, you might end up going, oh my God, this is a sea of complexity. And we're— which is my point of view, which is, hey, we're just going to report what people spent, which is what I would call the snowflake perspective.

So this is what I love about doing these episodes, because it makes me think and hopefully allows our audience to think about this, right? Because you mentioned, I don't see people reporting that in their public financial statements. 100% agree. But for internal reasons, as an operator, Dave, if I've introduced a new usage-based pricing model, I want to know over time how my contractual commitments tracks versus variable usage. So if this year I had $10 billion of Contractual recurring revenue, and I had $30 million of variable usage-based revenue, I may incent my sales organization, go turn out of that $30 million of variable usage into $10 million more of contracted recurring revenue. So now I'll have 20 and 20, which I have more predictability in the future. So that's why I think it's valuable as an operator's perspective.

Yeah, look, if you have a pricing model, I mean, to me, Ray, the job of the pricing model is to translate usage into Invoices, right? That's what a pricing model does. Um, you're going to use our service— like, the input is your usage of our service and the output is a bill. Um, and if your pricing model has a baseline plus an overage fee, you absolutely are going to want to track how much is coming— you will track how much is coming from which and how to optimize the pricing model to maximize the bill. Um, so I don't disagree with you there. I do think it just comes down to what we're gonna report. And I guess what I'm doing, Wei, is I'm putting the work on the pricing model to say, yeah, there's an incredibly complex pricing model conversation about how we decide, given a customer and their usage, how much do we bill them? But I think that's gonna be solely internal. So maybe we're agreeing here that that's gonna be internal stuff. And the outside, we're just gonna say, this is how much people paid to use our product last quarter, which itself creates a lot of problems about, well, is that recurring or not? And by the way, why do we wanna call it recurring? And why do we have this debate about recurring? versus recurring in the post that CJ talked about. Do you want me to comment on that or do you want to do it?

Yeah, I think you have a great insight on this, Dave.

So first, here's my first insight. A guy walks into a bar and orders a martini for $7— is it $17? Sorry, sorry, it's not 1980s. Uh, $17 martini, um, is it MRR? And you might think it's a crazy example, right? Like, what— how could a martini possibly be MRR? And if I say, Ray, that guy's a regular, he's come in every Tuesday for the last 2 years, orders one martini and leaves, and I have no no reason for me to stop. Well, that looks a lot like monthly SaaS. A monthly SaaS subscription is exactly that. Every month I choose to hit renew and pay your invoice, right? So it's the same thing as the guy going into the bar, right? If the guy's an out-of-towner or a tourist, no. If I just ask him, where are you from? He goes, Cleveland, I'm here for business convention. No, it's not RMRR, it's other revenue, which we need a line item for.

I agree.

Say it's a club. I didn't tell you that, but it's a club where you have to have an annual membership fee Right. And you get food and beverage credits. Okay, well, then it's probably ARR, not MRR, because they're paying an annual subscription to be a member of the club. And this guy's burning down some of his credits, right? Because most, most clubs like that will have a food and beverage minimum. So I like to start with that example for 2 reasons. One, it takes an incredibly simple example. It's a guy walks into a bar and orders a drink. Is it MRR? And it starts to shed light on this question of recurring versus reoccurring. And the insight— I'll try to say it really short, Ray. In the beginning, I honestly believed that recurring meant might renew, because we were coming in a world of perpetual software. Business Objects, we'd sell a million-dollar deal, and we were never going to get license fees from them again. We'd get our maintenance, but they were done. And then Benioff came along and said, hey, what if we did this first on a monthly, but then on an annual basis? So at the end of every year, somebody had to renew if they wanted to keep using the software. So that is what CJ would call recurring. It was not contractually bound, but the possibility that they would—

Right.

was to me what made it recurring as opposed to perpetual. To just finish the swamp of confusion here, I think CJ would call recurring if I took that 1,200-unit contract. Notice the sleight of hand here, Ray, always pick something divisible by 12. If we took the 1,200-unit contract and said that's 100 a month, that's what CJ would call recurring. But I think it's the exact opposite of SaaS history. So I'm gonna defer to CJ 'cause I think he represents the mainstream view and that's where the market's going, that recur means contractual. Recurring means might happen, but I just need to point out that that's not where it all started.

No, that's a good point. And thank you for taking me down history lane there. I have a couple other things I gotta go back to. And, you know, we've talked about this, and I try to be careful the way I position it, but I grew up my first 8 years in a recurring software license model.

Thank you for not saying timesharing.

And we had a lot of 7 and even 8-figure contracts. And here's what we had to do. We had to use the variable component, the usage-based pricing component, as an input to next year's forecast. So you couldn't just say we had 1,200 units of revenue from them last year. You had to say I had 1,200 units of revenue, of which 600 was contractual and 600 was variable based upon usage. And then we had to forecast how much variable usage and associated revenue we would get the next year. Were they adding more users or more products or more— their business was increasing 20%, so our revenue. So the reason I think splitting out variable from contractual is also for forecasting and guidance in the public markets, Dave.

So I think it's super important, Ray, that you bring that up. So first, if you get old enough, you get to live through the cycles on this stuff. And Ray grew up in timeshare. I did not. And timesharing was all about variable pricing, right? So he has actual real-life experience back in the prior generation approach. And what you're saying is perfectly clear to me that, yeah, I could say that customer A gave me 1,200 units last year, but it was actually split 600, 600, and I'm gonna forecast them differently. Like, say we get a 5% contractual uplift on the base, so that's gonna go to 630, and then we're gonna make a real forecast based on usage of what the other 600, the variable 600, is gonna become. And we're going to do that for planning first, right? We're going to make a board plan. We're going to do it for guiding Wall Street, which to me comes after planning. So I think it— look, I'm not against— if you've got a pricing model with base and overage, I am absolutely 100% in favor of analyzing that, right? And I think it's hard. And I think my favorite example is where you actually generate churn by saying, you know what, Ray, had you bought the $900K package, you only would have had $200K in overage, so it only would have cost you $1,100K last year. You actually paid $100K too much. And now I've generated $100K in churn. I've had help the customer, right, arguably exposed a flaw in the pricing model. I don't know if that happened. Did that actually happen back in the day?

It did. And so, here's what we did. So, 2 things. We incented salespeople to get a contractual commitment at about 70% to 75% of last year's total spend. So, number one, we had a 25% buffer. Number 2, right, we actually gave a one-time overage rollout—

rollover.

So, if you entered a new higher contractual commitment, If you did not use all of your variable units, we would roll over unused for the next agreement year. That's how we dealt with it.

Yeah. And that creates forecasting troubles as well. I understand it. But my main point is this shit gets complicated fast. And that's a real example of what I think people will do and have been doing. So why don't we go back to the script right here? And why don't you talk about the 2 things you want to talk about? I have one more point, but I'm gonna let you go first.

Well, I think my concern regarding taking variable usage, so recurring, and stuffing it into our classic definition of annual recurring revenue is it creates false expectations of what's going to happen in the future. And the reason I mentioned that in 2022 and 2023, when we saw the correction in the cloud industry, Those companies with usage-based pricing reduced their growth rate almost by 50% in the first 9 months of the correction because customers could just turn it off. They could just stop using it as much. The subscription with true contractual commitments, their growth rates didn't start going down for until about 9 to 12 months after the correction because their customers were legally locked in. So that was one of my concerns about putting variable in contractual. It makes it hard to predict based upon changes in usage environments.

So a couple of things, right? I have a bunch of— that's one small point. I have 5 minutes of material. I'll try to go fast. So first, what I'm hearing you say is you prefer forecasting to analyzing, right? You're basically saying, hey, that variable, we should forecast it. We shouldn't just annualize it and go, it was last year this, next year it's gonna be that. We should actually make a forecast. I hear you. Makes sense. I would argue that most people's kind of proxy ARR metric, you've got 5 companies on the screen. Who knows if we'll get to them? They're annualizing and they're just taking a month and multiplying by 12 and calling it ARR. And you're actually saying, I prefer forecasting, and I agree with you. But most people today who run variable models take a month, some month, who knows which month, and they multiply it by 12 to go, that's ARR. And maybe they'll split variable from base. I don't know. A lot of them don't. A lot of them just take total spend and annualize it.

Yeah.

The last point— sorry, I have one last point because I think it's super funny— is to me, when the downturn— oh, 2 things. Sorry, Ray, 2 points. One, when that growth deceleration happened, because I think we're thinking of the same study, UBP companies got hit harder, but they were still growing faster, right? So they actually hit harder, but even after all was said and done, their growth rates were actually faster than subscription companies. Interesting. Um, and then the other one, to me, even on the subscription side, I always say there's 2 types of CROs, and this is purely tactical. There were CROs who did a 3-year deal and built in NRR, and those that didn't. And when the downturn hit, you figured out which kind of CRO you had, because a lot of companies are like, we're fine, Tim took care of us. This guy's on a 3-year deal and we tilted the ARR, so NRR is gonna be fine. And a lot of them were like caught naked going, oh, we're only on 1-year deals and they've dropped their usage. Holy cow, what do we do?

So going back to those examples, I just wanna highlight a couple real quick. Datadog, right? One of the best usage-based pricing, great NRR. They say, we calculate ARR by taking the monthly run rate revenue, Or MRR and multiplying that by 12. So that's how they get ARR. And it includes both contractual and just usage-based variable. MongoDB— Everything.

Go ahead. So everything all in there, they're doing base plus variable, or what do you call base again? You have variable and what's the other one you call it? Subscription.

It's a contractually committed.

Okay. Subscription. I'm calling it base plus variable. Ray was calling it subscription plus variable.

All right.

But they're taking base plus variable, multiplying by 12. I do think it's interesting that they're not saying which month, because, because the spend across months in a quarter could vary sometimes quite a bit. But, but, but keep going. I'm sure it's hopefully somewhere in the 10-Q it says that.

MongoDB says, okay, I'm not going to just take 30 days because maybe, you know, pricing is too variable. I'm going to take the prior 90 days of their actual consumption, and then I'm gonna Um, annualize that. So previous 90 days of variable usage times 4, that's how I get my annualized recurring revenue, or annual recurring revenue.

12 times the last month versus 4 times the last quarter, basically. But this is— these are all based on trailing spend, and they're all all-in metrics, right? Base plus variable. Keep going.

So I, I don't—

I—

because we're running up on time, I don't think I'm going to do a lot more, David. But I think here's my problem. I think annual recurring revenue used to mean subscription in my brain. ARR that is based upon both contractual and variable is not a subscription. It's not a contractual commitment. And that's why I think it should not be included in ARR, even though 78% of private SaaS companies with usage-based pricing include variable usage in their ARR calculations.

Yes. So, so look, what's going on here, Ray, is pretty simple. SaaS grew up in a world of annual recurring revenue. We created a bunch of really important metrics like LTV to CAC that are based in ARR. So you, if you want to do SaaS metrics, you need to have an ARR number to plug into the formula. But the issue is these companies have lost the original model, and there's nothing wrong with that. And they're doing a mix of baseline plus usage or per usage or whatever, and they're creating what I call a proxy for ARR. Most people create a proxy by annualizing something, right? And you can annualize a quarter, you can annualize a month, um, it depends. And when you do that, you are mixing— by annualizing something, you're analyzing spend, which can be a mix of both baseline and variable, and then multiplying by 12. So I agree with you on the problem statement. Um, I'm not sure we agree on the solution. I don't think the solution is to expose the difference between the two. I think that's getting too much into a company's dirty laundry. I, I just think what it— I mean, I don't have a great answer, Ray. I just think people are going to continue to annualize. trailing spend. They have to be careful for seasonality, right? Because Host Analytics— I sold a planning system, it got used a lot in Q4. And if I want to go ARR as 4 times 4th quarter, that's going to be a lot bigger than next year, I can tell you that, right?

And believe it or not, I mean, that's what public company analysts do. That we have this metric called implied ARR, and it's the last quarter of subscription revenue, however we define that, times 4. To your point, hosts would look great one quarter a year, right?

Yeah. I mean, basically, yes. Because if you're annualizing a high usage month, the host didn't have usage-based pricing. Maybe this is why for some companies. But if you have a highly seasonal model, maybe you do trailing 12-month spend, frankly, which is how Snowflake calculates NRR, using trailing basically month 24 to 12 versus month 12 to present day. So look, I think we've agreed on the problem statement. And I think ARR is elusive. I think we know why. Ray sees a world, which I think is going to be true internally, which is splitting base from variable and doing a lot of analytics about how to make the pricing model optimize outcomes. I, looking more from the external perspective, I'm like, people aren't going to break this out. They're not going to want to get into this with financial analysts on earnings calls. So I doubt people will break it out. I mean, look, Ray, for a long time, companies didn't even release ARR. That's why we have implied ARR, by the way. Why did implied ARR come into being? Because companies didn't release ARR. So we had to kind of proxy it.

Well, Dave, maybe we're going to have to change our nicknames and I'm going to have to become Mr. Insider and you have to become Mr. Outsider.

There we go. There we go.

Okay. Hey, thanks for that great summary and thank you for discussing this topic with me.

Thanks, Ray. See you next week.

The Metrics Brothers AI, SaaS, and More is a production of The Metrics Brothers Growth and CAC and a member of the Benchmarkit 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.

Ahem, 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, indirect, misdirect, incidental, special, ordinary, consequential, inconsequential, or other damages arising out of any use of or God help you rely 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.