Seasonality is one of the few diligence claims that is fully falsifiable from data you already have. A seasonal pattern repeats in the same month across years. If the spike appears once, it is an event, and the only question is which event.
TL;DR: Seasonality is a testable claim: it requires the same spike in the same month across multiple years. Here is how to test it, and what the four alternative explanations look like in the data.
When a chart shows an ugly month, seasonality is the most available explanation and it is often offered in complete good faith — small businesses do have quiet quarters, and a founder who has lived through two Januaries can reasonably believe January is just like that. The problem is that a single observation cannot distinguish a season from a price increase, a churned cohort, an outage or a competitor launch, and the four have very different implications for a buyer.
Four mechanisms account for most of the gap between this claim and what the raw rows show. They are not mutually exclusive and they compound.
Price rises show up as elevated churn at the next renewal, not immediately. Line the churn series up against the pricing-change history with a two-to-three cycle lag before accepting any other explanation.
A promotion or launch cohort that all signed up together will all reach their decision point together. That looks exactly like seasonality once, and never again.
Product and service incidents produce churn with a lag of one to two billing cycles. Ask for the incident history and the support-ticket volume by month, and overlay them.
If a marketplace changed its ranking, or an integration partner shipped the same feature natively, churn concentrates among the accounts that arrived through that channel. Segment the spike by acquisition source and it usually resolves immediately.
Every step below runs on a subscription-level export in a spreadsheet. None of it needs access to the seller's live billing account, which matters, because as a buyer you will not get one.
These are the thresholds we use in our own reports. They are working thresholds rather than industry standards, and the right line for a given deal depends on contract length, tenure and how transferable the customer relationships are.
| What you find | Verdict | What to do about it |
|---|---|---|
| The same month is elevated in two or more years | Green | Genuine seasonality. Model it and move on; it is a working-capital consideration, not a valuation one. |
| One elevated month, 24+ months of data, no repeat | Investigate | This is an event. Identify it before you accept any explanation, because the explanation determines whether it recurs. |
| The spike concentrates in one plan, cohort or channel | Price it in | A segment-specific event. Establish whether the cause is still present, because if it is, the rest of that segment is next. |
| The base did not recover to trend within three months | Price it in | Permanent impairment, not a season. Rebase your model on the post-spike level. |
| Fewer than 18 months of history available | Investigate | Seasonality is untestable with this much data. Treat the claim as unevidenced, not as false. |
Ask for these before the LOI. After the LOI you are renegotiating rather than negotiating, and a seller who will not produce subscription-level rows has told you something useful either way.
Illustrative. Churn runs at 3% and spikes to 11% in a single February. Seasonal, says the memo. Three years of history shows February at 3.1% and 2.8% in the other two years, so the season hypothesis dies immediately. Segmenting the spike shows 80% of it in accounts acquired through one integration marketplace, and the marketplace changed its default listing that January. The cause is external, ongoing, and the remaining accounts from that channel are the next cohort at risk. That is a completely different finding from seasonality, and it took two groupings to reach.
Whether a spike is a season or an event determines whether you model reversion or impairment, which is usually the difference between two valuations. It also determines whether the cause is still operating, which is the part that matters most: an event with a live cause is a forecast, not a historical note. Ask for thirty-six months up front; the most common reason this analysis fails is simply not having enough history to run it.
The relevant tool on this site is the churn divergence detector, which runs the arithmetic above on a file you paste in. The full method is documented in the 5-risk buyer-side method and the due-diligence checklist.
Every check on this page can be run by hand in a spreadsheet, and if you have the time you should. If you would rather not: send us the target's subscription export and we run the full human-reviewed analysis — logo churn, revenue churn, customer concentration, annual-plan decay, zombie MRR and an A–F revenue-quality grade. The free Starter tier covers one CSV per month, which is enough to check a single deal.
See a sample report → · Get the free 23-point checklist →
Compare the same calendar month across multiple years. Seasonality repeats; a one-off spike does not. With fewer than eighteen months of history the question cannot be answered either way, which is a reason to ask for more data rather than to accept the explanation.
In our experience the four most common causes are a price increase landing two or three renewal cycles earlier, a single sign-up cohort reaching the end of its natural life together, a product or support incident, and an external change such as a marketplace ranking or an integration partner shipping the same feature natively. Segmenting the spike by plan, tenure and acquisition source usually distinguishes them.
Because subscribers mostly cannot act on a price change until their next renewal. Churn therefore appears one to three cycles later, which is long enough that the connection is easy to miss and the spike gets attributed to whatever was happening in the month it appeared.