Are You Counting Payments as Renewals?

Enterprise SaaS has drifted to a model where many, if not most, companies do multi-year contracts on annual payment terms.  How did we get here?

  • Most enterprise SaaS products are high-consideration purchases. Buyers typically perform a thorough evaluation process before purchasing and are quite sure that the software will meet their needs when they deploy.  These are not try-and-buy or wing-it purchases.
  • Most SaaS vendors will jump at the opportunity to lock in a longer subscription term. For example, with an 85% gross retention rate you can offer a 5% discount for a two-year contract and end up mathematically ahead [1].  Moreover, with a default annual increase of 5 to 10% built into your standard contact, you can offer a “price lock” without any discount at all (i.e., the customer locks in the price for two years in exchange for a two-year commitment).

When you combine the vendor’s desire to lock in the longer term with the customer’s belief that the solution is going work, you find a fertile ground for doing two- or three-year contracts.  But these multi-year deals are almost always done on annual payment terms.

Most SaaS vendors don’t want to take the next step and ask for a multi-year prepayment.  The upside for the vendor would be to eliminate the need for collections in years 2 and 3, and eliminate the chance that the customer — even if unhappy — won’t make the out-year payments.  But most vendors refrain from this because:

  • It’s seen as an unusual practice that’s frowned upon by investors
  • Most investors believe you could better maximize ARR by simply raising more capital and sticking with annual payments
  • It can lead to lumpy renewals and cash flows that are both hard to manage and understand
  • It can lead to large long-term deferred revenues which can hinder certain M&A discussions.  (Think:  large balance of cashless revenue from suitor’s perspective.)
  • It complicates the calculation of SaaS metrics, sometimes confusing investors into believing that good metrics are bad ones. (I think I am literally the only person in Silicon Valley who is quick to point out that a 75% three-year retention rate is better than a 90% one-year one [2].)

Thus, we end up in a situation where the norm has become a two- or three-year contract with annual payments.  This begs a seemingly simple “if a tree falls in the forest and no one hears it, did it make any noise” kind of question:

Quick, what’s the difference between a one-year contract that’s renewing for the first time and a three-year contract that’s coming up for its first downstream annual payment?

I’ve often quipped that they’re both “renewals,” but in the former case they’re handled Customer Success and in the latter they’re handled by Legal. [3]

But let’s be clear, regardless of the process you use to manage them [4], they are not the same, and should not automatically be treated as such for the purposes of calculating SaaS metrics. One is the voluntary renewal of a subscription contract; the other is the payment of a contractual commitment.

If you don’t want to renew your subscription, there’s nothing I can do to force you.  If you don’t want to make a contractually committed payment I can sue you.

Let’s consider an example.  We have six customers, Alpha through Foxtrot.  The first three did one-year deals, the second three did three-years deals.  The simple question is:  what’s your gross dollar retention?  A merely acceptable 83% or a very healthy 95%?

payment renewal

If you calculate on an available-to-renew (ATR) basis, the rate is 83%.  There were 300 units up for renewal and you renewed 250 of them.  If you include the payments, the rate is 95%.  1,050 units were up for renewal or payment, and you invoiced 1,000.

This is a case that feels a little bit wrong both ways.  Including the payments uplifts the rate by mixing involuntary payments with voluntary renewals; to the extent you want to use the rate as a satisfaction indicator, it will be over-stated [5].  However, excluding the payments seems to fail to credit the company with the auto-renewing nature of multi-year deals.

One thing is clear:  payments certainly cannot be included in any ATR-based rate.  You cannot view making a contractually required payment as the same thing as voluntarily renewing a contract. 

Because of prepaid multi-year deals, I have always calculated retention rates two ways:  ATR-based and ARR-based.  The former is supposed to give you an idea of how often, given the chance, people want to renew their contacts.  The latter is supposed to show you, mathematically, what’s happening to your ARR pool [6].

I have an issue, which is highly subjective, when it comes to out-payments on non-prepaid, multi-year deals:

  • On one hand, I can argue they are contractual commitments that the vast majority of customers will honor and thus are effectively – save for a few rare cases – identical to prepaid multi-year deals. Think:  the money’s good as in the bank.
  • On the other hand, I can argue that a dissatisfied customer – particularly one who blames the vendor and/or the software for their failure – will not want to pay, even if the contract says they’re supposed to. Think:  it’s a toothless contract that the vendor will not likely not enforce against an angry customer.

Philosophically, I can argue that these out-year payments are either “good as in the bank” or I can argue that they’re “basically renewals that will ‘churn’ if the customer is not happy.”  The first argument says to treat them like prepaid multi-year deals and put them in ARR-based retention rates.  The second argument says they’re effectively voluntary renewals and should be counted as such.

In reality, you need to know what happens at your business.

I believe for the vast majority of businesses, customers honor the contracts and we should treat them like prepaid, multi-year deals in ARR-based rates — and you should always publish in parallel ATR-based rates, so people can see both.  However, if your company is an outlier and 10% of those payments are never collected, you’re going to need to look at them differently – perhaps like renewals because that’s how they’re behaving.  Or get better lawyers.  Or stop doing non-prepaid, multi-year deals because, for whatever reason, your customers are not honoring the commitment they made in exchange for you to give them a price lock.

