Are downgrades a revenue leak?

A downgrade is a leak when recurring revenue falls without the customer leaving. I measure it as the fall in monthly recurring value between two consecutive paid invoices of the same subscription. It is the smallest bucket in my sample, but it is the one most people never count. Whether it matters for you depends on your own numbers.

What is a downgrade?

A customer stays, but pays less. They move to a cheaper plan, remove seats, or drop an add-on. They are not a cancellation, so they do not appear in a churn number, and they are not a failed payment. The revenue still falls.

That is why I give downgrades their own bucket. Without it, a company can have flat customer counts and a shrinking base, and nothing on the usual dashboards will say why.

How do I measure it in Stripe?

For each subscription, look at its paid invoices in date order. Convert each invoice to a monthly value using its non-proration lines, normalised by period, before discounts. When the monthly value falls by more than 1% between two consecutive paid invoices, count the fall as one downgrade, valued at the amount it dropped. Sum them, then divide by the months in the window.

The details matter:

• Before discounts, so a coupon does not look like a downgrade.
• No proration lines, because they describe a mid-cycle adjustment, not the plan price.
• Seat reductions are included. Fewer seats is a lower recurring value.

The same monthly conversion is in how to calculate MRR from Stripe.

How large can this bucket be?

In my synthetic sample, for a fictional company, there were 52 downgrades worth $292 a month, compared with $1,134 for voluntary cancellations and $929 for involuntary churn. These numbers are made up. They show how the buckets sit next to each other in the layout, not what you will find. In your account the downgrade bucket may be larger or smaller, and I would not guess.

Notice that it is one of the four leaks on the landing page for a reason: it is realised revenue. The customer was paying that amount last month.

Is every downgrade a bad sign?

No. Some customers are right-sizing and will grow back. A seat reduction after a team shrinks is not something you caused. Others are a quiet step before a cancellation. Stripe shows only the numbers. It does not say why the plan changed.

So treat the bucket as a question, not a verdict. If it is small, leave it alone. If it is large, look at which plans and which timing are involved before you design a fix.

What can I do about downgrades?

I can offer a way of thinking rather than a recipe, because I do not have a sourced fix with a known size:

1. Group downgrades by plan pair, such as annual to monthly or top tier to middle tier.
2. Look for a trigger: a price change, a billing event, the end of a promotion.
3. Ask a few of the customers directly.
4. If the cause is price, a lower tier you control may be better than an ad hoc discount.

A reason-first flow can also catch some of these at the point of change. I describe it in how to build a reason-first cancel flow.

What can the measurement miss?

A mid-cycle plan change shows on the next full invoice, so the timing can shift by one cycle. A usage-based plan's invoice can fall because usage fell, which is not a plan change at all. And a customer who downgrades and then upgrades in the same month nets out, so it appears as nothing. State those limits when you quote the number.

How does it relate to cancellations?

Both are realised and both reduce the base. I value a cancelled subscription at its full monthly value, once, in the month it cancels. A downgrade is valued only at the amount it dropped. A customer who downgrades and later cancels appears in both buckets, once for each step, and the amounts do not overlap.

That is different from failed payments and involuntary churn, where I specifically avoid double counting. See voluntary vs involuntary churn.

How should I report downgrades to my team?

As two numbers and a count: the dollars per month, the number of downgrade events, and the window. For example "52 downgrades, $292 a month, last 365 days" in my synthetic sample. The count matters because a few large drops and many small ones call for different responses. Then name the rule you used, including the 1% threshold, so that a colleague who recomputes it gets the same figure.

If you change the rule later, recompute the older periods as well. Otherwise a change in the number is a change in the method, not in the business.

When would I ignore this bucket?

When it is small next to the others and your volume is low. A handful of downgrades in a year is a story about individual customers, not a pattern, and the right response is to read each one. I would also leave it alone if the drops mostly come from usage-based invoices, because there the fall in the invoice is a fall in usage and a plan-level fix will not touch it.

Where do I see mine?

In the Revenue Leak Report, as one of the four leaks in dollars per month. It is $490, delivered within 48 hours of my receiving a restricted read-only Stripe key, and it changes nothing in your account. The sample report shows the layout with synthetic data.