I build billing infrastructure for subscription businesses: plans and proration, dunning, revenue recognition and cohort analytics — on a ledger, so that monthly recurring revenue is a fact you can audit rather than a dashboard you hope is right.
Where does subscription billing actually get hard?
Not in the happy path. Charging a card monthly is a solved problem, and every provider does it well. It gets hard where Indian reality meets a billing model designed elsewhere.
UPI mandates and e-mandates have their own failure modes — registration failures, limit changes, step-up authentication at renewal — and none of them map cleanly onto “card declined”. Plan changes arrive mid-cycle and need proration to the day. GST applies to every invoice with its own rules. And then the gap that defines the category: the billing tool’s MRR figure and the bank’s actual deposits disagree, and nobody can explain by how much or why.
Recurring revenue with non-recurring reconciliation is just optimism with a dashboard attached.
What does the system cover?
- Plan and proration engine. Upgrades, downgrades, pauses and mid-cycle changes computed to the day as explicit events, not manual credit notes.
- Payment orchestration. Mandates, retries and smart dunning that recovers involuntary churn without harassing loyal customers — tuned to salary cycles and delivered where people actually read messages.
- Invoicing correctness. GST or VAT per market, credit notes handled properly, receipts that reconcile.
- The revenue ledger. Every invoice, receipt and credit note as double-entry events, with MRR and ARR as projections you can rebuild from history rather than numbers a tool asserts.
- Cohort and churn analytics. Drawn from billing truth, with revenue churn separated from customer churn.
Why involuntary churn is the cheapest revenue in the business
Because those customers still want your product. They did not decide to leave — a mandate failed, a card expired, a bank tightened a limit, an authentication step appeared at renewal. Every one of those is recoverable with a well-timed, well-worded nudge, and every one of them gets counted as churn when the retry logic is generic.
The fix is unglamorous and specific. Model each failure reason separately, because they have different recovery paths: a limit issue needs the customer to act in their banking app, an expired card needs a payment-method update, a step-up authentication needs a link at a moment they can complete it. Then time the retries to when money is actually in accounts, which in India means paying attention to salary cycles rather than retrying every 72 hours because that is the library default. And deliver the nudge on WhatsApp, where it will be read.
Businesses that do this find a meaningful slice of what they had booked as churn was actually a billing failure — which reframes the retention problem entirely, because you are no longer trying to win people back, only to let them keep paying you.
Why the ledger sits underneath all of it
Because every number above needs to survive scrutiny: an auditor’s, an investor’s, or your own during a tool migration. A billing provider’s dashboard is a report on its own records, and those records leave when the provider does. A ledger you own — events immutable, balances derived, reconciled daily against the bank — means MRR is provable, deferred revenue schedules are tie-outs rather than exports, and switching providers is an integration change rather than a history loss.
That is the same argument as the ledger platform makes, applied to the specific case where the money arrives on a schedule.
Related reading
/products/ledger-platform — the deployable core · /blog/reconciliation-at-scale — matching deposits to invoices · /industries/insurance — the renewal-book parallel · /services/fintech — the practice behind it
Has your MRR ever corrected itself overnight?
Facts do not correct; estimates do. If your recurring revenue number has ever moved by lakhs after the fact, it was never a measurement. /contact.
Questions I actually get
Why not just use Stripe Billing or Razorpay Subscriptions?
Use them — under a ledger you own. Those tools bill well; they do not keep your books, and they do not survive a tool migration with your history intact. Revenue recognition, cohort truth and audit tie-outs need to live in your own data, with the billing provider as a replaceable component.
Does dunning actually work in India?
It works when it is tuned to local reality: retry windows aligned to salary cycles, mandate-behaviour awareness, and WhatsApp rather than email as the nudge channel. Generic dunning built for card-first Western markets underperforms badly here, which is why involuntary churn looks worse than it is.
How do UPI and e-mandates change the picture?
They introduce their own failure modes — mandate registration failures, limit changes, step-up authentication at renewal — which need modelling as first-class states rather than lumped into a single 'failed' bucket. Treating them all the same is how recoverable failures get written off as churn.
Can it produce revenue recognition for audit?
Yes — deferred revenue schedules drawn from the same ledger that runs billing, so your auditor gets tie-outs instead of exports. Rev-rec computed separately from billing is how the two end up disagreeing at year-end.
Plan changes mid-cycle?
Proration computed to the day, with upgrades, downgrades and pauses as explicit events rather than manual credit notes. Every manual adjustment is a future reconciliation problem, so the engine handles the arithmetic.
Do you handle cohort and churn analytics?
From billing truth rather than product guesses — cohorts, retention curves and revenue churn separated from customer churn. Those two diverge, and confusing them leads to fixing the wrong problem.