# # #

Notes

[1] Over 2 years you get 190 units versus an expected 185.  (Not counting any expansion.)

[2] 0.75 > 0.9^3 = 0.73 – you need to compound annual rates to compare them to multi-year ones.

[3] Or, really, Accounts Receivable but that doesn’t sound as funny.

[4] I’d argue that when you define your customer success process that you should treat these two customers identically.  Whether it’s a payment or a renewal, in a good customer success process you should constantly monitor customer progress with the hope that the renewal (or the payment) is not some big decision, but merely incidental.  (“Yes, of course, we want to keep using the software – is it just a payment year or do we need to renew the contract?”)  This might increase your cost to renew a bit – because you’ll be paying CSMs or renewals reps to do collection work that could theoretically have been done by Accounts Receivable – but it’s still the right answer if you want to maximize ARR.

[5] While payment does not necessarily indicate satisfaction, it probably does indicate the absence of intense dissatisfaction.

[6] e.g., I’d use the the churn rate (1 minus the retention rate) as the discount rate in a present value calculation.

12 responses to “Are You Counting Payments as Renewals?

  1. Amazing entry as usual!

    I’d love to hear your input on these 2 follow up questions, under the same premise of ATR based renewal estimation:

    1. What about the possible upgrades/cross sells that happen during the renewal process? How are they to be considered or measured
    2. Considering question 1, What’s the impact of Renewals estimation based in ATR, having upgrades or crossells at the moment of renewal, for a rough lifetime value estimation of that customer (a health check per accounts over the years)?

    • ARR expansion (e.g., price increase, upsell) should be booked when it happens, should be included in the *denominator* for the renewal/CS team’s goals (think of ARR like a one-way bezel), but should be in the numerator for cohort-based retention rates. See also https://kellblog.com/2016/12/27/a-fresh-look-at-how-to-measure-saas-churn-rates/

    • I’m less enthusiastic about LTV than I used to be because so many companies now have 100%+ net retention rates that means, technically, that LTV is infinite. So you’re starting to see companies run the calculations that use the real LTV calc when you can and, when infinite, insert an arbitrary cap. I don’t like that. I think LTV/CAC still makes sense of a gross basis, but it’s hard to argue it does on a net one.

    • 1. expansion of any form that offsets churn is the difference between gross dollar retention (before expansion) and net dollar expansion (churn offset by expansion). 2. to the extent that most net dollar expansion rates are above 100% these days (and more like 120% than 102%) they make LTV calculations meaningless because the LTV goes mathematically infinite. most folks then just assume some arbitrary duration (e.g., 10 years) in that case for calculations. i try to avoid a metric that includes that sort of arbitrary cap.

  2. This blog post spot on and points out some mistakes I (and others I work with!) made along the way in calculating churn, LTV and CAC. Keep it coming.

  3. Thanks for the article! A quick question:

    In your example for the customers who agree to a multi-term deal, is the 200, 250, and 300 their ARR (the revenue that will be recognized annually)? Or is that the total contract revenue that will be collected over 3 “terms”? If those terms are years, should those values be divided by 3 to calculate ARR?

    • Those numbers are all in a column called ARR, annual recurring revenue, and yes the revenue you get from each one each year. TCV = ARR * contract-years. If the contract is prepaid you could say NSB (new subscription bookings) = ARR * prepaid years.

      • Thanks!

        A related question regarding the industry standard in computing ARR for a multi-year contract with escalating payments. Eg. Three year contract valued at $330 with payments of $100, $110 & $120 in years 1 – 3 respectively. Is ARR computed as $110 at each point in each of the 3 years or is ARR computed based on the value for each distinct period ($100, $110 & $120 in year 3)?

      • I’m not sure as, while I like finance topics, this one’s right on the edge of my limit. Also, the reason I don’t know if you’d want to structure it so it shows up as expansion ARR (which everybody loves) in year 2 and year 3. Not sure if/how the accountants will attempt to defeat that, but that’s the outcome you should shoot for, imho.

  4. Dave- been reading your blog for a while now…particularly useful/insightful as an ibanking analyst. Apologies that my comment doesn’t relate to this post.

    I’m currently working on an investment pitch of a public $5 billion cybersecurity company with SaaS based business model. I’m working on forecasting next 5 years revenue growth and was wondering methods I would use to forecast.

    Should I be using a top-down approach – TAM * market penetration * # of companies, etc.. Or should I use another method by trying to forecast billings and apply a % growth every quarter. Or if I were to use billings, I can forecast revenue and deferred revenue, which again begs the question of what method to use to forecast those numbers.

    I’m stuck and would appreciate your advice on public Saas company valuation. Thank you for your time.

    • Primary use of top-down metrics is to conclude: HUGE MARKET, LOTS OF RUNWAY, ETC. Very hard to do anything credible, bottom-up about future quarters in that way imho.

Leave a Reply to Brian Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s