Subscription billing and dunning: the first 90 days

In our experience with Indian SaaS billing books, 6-9% of recurring charges fail on the first attempt in a normal month, and closer to 12-15% when the customer base is SMB-heavy. Each failure starts a quiet countdown: the customer keeps using the product, finance keeps waiting for money that will not arrive, and nobody owns the gap between "charge declined" and "subscription cancelled." That gap is involuntary churn, and the first ninety days of fixing it follow a fairly predictable shape.

The first 30 days are discovery, not recovery

The first month is mostly about finding out how much was already leaking; teams typically recover 20-30% more failed payments just by instrumenting what already happens.

Pull ninety days of decline data out of your gateway — Razorpay, Cashfree, PayU, Stripe India, whatever holds your book — and classify every failure: insufficient funds, card expired, mandate revoked, issuer downtime, authentication not completed, technical. Two things usually surprise people. Technical failures (timeouts, malformed requests, expired tokens) are often 5-10% of the total and are fixable in code. And the largest single bucket is almost always insufficient funds, which means the fix is timing and retries, not persuasion.

Indian subscriptions fail differently from US ones

Indian recurring billing breaks in ways a US dunning playbook misses, because RBI's e-mandate rules and Indian bank behaviour shape what you are allowed to attempt.

The ones that bite:

• A pre-debit notification must reach the customer at least 24 hours before each charge. A retry is a fresh debit, so it needs its own notification — that caps how fast you can re-attempt.
• Recurring card charges above ₹15,000 need an additional factor of authentication. A ₹45,000 annual plan is not one silent debit.
• Card numbers cannot be stored. You hold tokens, and refresh depends on the issuer and network, not on you.
• UPI Autopay mandates get revoked at the customer's bank without telling you. You discover it on the debit date.

The practical consequence: schedule retries against the notification clock, and route most recovery through an action the customer takes — approving a mandate, adding funds, paying a fresh link.

Days 30-60: the retry calendar beats the email copy

A retry schedule tuned to failure codes recovers more money than better-written reminder emails, because most soft failures clear on their own within a week or two.

A workable default: retry insufficient-funds and issuer-downtime failures on day 1, 3, 7 and 14. Never retry expired cards or revoked mandates — send a payment link and stop spending effort there. Pair every retry with a short reminder.

A worked example: 1,400 subscriptions at ₹3,200 average monthly billing is about ₹44.8 lakh billed each month. A 7% first-attempt failure rate means roughly ₹3.1 lakh fails. Ad-hoc follow-up typically recovers about a third of that; a structured retry-and-notification sequence typically recovers two-thirds to three-quarters. The gap is close to ₹1 lakh a month of cash you were writing off quietly.

Those notifications are their own deliverability problem — dunning mail lands in spam more often than product mail, and SMS in India needs DLT registration first. MailSender covers that side if you would rather not build it.

Days 45-75: the invoice and ledger become the hard part

The heavy lift from around day 45 is compliance, not collections: every debit needs a correct tax invoice, and every failed-then-recovered debit needs a credit note or reversal that actually matches GSTR-1.

For a continuous supply of services you can invoice per cycle rather than per debit, provided your contract says so — but invoice numbers cannot have holes, and place of supply must be right for every B2B customer. Then comes reconciliation: your payment aggregator typically settles T+2 or T+3, nets its fees, and sometimes settles in a batch that does not line up with any single invoice. GST billing automation is the part teams underestimate. Dunning recovers cash; sloppy invoicing turns that recovered cash back into a compliance problem.

Days 60-90: four numbers, not twelve

By day ninety, four numbers tell you whether any of this works: first-attempt success rate, involuntary churn, recovery rate by failure code, and days-to-recovery.

First-attempt success is the leading indicator — below 90% and your problem is mandate hygiene and notification timing, not copywriting. Recovery by failure code stops you over-investing in cases that will never recover. Days-to-recovery is working capital, not vanity: a payment recovered on day 14 has cost you two weeks of float. Involuntary churn is the lagging measure finance will be judged on. The one place a small model genuinely earns its keep is classifying decline codes and picking retry timing — AI work that is unglamorous and measurable rather than generative.

Where to start

Pull ninety days of decline data, classify it, and calculate what ten percentage points of improved recovery is worth per month — that number is your budget case. Then fix the two things that cost nothing: stop retrying hard declines, and make sure your pre-debit notification is provably going out. If the invoice and reconciliation layer is where it falls apart, which it usually is, that is the work we do at Maysan Labs — and the request we get most often from SaaS finance teams.