This post won’t save your life, or your company. But it might save you a few precious hours at 2:00 AM if you’re working on your company’s SaaS metrics and can’t foot your quarterly and annual churn rates while preparing a board or investor deck.

The generic issue is a lot of SaaS metrics gurus define metrics in a generic way using “periods” without paying attention to some subtleties that can arise in calculating these metrics for a quarter vs. a year. The specific issue is, if you do what many people do, that your quarterly and annual churn rates won’t foot — i.e., the sum of your quarterly churn rates won’t equal your annual churn rate.

Here’s an example to show why.

If I asked you to calculate the annual churn rate in the above example, virtually everyone would get it correct. You’d look at the rightmost column, see that 2018 started with 10,000 in ARR, see that there were 1,250 dollars of churn on the year, divide 1,250 by 10,000 and get 12.5%. Simple, huh?

However, if I hid the last column, and then asked you to calculate quarterly churn rates, you might come up with churn rate 1, thinking churn rate = period churn / starting period ARR. You might then multiply by 4 to annualize the quarterly rates and make them more meaningful. Then, if I asked you to add an annual column, you’d sum the quarterly (non-annualized) rates for the annual churn and either average the annualized quarterly rates or simply gray-out the box as I did because it’s redundant [1].You’d then pause, swear, and double-check the sheet for errors because the sum of your quarterly rates (10.2%) doesn’t equal your annual rate (12.5%).What’s going on? The trap is thinking churn rate = period churn / starting **period** ARR.That works in a world of one-year contracts when you look at churn on an annual basis (every contract in the starting ARR base of 10,000 faces renewal at some point during the year), but it breaks on a quarterly basis. Why? Because starting ARR is increasing every quarter due to new sales that aren’t in the renewal base for the year. This depresses your churn rates relative to churn rate 2, which defines quarterly churn as churn in the quarter divided by starting-**year** ARR. When you use churn rate 2, the sum of the quarterly rates equals the annual rate, so you can mail out that board deck and go back to bed [2].

**Available to Renew (ATR-based) Churn Rates**

****While we’re warmed up, let’s have some more fun. If you’ve worked in enterprise software for more than a year, you’ll know that the 10,000 dollars of starting ARR is most certainly **not** distributed evenly across quarters: enterprise software **sales** are almost always backloaded, ergo enterprise software **renewals** follow the same pattern.

So if we want more accurate [3] quarterly churn rates, shouldn’t we do the extra work, figure out how much ARR we have available to renew (ATR) in each quarter, and then measure churn rates on an ATR basis? Why not!Let’s first look at an example, that shows available to renew (ATR) split in a realistic, backloaded way across quarters [4].

In some sense, ATR churn rates are cleaner because you’re making fewer implicit assumptions: here’s what was up for renewal and here’s what we got (or lost). While ATR rates get complicated fast in a world of multi-year deals, for today, we’ll stay in a world of purely one-year contracts.Even in that world, however, a potential footing issue emerges. If I calculate annual ATR churn by looking at annual churn vs. starting ARR, I get the correct answer of 12.5%. However, if I try to average my quarterly rates, I get a different answer of 13.7%, which I put in red because it’s incorrect.

Quiz: what’s going on?

Hint: let me show the ATR distributed in a crazy way to demonstrate the problem more clearly.

The issue is you can’t get the annual rate by averaging the quarterly ATR rates because the ATR is not evenly distributed. By using the crazy distribution above, you can see this more clearly because the (unweighted) average of the four quarterly rates is 53.6%, pulled way up by the two quarters with 100% churn rates. The correct way to foot this is to instead use a weighted average, weighting on an ATR basis. When you do that (supporting calculations in grey), the average then foots to the correct annual number.

**Notes**:

[1] The sum of the quarterly rates (A, B, C, D) will always equal the average of the annualized quarterly rates because (4A+4B+4C+4D)/4 = A+B+C+D.

[2] I won’t go so far as to say that churn rate 1 is “incorrect” while churn rate 2 is “correct.” Churn rate 1 is simple and gives you what you asked for “period churn / starting period ARR.” (You just need to realize that the your quarterly rates will only sum to your annual rate if you have zero new sales and ergo you should calculate the annual rate off the yearly churn and starting ARR.) Churn rate 2 is somewhat more complicated. If you live in a world of purely one-year contracts, I’d recommend churn rate 2. But in a world of mixed one- and multi-year contracts, then **lots** of contracts are in starting period ARR aren’t in the renewal base for the year, so why would I exclude only some of them (i.e,. those signed in the year) as opposed to others.

[3] Dividing by the whole ARR base basically assumes that the base renews evenly across quarters. Showing churn rates based on available-to-renew (ATR) is more accurate but becomes complicated quickly in a world of mixed, multi-year contracts of different duration (where you will need to annualize the rates on multi-year contracts and then blend the average to get a single, meaningful, annualized rate). In this post, we’ll assume a world of exclusively one-year contracts, which sidesteps that issue.

[4] ATR is normally backloaded because enterprise sales are normally backloaded. Here the linearity is 15%, 17.5%, 25%, 42.5% or a 32.5/67.5 split across the first vs. second half of the year (which is pretty backloaded even for enterprise software).

[5] The spreadsheet I used is available here if you want to play with it.

*This article originally appeared on **Kellblog**.*

Dave Kellogg is a technology executive, investor, adviser, and blogger. From 2012 to 2018, Dave was CEO of cloud enterprise performance management vendor Host Analytics, where they quintupled ARR while halving customer acquisition costs in a highly competitive market, ultimately selling the company in a private equity transaction. He was SVP/GM of Service Cloud at Salesforce and CEO at NoSQL database provider MarkLogic, and CMO at Business Objects for nearly a decade. Dave started his career in technical and product marketing positions at Ingres and Versant.