Reconciling School Fee Collection in Nepal

A school or college in Nepal collecting fees today is running a small payments operation whether it wants to or not. Parents pay through eSewa, through Khalti, by Fonepay QR at the front desk, by bank transfer, and some still by cash. Each channel produces its own record, on its own schedule, in its own format. Somewhere in the accounts office, someone has to turn all of that into a clean answer to a deceptively simple question: which students have actually paid, and how much is still outstanding.

This is a reconciliation problem, and it is a harder one than most retail businesses face, because the money is not just money - it has to attach to a specific student, a specific term, and often a specific fee head. This article walks through how to do that reliably.

Why school fees are harder to reconcile

A shop reconciles a settlement against a batch of anonymous orders. A school has to reconcile against a roster. That changes everything.

• The payment must identify a student. A Rs 12,000 credit is useless until you know it is Aarav in Grade 8, term two. If the parent forgot to put the student ID in the payment reference, you have money you cannot allocate.
• Fees have structure. Tuition, transport, exam fees, admission - a single payment might cover several heads, or only part of one. "Paid" is rarely a yes or no; it is a balance.
• Partial and late payments are normal. Parents pay in instalments. A student can be fully paid on tuition but owing on transport. Your reconciliation has to track balances, not just receipts.
• Volume is bursty. Fee deadlines create a flood of payments in a few days across every channel at once, which is exactly when errors and duplicates creep in.

Step one: get every channel into one place

Before you can allocate anything, you need every payment for the period in a single view, tagged by channel:

• eSewa and Khalti settlements. eSewa and Khalti payments arrive at your bank as lumps, net of fees. Each lump contains many parents' payments. You decompose the lump using the provider report, exactly as in reading an eSewa settlement report, before you can see the individual parent payments inside it.
• Fonepay QR. Front-desk and counter collections via Fonepay settle to the bank too, and carry their own references.
• Direct bank transfers. Many parents still transfer straight to the school account. These show on the bank statement with whatever narration the parent typed - sometimes the student name, often nothing useful.
• Cash. Recorded at the desk, banked later. The deposit slip has to reconcile against the day's cash receipts.

The output of this step is one list of payments, each tagged with its channel and provider reference, all reconciled against the bank statement so you know the money genuinely arrived and is not just a claimed payment.

Step two: attach each payment to a student

This is where schools live or die on reconciliation. Each payment has to find its student ledger. The reliability of this step depends entirely on how payments are identified.

• Best case: a student ID in the reference. If your fee notices ask parents to enter the student ID or roll number as the payment remark, most payments self-allocate. Push hard on this habit - it is worth more than any tool.
• Middle case: name matching. When the reference carries a name, you match against the roster. Nepali names have spelling variants, so this is fuzzy and needs review, but it clears a large chunk.
• Worst case: an orphan payment. Money with no identifiable student. These go into an exceptions queue and get chased manually - a parent phone call, a cross-check against who is known to be due.

Step three: track balances and defaulters

Once payments are attached, the ledger does the rest. For each student you now know the expected fee, the amount applied, and the balance. From this the two reports every administration needs fall out naturally:

• The defaulter list. Every student with a positive outstanding balance, sorted by amount or by how overdue. Because it is computed from a proven ledger, you can send reminders with confidence that you are not chasing a parent who already paid - the single fastest way to lose parents' trust.
• The collection summary. Total expected, total collected, total outstanding, broken down by class or fee head. This is what management and the board actually want to see.

The discipline that makes both trustworthy is the same as any reconciliation: every rupee of collection traces to a bank credit, and every allocation traces to a student. A defaulter list built on un-reconciled data will wrongly dun paid parents and miss real defaulters, which is worse than no list at all.

Step four: issue receipts that reconcile back

A fee receipt is a promise: it tells the parent their money was received and applied. That promise should be backed by a reconciled payment, not a claimed one.

The clean sequence is: payment arrives, reconciles against the bank, attaches to the student ledger, and only then generates a receipt carrying the student, the fee heads covered, the amount, and the remaining balance. A receipt issued before reconciliation - on the strength of a screenshot a parent sent, say - is a liability, because if that payment later fails to settle you have receipted money you never received.

Bringing it together across a term

Across a full term, the school's reconciliation becomes a rolling picture: expected fees at the top, payments flowing in through five channels, each attached to a student, each balance updating, defaulters shrinking toward the deadline. Rolled up daily, it becomes a proven close for the accounts office, in the sense described in what a daily close is, and it feeds clean figures into whatever accounting the institution runs.

Doing this by hand across eSewa, Khalti, Fonepay, bank, and cash - for hundreds or thousands of students - is a genuine burden, especially in the deadline rush. RakamHQ ingests all of those channels, decomposes the settlement lumps, and matches each parent payment back toward the right student ledger, so the accounts office spends its time chasing real defaulters instead of hunting for which lump a Rs 12,000 credit belonged to.

Frequently asked

Why is school fee reconciliation harder than retail?

Money has to attach to a specific student, term, and often a fee head, not just settle as anonymous revenue. Partial payments, instalments, and bursty deadline volume make each student a running balance rather than a paid-or-not flag.

How do I make parent payments match to the right student?

Print a unique reference - ideally the student ID - on each fee notice and instruct parents to enter exactly that. This converts most manual allocation into automatic matching and shrinks the orphan-payment queue dramatically.

How should a defaulter list be built?

From a proven student ledger where every collection traces to a bank credit and every allocation traces to a student. A list built on un-reconciled data wrongly chases parents who already paid and misses real defaulters.

Should I issue a receipt from a payment screenshot?

No. A success screen means the payment was captured, not that it settled to the school's account. Wait for the payment to reconcile against the bank, then issue the receipt, to avoid receipting money that never arrives.

Keep reading

How to Read Your eSewa Settlement Report (Without the Headache)

Read

Bank Statement Reconciliation in Nepal

Read

Reconciliation for ISPs and Subscriptions

Read