School Fees Reconciliation: M-Pesa, Banks & the Bursar's Ledger
M-Pesa, three bank accounts, cash at the office, and a thousand students — how bursars end the evening matching game: invoice per student, automatic payment matching, and arrears that report themselves.
Every Kenyan bursar knows the ritual: the M-Pesa statement on one screen, the bank statement printed, the fees register open, and an evening of detective work. "KIPCHOGE E — 15,000" — which of the three Kipchoges? The payment with no student name at all? The parent who paid for two siblings in one transaction? Fee reconciliation is not hard because the money is missing; it is hard because the money arrives without its paperwork.
The structure that ends the matching game
- One invoice per student per term — fees, transport, boarding, levies as line items, so a partial payment lands against something specific.
- A unique payment reference per student — admission number as the account reference on paybill payments. One instruction to parents, printed on every invoice, repeated every term.
- All channels into one ledger — M-Pesa, each bank account, and office cash posting into the same student accounts, not three parallel records.
- Same-day posting — payments matched daily, exceptions listed for the bursar; the evening ritual becomes a fifteen-minute exceptions review.
Handling the messy realities
| Reality | The undisciplined way | The disciplined way |
|---|---|---|
| Payment without a reference | Guess from the name; hope | Exceptions queue — matched by phone number history, confirmed with the parent, then posted |
| One payment, two siblings | Post to one child; argue in March | Family account linking siblings; split rules recorded once |
| Post-dated promises & bursaries | A notebook only the bursar can read | Documented payment plans and bursary awards on the student account |
| Cash at the office | Receipt book and a drawer | Receipted into the same ledger, banked intact daily — no netting expenses from fee cash |
| Refunds & transfers out | A negotiation each time | Credit balances visible; refund approvals through a workflow |
Never spend from the collection stream
Fee cash used directly for expenses — before banking — is the single practice that destroys school financial credibility. It makes reconciliation impossible, invites shortage disputes, and turns an honest office into a suspicious one. Bank everything intact; spend through the payment process.
Arrears: from ledger to collection
- Arrears by class, stream, and family — live, not compiled monthly by hand.
- Aging bands (current, 30, 60, 90+) so follow-up effort lands where recovery is likely.
- Consistent reminders — SMS at invoice, mid-term, and before exams — beat dramatic end-of-term confrontations.
- Payment plans recorded and tracked: a promise in the system is a commitment; a promise in the corridor is weather.
Fees are the revenue half of school money; the spending half — term procurement and store control — leaks just as quietly. The school ERP buyer's guide covers how both halves live in one system, with billing automation doing the matching.
What AWRA OpsHub does today
- M-Pesa collection via STK push, which is a real integration and the only mobile-money one we have.
- A consolidated payments register across modules, so recorded receipts are visible in one place.
- Customer invoices with balances, payments and AR aging, which is the generic receivable machinery.
- Audit logging of who recorded what, and when.
- Customer statements and overdue reminders — a statement over any date range with a running balance, emailable with your own subject and message, and an automatic reminder to the payer once an invoice is past due, on a cadence you set or switch off. Both work on customer invoices, so they describe a family's receivable rather than a learner's fee position.
More we can add to your workspace
- A student entity and a fee ledger: a student, a fee structure, a per-student invoice and an arrears position. Everything this article describes about fees sits outside the system today.
- Automatic bank matching: a statement import and a matching engine, so bank-side reconciliation stops being manual.
- Matching suggestions on the M-Pesa side, proposing a candidate from the payer's phone number or their payment history. Today an unreferenced payment reaches an unmatched queue and a person attaches it to an invoice chosen from a capped list of open ones.
- A parent portal, and no recurring invoice generation — so a termly bill is a set of invoices somebody raises each term rather than a cycle the system runs.
- A term or academic period concept to attach a fee cycle to.
This was the least honest page in the school cluster as first written, and the correction is blunt: reconciling school fees needs the fee ledger above, and it is a build. Two things once listed here as unavailable do ship and are worth knowing about — a dated statement you can email, and an automatic overdue reminder — though they operate on invoices raised by hand, against families rather than learners. Until the student, class and term entities exist, a fee system remains the right home for this and we take the spending side. The workable middle ground is set out in the school shop and the account that isn't there.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsTake the spending side, not the fees
M-Pesa collection, a consolidated payments register and AR aging — the generic receivables machinery, which is not a fee system. The page below is honest about which half of a school we handle.
See what we do for schoolsFrequently asked questions
Parents refuse to use the admission number reference. What then?
Some always will, and here it stays manual. An unreferenced M-Pesa payment arrives as a successful receipt attached to nothing, and lands in an unmatched queue where somebody picks the invoice it belongs to from a list of open ones. There is **no phone-number matching, no suggestion ranked by payment history and no automatic clearing** — the queue shortens because a person works through it. Two limits worth knowing before you plan around it: the list of open invoices offered alongside each receipt is **capped**, so a school with hundreds of unpaid bills may not see the one it needs; and the invoice you attach to belongs to a payer, not a learner, because there is no learner.
Can we handle bursaries, scholarships, and CDF payments?
No, not as a bursary. There is no student account for a third party to pay into, so there is nothing to track a commitment or a disbursement against. What exists is the ordinary customer machinery: a bursary fund or a sponsor can be a customer, you can invoice them and record what they pay, and that payment appears in the payments register like any other. What you cannot get is one balance per learner assembled from a parent, a fund and a constituency office — that is the fee ledger this article says we do not hold, and splitting a payer across learners is exactly where it would be needed.
Should we stop accepting cash entirely?
Many schools push hard toward paybill-only, and it simplifies everything — but a hard ban can exclude some families. The workable middle: cash accepted at the office, receipted into the system immediately, banked intact daily. What matters is that cash follows the same ledger discipline, not the channel itself.
How do we start mid-year with messy existing balances?
Reconstruct from the last trusted point, usually the start of the year, then verify with a statement sent to each family — disputes surface fast and get settled once — and run clean from a cut-over date. Do not migrate the mess; draw a line under it. Be clear about the unit while you do it: what you can open a balance on here is **a payer**, so a family with three learners is one balance rather than three. If you need it per learner, that split lives in your fee system and this is where the two have to agree.
