Refunds, without the WhatsApp drama. One policy. Every refund flows through it.

How most Indian schools handle fee refunds today

It is the second week of June. A father walks into the office of an ICSE school in Pune and says his daughter has joined a different school in Bangalore. He has paid the first-quarter fees — ₹42,000 — and wants a refund. The accountant pulls out a hardbound register, finds the receipt, calls the principal on the intercom. The principal asks how much processing fee to deduct. The accountant says she does not know; last month a different parent got a 5% deduction, the parent before that got ₹500 flat, and one parent got nothing deducted because his cousin is on the school committee.

The principal makes a call. Five minutes later the answer comes back: deduct ₹1,500 flat. The cheque is written. Two weeks later the same scene plays out for a different family with a different number. The third family, hearing of the second, asks for the same treatment. By August three parents are in a WhatsApp group complaining about inconsistency. By September the school has a reputation problem nobody can quite trace.

The pattern is universal. Refunds at most Indian schools are decided one cheque at a time — not because the school is unkind, but because no rule exists. There are demand drafts everyone has forgotten about, online payments that arrived twice, students who left mid-quarter, transport fees on a route that was discontinued, scholarship adjustments that flowed in late. Without a policy, every refund is a negotiation. With a policy, every refund is a calculation. That single shift is what the Refund Policy engine in Inkwelly delivers.

How Refund Policies in Inkwelly work

A Refund Policy in Inkwelly is exactly what its name suggests — the school's written rule for how a fee refund is calculated, approved and accounted for. You set it up once at Student Fee → Configuration → Refund Policies, give it a name (most schools use Standard Refund Policy FY25), and from that point forward it governs every refund the school issues.

Four controls sit at the heart of the policy: a processing fee (charged as a percentage of the refund AND/OR a fixed rupee amount, both deducted from what the parent receives), a minimum refundable amount (refunds below this threshold are rejected outright — prevents ₹23 cheques), an approval requirement flag, and an optional approval threshold (only refunds above this amount need approval; smaller amounts go through without manual sign-off).

When a refund request is raised — from the Student Fee ledger, the parent portal, or the office's manual entry — Inkwelly resolves the active policy, runs the math, and produces a refund draft. If approval is required and the amount crosses the threshold, the request waits in the principal's queue with a one-click approve / reject. If approval is not required, the refund is posted to the ledger and a printable receipt is generated immediately. Either way, the calculation, the policy name, the approver and the timestamp are recorded — making the refund permanently auditable.

Five real refund scenarios this fixes — from Indian school offices

1. The mid-year transfer. A Class 7 student in a CBSE school in Indore moves to Bangalore in October. The family has paid annual fees of ₹88,000. The Withdrawal Refund Policy (10% + ₹1,000 fixed) calculates: ₹88,000 × (1−0.10) − ₹1,000 = ₹78,200. The principal approves; the cheque is cut the same day; the receipt prints the breakdown. No PTA debate, no negotiation, no inconsistency.

2. The Razorpay double-payment. A parent pays ₹12,500 by UPI. The transaction times out, parent retries, gets a success on retry — but the original payment also went through. Inkwelly's reconciliation flags the duplicate. The Double-Payment Refund Policy (0% + 0 fixed, auto-process below ₹5,000) reverses the duplicate amount back to the parent's UPI ID within minutes. No principal involvement needed.

3. The transport refund. Fuel prices change; the school discontinues a route. Twelve students owe partial transport refunds for the unused months. The Transport Refund Policy (0% + 0 fixed, requires approval) calculates each refund pro-rata; the principal approves them in a single batch. Twelve refund receipts auto-generate, each carrying the policy name and the rationale.

4. The mistaken late fee. A parent is wrongly charged a ₹300 late fee on a paid invoice. The accountant raises a refund. The Late Fee Reversal Policy (0% + 0 fixed, auto-process below ₹1,000) processes the reversal immediately. The audit log shows the original late fee, the reversal, the policy and the user.

5. The minimum-threshold case. A parent over-pays by ₹23. The Standard Policy's Minimum Refundable Amount is set to ₹100. The system auto-rejects the refund and adds the ₹23 as a credit on the student's ledger — visible to the parent, applied automatically against the next invoice. Nobody chases a ₹23 cheque. Nobody loses ₹23 either.

“A refund policy nobody can recite from memory is a policy that doesn't exist. The point of writing it in software is not automation — it is fairness made visible.”

See the Refund Policy engine on a real school's books

20-minute walkthrough on a sample CBSE / State Board fee structure. We'll show withdrawal refunds, double-payment auto-reversal, the principal's approval queue and the receipt parents actually receive.

Limits, safety and the small print

Refund processing is a financial control — Inkwelly handles it with the same care as the original fee collection. Only users with the Student Fee Configuration permission inside Identity & Access Management can create, edit or archive policies. Raising a refund request is a separate permission — typically held by the accountant and the office manager. Approving a refund above the threshold requires the Refund Approval permission, usually held by the principal and the school owner.

A refund policy cannot be deleted while it has historical refunds linked — the system enforces a soft archive instead. This means three years later, when an auditor asks for the policy used in a 2024 refund, it is retrievable exactly as it was. Active policies can be edited only via a versioned change — the prior version stays attached to past refunds, the new version applies to refunds issued from that day forward. No policy edit can retroactively change a posted refund's math.

Refunds against online payments (Razorpay, UPI, PayU, Cashfree, Paytm) are routed back to the original instrument by default — same UPI ID, same card, same wallet — which is what the Reserve Bank of India's October 2023 guidance on merchant refunds requires. Manual override to issue a cheque or bank transfer is allowed only for users with elevated permissions and is logged with a written reason. Refunds against cash payments default to a cheque mode and require the parent's bank account or signed cheque-collection acknowledgement before posting.

Finally, the policy engine never auto-processes a refund where the calculation produces a negative net (i.e., the processing fee is larger than the refundable amount) — instead it raises an error so the office can verify the inputs. Floors and thresholds are enforced server-side, not in the form, so even a misconfigured front-end cannot bypass them. The full audit log is exportable to CSV at year-end for board review and statutory audit purposes.