Refunds, बिना WhatsApp drama। एक policy। हर refund इसी से flow होगा।

आज ज़्यादातर Indian schools fee refunds कैसे handle करते हैं

June का दूसरा हफ्ता है। एक father Pune के ICSE school के office में आते हैं और कहते हैं कि उनकी daughter Bangalore के किसी दूसरे school में join हो गई है। उन्होंने first-quarter fees ₹42,000 pay की है और refund चाहिए। Accountant हार्डबाउंड register निकालती है, receipt ढूँढती है, intercom पर principal को call करती है। Principal पूछते हैं कि कितनी processing fee deduct करनी है। Accountant कहती है कि उसे नहीं पता; पिछले महीने एक दूसरे parent को 5% deduction मिली थी, उससे पहले एक parent को ₹500 flat, और एक parent का कुछ deduct नहीं हुआ क्योंकि वो school committee वाले के cousin थे।

Principal एक call करते हैं। 5 minutes में answer आता है: ₹1,500 flat deduct करो। Cheque लिख दिया जाता है। 2 hafte बाद वही scene एक alag family के साथ alag number पर play होता है। तीसरी family, दूसरी की सुनकर, same treatment ask करती है। August तक 3 parents एक WhatsApp group में inconsistency की complaint कर रहे हैं। September तक school को reputation problem हो जाती है जिसका cause किसी को clearly trace नहीं होता।

यह pattern universal है। ज़्यादातर Indian schools में refunds एक-एक cheque पर decide होते हैं — इसलिए नहीं कि school unkind है, बल्कि इसलिए कि rule ही नहीं है। Demand drafts जो सब भूल गए, online payments जो 2 बार आ गए, mid-quarter स्कूल छोड़ने वाले students, transport fees जिसका route discontinue हो गया, scholarship adjustments जो देर से आए। Policy के बिना, हर refund negotiation है। Policy के साथ, हर refund calculation है। वो single shift है जो Inkwelly का Refund Policy engine deliver करता है।

Inkwelly में Refund Policies कैसे काम करती हैं

Inkwelly में Refund Policy exactly वही है जो इसका नाम कहता है — school का written rule कि fee refund कैसे calculate, approve और account होगा। आप इसे Student Fee → Configuration → Refund Policies पर एक बार setup करते हैं, एक name देते हैं (ज़्यादातर schools Standard Refund Policy FY25 use करते हैं), और उस point से ये हर refund को govern करती है।

Policy के dil में 4 controls हैं: एक processing fee (refund का percentage AND/OR एक fixed rupee amount, दोनों parent को मिलने वाले अमाउंट से deduct होते हैं), एक minimum refundable amount (इससे छोटे refunds outright reject — ₹23 के cheques रोकता है), एक approval requirement flag, और एक optional approval threshold (केवल इस amount से ज़्यादा refunds को approval चाहिए; छोटे amounts manual sign-off के बिना जाते हैं)।

जब refund request raise होती है — Student Fee ledger से, parent portal से, या office की manual entry से — Inkwelly active policy resolve करता है, math चलाता है, और refund draft produce करता है। अगर approval required है और amount threshold cross करता है, request principal के queue में wait करता है एक click approve / reject के साथ। अगर approval नहीं चाहिए, refund ledger में post होता है और printable receipt immediately generate होती है। Either way, calculation, policy name, approver और timestamp record होते हैं — refund को permanently auditable बनाते हुए।

पाँच real refund scenarios जो ये fix करता है — Indian school offices से

1. Mid-year transfer. Indore के CBSE school में Class 7 की एक student October में Bangalore move हो जाती है। Family ने annual fees ₹88,000 pay की हैं। Withdrawal Refund Policy (10% + ₹1,000 fixed) calculate करती है: ₹88,000 × (1−0.10) − ₹1,000 = ₹78,200। Principal approve करते हैं; cheque same day cut होता है; receipt पर breakdown print होता है। कोई PTA debate नहीं, कोई negotiation नहीं, कोई inconsistency नहीं।

