Product & Activation · 3 min read

The 1,361-Account Reality Check: Why a Smaller MRR Number Can Make Your SaaS Faster

An MRR chart can look healthy while customers are already leaving. That is not a dashboard bug. It is often a timing choice. In 2025, Buffer changed how it counted cancelled annual subscriptions. It…

← All articles

An MRR chart can look healthy while customers are already leaving.

That is not a dashboard bug. It is often a timing choice.

In 2025, Buffer changed how it counted cancelled annual subscriptions. It removed 1,361 inactive legacy annual accounts and began treating cancellation as churn when the customer cancelled, rather than waiting for the subscription’s renewal date. The company expected a roughly $14,000 monthly recurring revenue reduction. Its reported July MRR was later revised from about $1.93 million to $1.84 million.

The headline is not that a lower revenue number is good. The useful lesson is that a slower, friendlier-looking number can delay the product work that matters most.

Renewal-date churn hides the learning window

When an annual customer cancels in January but remains paid through December, the cash is still real. Their renewal is still not coming.

If the cancellation is invisible in retention reporting until December, the team loses eleven months of feedback. Marketing may continue spending to replace a customer who was already gone. Product may keep prioritizing a feature that did not solve the reason they left. Leadership may mistake remaining contract time for customer confidence.

You do not need to choose one number and abandon the other. You need to label them honestly.

Keep three views of customer revenue

1. Contracted revenue

This answers: “What is paid or committed through the current term?” It matters for cash planning.

2. Retained revenue

This answers: “What revenue is still expected to renew?” Remove accounts as soon as they cancel, even if access remains active until the end of their term.

3. At-risk revenue

This is an early-warning view. It includes accounts that have requested cancellation, reduced use, failed activation, or raised a repeated unresolved problem. It is not a prediction with false precision; it is a work queue.

The value of these views is not perfect forecasting. It is faster conversation between finance, support, and product.

Turn cancellations into product evidence

The cancellation form should not be the end of a relationship. It should trigger a short review.

For every meaningful cancellation, capture the account type, the first moment where value stalled, the stated reason, and the action the team will take—or choose not to take. A reason like “too expensive” is usually not enough on its own. Was the product underused? Did a key teammate never activate? Did the customer replace one workflow or the entire tool?

Group the notes monthly. If five accounts mention the same setup barrier, do not merely label it “onboarding.” Read the actual language and watch where the path breaks.

A small operating rule

Set one rule: a cancellation that fits your target customer profile must be visible to the product owner within seven days.

That does not mean every cancellation becomes a roadmap item. It means there is no long delay between an important signal and a decision. Some patterns will lead to a product change. Others will improve qualification, pricing, documentation, or expectation-setting.

The trade-off is worth seeing

More honest retention reporting can make a monthly chart look worse before anything improves. That can be uncomfortable, especially when a team is fundraising or planning a launch.

But delaying the truth does not preserve retention. It only postpones the work. A smaller, more accurate number is easier to improve because it tells you where to look.

Quick checklist

  • Count cash and expected renewals as different views.
  • Mark cancellation when the customer cancels, not only when their card stops charging.
  • Create a simple at-risk queue.
  • Review cancellation language monthly with product and support together.
  • Turn one repeated problem into one clearly owned experiment.

Source: Buffer’s explanation of its MRR and ARR reporting change.

The discussion

Add your perspective

Keep it useful and specific. Your email address is never published.

Still building?

Get the next useful signal in your inbox.