The complete guide
Most Indian students do not pay a course fee in one go, and most academies do not want a financing platform standing between them and their money. This guide explains how instalment collection actually works when the software owns the schedule and you own the collections — from the counsellor's first conversation to the last rupee reconciled.
How fees are really sold
A course has a list price; a student has a negotiated one. They pay a registration amount to book the seat — often before they exist in any system — and a counsellor splits the remainder in front of them: four instalments this time, six for the next student, a bigger first instalment for one, a due date that lands after salary day for another. Any instalment software that only offers fixed EMI templates has failed before the first admission.
Tensionmukti models the conversation itself. The enrolment console takes the agreed fee, the registration (and whether it was already collected, and the invoice number if one was already raised in your Zoho Books), and an editable row per instalment. The difference against the fee recomputes live as the counsellor types, and the plan cannot be saved until it adds up to the rupee. What was agreed is what is stored — and what is stored is what gets collected.
You can feel that arithmetic yourself on the homepage's interactive plan splitter — drag a fee and watch the schedule assemble.
The schedule
The legacy system this product replaced had a real bug worth learning from: a downstream recompute quietly re-divided a student's remaining pool, and a penalty that had been added to the schedule simply vanished into the new division. Nobody deleted it; the arithmetic ate it. That class of bug is why Tensionmukti treats a schedule as a contract: generated once at enrolment, with final amounts, and never recomputed. Later events — payments, date changes, write-offs — add rows or mark rows. They never edit history.
Status, on the other hand, is never stored stale. Whether an instalment is upcoming, due soon, overdue, partially paid or paid is derived from its amount, its payments and today's date, each time it is read. Grace days come from the batch. A part-paid instalment past its deadline shows the badge that is most useful at a glance and still counts as late money in every total — the badge and the sum are deliberately driven by different flags, so neither lies.
| Item | Ex-GST | GST | Amount | |
|---|---|---|---|---|
| Admission fee | ₹4,237 | ₹763 | ₹5,000 | Paid |
| Instalment 1 of 5 | ₹5,085 | ₹915 | ₹6,000 | Paid |
| Instalment 2 of 5 | ₹5,085 | ₹915 | ₹6,000 | Overdue |
| Instalment 3 of 5 | ₹5,085 | ₹915 | ₹6,000 | Upcoming |
Collection
Instalment collection fails in practice when the software only understands one channel. An Indian academy collects across at least four, usually in the same week:
Whatever the channel, one pipeline runs: an idempotency guard (a double click or a replayed webhook records once), the ledger row, a sequential invoice number, the GST tax invoice in your Zoho Books, the receipt email, and the live status refresh. Cash has one extra step — an evening handover the receiver confirms — so what was collected and what reached the drawer reconcile daily, with two names on the record.
When plans meet reality
A due date moves with one action, and every move is kept in its own history — the schedule stays a contract, amendments and all.
The receipt is voided, the instalment re-opens itself, and the bounce charge becomes a penalty row that is chased like any other due amount.
Recorded against the instalment; the balance stays live and correctly aged. Nothing is recalculated by hand, so nothing is forgotten.
Recorded against the original receipt. Partial refunds may never exceed it; only a full reversal voids the invoice. The books stay honest.
Remaining instalments are cancelled — kept, not deleted — and the exact shortfall books as bad debt on that date. Reminders stop the same moment.
The old enrolment closes, a new one opens, and money already collected stays attached to the enrolment it was actually collected against.
The financing comparison
The other way to offer instalments is a financing platform: it pays your institute upfront, collects no-cost EMIs from the parent on its own account, and keeps a percentage of everything. That genuinely solves cash flow — at the price of a permanent tax on your collections and a fee history that lives in someone else's system.
With Tensionmukti the trade is different: you wait for each instalment as it falls due (the software makes sure it does not fall quietly), and in exchange every rupee lands in your own Razorpay account, uncut, with the ledger in your own Zoho Books. For most established academies the arithmetic favours owning the flow. If you are choosing between the two models, the buyer's guide lists the exact questions to ask either vendor — including us.
Questions
No. Tensionmukti is software, not a lender. Your student pays you directly, on the schedule you both agreed; we never advance money, never collect on our own account, and never take a percentage. If you want financing, that is a different product with different economics — this guide's comparison section explains the trade.
Yes — that is the point. The fee is agreed per student, the registration recorded as actually collected, and the remainder split however the conversation went: four instalments or six, a bigger first one, a due date after salary day. The console refuses any plan that does not add up to the agreed fee, and stores exactly what was agreed.
A part payment is recorded against the instalment and the balance stays live — badged partially paid, counted as late money in every total once past its grace days. Nothing needs recalculating by hand: status is derived from the amount, the payments and today's date, on every page load.
One button voids the receipt (the money never arrived), which automatically re-opens the instalment, and raises the bounce charge as its own penalty row — so it gets collected and reminded about like any other due amount instead of being a note in someone's diary.
Mark them backed out: the remaining instalments are cancelled — kept in the record, never deleted — reminders stop immediately, and the exact shortfall between the agreed fee and what you actually kept is booked as bad debt on that date. The write-off happens once, honestly, instead of haunting the collections list for months.
Yes. Each instalment can carry a Razorpay payment link — sent by staff, included automatically in reminders, or opened by the student from their own portal. The webhook records the payment the moment it succeeds, raises the invoice and emails the receipt with nobody at a keyboard.
Keep reading
What it should actually do for an Indian education business, and how to judge one.
Read the guideAutomated, polite, and from your own number — with a pay link inside every nudge.
Read the guideCGST, SGST, IGST and sequential invoice numbers, decided per student, automatically.
Read the guideRegistration already billed elsewhere, uneven instalments, a penalty mid-schedule — tell us the messy real case and we'll show you exactly how it is modelled.