2. Razorpay double-payment. Parent UPI से ₹12,500 pay करता है। Transaction time out होती है, parent retry करता है, retry पर success मिलती है — लेकिन original payment भी go through हो गया। Inkwelly की reconciliation duplicate flag करती है। Double-Payment Refund Policy (0% + 0 fixed, ₹5,000 से नीचे auto-process) duplicate amount minutes में parent के UPI ID पर reverse करती है। Principal involvement की जरूरत नहीं।

3. Transport refund. Fuel prices change होते हैं; school एक route discontinue करता है। 12 students को unused months का partial transport refund चाहिए। Transport Refund Policy (0% + 0 fixed, approval required) हर refund को pro-rata calculate करती है; principal single batch में sabhi approve करते हैं। 12 refund receipts auto-generate होती हैं, हर एक policy name और rationale के साथ।

4. Mistaken late fee. Parent को paid invoice पर galat से ₹300 late fee charge हो जाती है। Accountant refund raise करती है। Late Fee Reversal Policy (0% + 0 fixed, ₹1,000 से नीचे auto-process) reversal immediately process करती है। Audit log original late fee, reversal, policy और user dikhati hai।

5. Minimum-threshold case. Parent ₹23 over-pay करता है। Standard Policy का Minimum Refundable Amount ₹100 set है। System refund auto-reject करता है और ₹23 student के ledger पर credit जोड़ता है — parent को visible, अगली invoice पर automatically apply। कोई ₹23 का cheque chase नहीं करता। कोई ₹23 lose भी नहीं करता।

“जो refund policy किसी को memory से याद ना हो, वो policy actually exist ही नहीं करती। Software में डालने की baat automation की नहीं है — fairness को visible बनाने की है।”

Refund Policy engine को real school की books पर देखिए

Sample CBSE / State Board fee structure पर 20-minute walkthrough। हम withdrawal refunds, double-payment auto-reversal, principal का approval queue और parent को असल में जो receipt मिलती है — सब दिखाएँगे।

Limits, safety और small print

Refund processing एक financial control है — Inkwelly इसे same care से handle करता है जैसे original fee collection को। केवल वही users जिनके पास Identity & Access Management में Student Fee Configuration permission है, policies create, edit या archive कर सकते हैं। Refund request raise करना एक separate permission है — typically accountant और office manager के पास। Threshold से ज़्यादा refund approve करने के लिए Refund Approval permission चाहिए, usually principal और school owner के पास।

Refund policy को delete नहीं किया जा सकता जब उससे historical refunds linked हों — system soft archive enforce करता है। मतलब 3 साल बाद, जब auditor पूछे कि 2024 के refund में कौन सी policy use हुई थी, retrieve exactly वैसा ही होगा। Active policies को versioned change से ही edit किया जा सकता है — prior version past refunds से attached रहती है, नई version उस day के बाद issued refunds पर apply होती है। कोई policy edit posted refund की math retroactively change नहीं कर सकता।

Online payments (Razorpay, UPI, PayU, Cashfree, Paytm) के against refunds default में original instrument पर route होते हैं — वही UPI ID, वही card, वही wallet — जो Reserve Bank of India की October 2023 guidance merchant refunds पर require करती है। Manual override करके cheque या bank transfer issue करना elevated permissions वाले users को allowed है और written reason के साथ log होता है। Cash payments के against refunds default में cheque mode होते हैं और posting से पहले parent का bank account या signed cheque-collection acknowledgement चाहिए।

Finally, policy engine कभी ईसा refund auto-process नहीं करता जिसकी calculation negative net produce करे (i.e., processing fee refundable amount से ज़्यादा हो) — ये error raise करता है ताकि office inputs verify कर सके। Floors और thresholds server-side enforce होते हैं, form में नहीं, तो misconfigured front-end भी इन्हें bypass नहीं कर सकता। Full audit log year-end पर board review और statutory audit purposes के लिए CSV में export होत“e है।