Revenue Intelligence
Subscription saved vs MRR recovered: two different wins
When a halted subscription comes back, future cycles resume but the unpaid invoices don't auto-charge. Saving the subscription and collecting the failed rupees are not the same number.
I used to think recovery was one number. The dashboard said "₹X lakh recovered this month" and that was the win — the bigger the number, the better the month. Then I started reconciling that figure against actual bank credits, and the math stopped agreeing. The recovered number was real. The cash was only sometimes there.
What I had been calling "recovered" was two things stacked on top of each other. And if your dashboard reports a single recovery number, you are almost certainly doing the same.
One word, two very different wins
Saving a subscription protects tomorrow's revenue. Recovering MRR collects yesterday's. They are not the same number.
Subscription saved means the customer is active again and future MRR is protected. Past MRR recovered means the specific invoices that failed were actually collected — money back in your bank account, not just future cycles preserved. You can do the first without the second. Most reporting blurs them into one figure, and that figure quietly flatters your recovery.
Why they come apart in India
Razorpay makes the gap concrete. After four consecutive failed attempts, a subscription moves to halted. When the customer's payment method works again and the subscription comes back to active, the unpaid invoices from the halted period are not automatically charged. Only future cycles resume. The subscription is saved. The failed rupees sit uncollected, waiting for a separate action that someone has to consciously take.
| Metric | What it means | How it is actually collected |
|---|---|---|
| Subscription saved | Customer active again, future MRR protected | Happens on its own when billing resumes |
| Past MRR recovered | The failed invoices themselves are collected | Needs a deliberate charge or a fresh payment link |
And on domestic Indian cards, Razorpay does not permit a programmatic manual charge of those past invoices. Recovering them means sending the customer a fresh payment link — a real, separate step, not an automatic one. If you don't take that step, the subscription is alive and the failed rupees never come home.
The reporting trap
A single blended "recovered" figure overstates one of the two. If you report saved subscriptions as recovered revenue, you are counting money that never returned to the bank. If you only count collected invoices, you understate how much future MRR your recovery flow actually protected. Both your forecast and your investor update need both numbers — separately, with attribution to whichever message or channel did the work.
The first time I asked a founder to split their monthly "recovery" figure this way, there was a long pause. They could not. The dashboard hadn't been built to separate the two, and they had been quoting whichever framing happened to flatter the month. That is not dishonest. It is what happens when the tool you use to measure something quietly conflates two different things and you trust the tool.
What to track
If I were rebuilding a recovery dashboard from scratch tomorrow, these are the four numbers I would track separately — and I would refuse to let any of them sit inside a single "recovered" bucket:
| What to count | Why |
|---|---|
| Subscriptions saved | Future MRR protected — the durable win |
| Past invoices recovered | Cash actually returned to the bank |
| Recovery time | How long the gap between failure and resolution ran |
| Channel attribution | Which message or channel did the work |
Where SubsShield fits
SubsShield separates the two by design, tracks each with attribution, and surfaces the halted invoices that still need a manual nudge — so "recovered" never quietly means "saved." It diagnoses and communicates; it does not move money.
So when you say you "recovered" revenue last month — can you split it into future MRR protected and rupees actually collected? And would your investor update survive that split?

