Getting a Paybill is the part every school manages. Safaricom sets it up, you print the number on the fee structure, and parents start paying. Within a term you discover that this was never the hard part.
The hard part is that a Paybill gives you a list of payments, and a school needs a list of learners. Turning one into the other — every day, without a bursar reading a statement line by line — is the actual job. This guide is about that.
Collecting is easy. Reconciling is the work
A Paybill statement tells you a phone number paid an amount at a time, with whatever reference the payer typed. It does not tell you which learner that was, which term it applies to, or which votehead it should sit against. Somebody has to decide all three.
In a school of 400 learners with two payment peaks a term, that is a few thousand decisions a year. Done by hand it produces the familiar symptoms: balances that are wrong for a fortnight after opening, parents who have paid being sent reminders, and a bursar who cannot leave the office in the first week of term.
So the question to put to any system, and to yourself, is not “can we accept M-Pesa”. It is how quickly does a payment become a correct balance on the right learner's account, and what happens when it cannot.
Make the account number do the work
Most of the reconciliation problem is decided before any money moves, by what you tell parents to type in the account number field.
The reference that works best is the one the parent already has written on everything: the learner's admission number. It is short, it is unique, it does not change when a phone changes hands, and it does not depend on which parent or relative is paying. Names do not work — they are typed differently every time. Phone numbers do not work either, because a learner may be paid for by a father one term and an aunt the next, and one number may cover three siblings.
Print it everywhere the fee structure appears, and print it as an example rather than an instruction:
Paybill: 123456 Account number: your child's admission number (e.g. 2451) Amount: any amount towards the term's fees
Two words of care. Say “admission number”, not “student number” or “ID”, and use the same phrase on the fee structure, the reminder message and the portal. Inconsistent wording is a surprisingly large share of the mismatches.
The four exceptions that create most of the work
Even with a clean reference, a predictable minority of payments will not post themselves. These four cover most of it:
| Exception | What it looks like | How to handle it |
|---|---|---|
| Blank or junk reference | Account field has a phone number, a name, or nothing | Queue for manual matching; use the payer's number and amount as clues |
| Sibling reference | One admission number used for two or three children | Split against siblings by the fee structure, and record the split |
| Wrong learner | An old admission number, or a digit mistyped | Reverse and repost, keeping both entries visible in the audit trail |
| Overpayment or part payment | Round figure that matches no invoice | Post it and let it sit as a credit or partial balance — do not hold it aside |
The thing to insist on is that exceptions are visible and dated. A system that silently drops unmatched payments into a suspense account nobody opens is worse than one that puts twelve items on a screen each morning and asks someone to clear them. The daily habit is what keeps balances trustworthy.
What a same-day workflow looks like
- Payments arrive against the Paybill and are pulled into the school's records with their reference intact.
- Automatic posting matches the admission number to a learner and applies the amount to their outstanding invoice.
- The receipt is generated by the payment, not typed afterwards, and goes to the parent on the channel they use.
- Exceptions land in one queue — unmatched, ambiguous or over-paid — and someone clears it once a day.
- The balance the parent sees updates at the same moment as the balance the bursar sees. One number, not two.
Step five is the one that removes the phone calls. When a parent can check their own balance and it is right, most of the fee-related traffic into your office disappears.
Receipts are not admin, they are evidence
A receipt settles a dispute before it starts. It is also the record you will rely on at audit, which is why receipting discipline has become a compliance matter as much as a finance one — see eTIMS and KRA compliance for Kenyan schools.
The rule worth holding to: every payment produces exactly one receipt, automatically, stored in one place, reachable by admission number. If receipts live partly in a book, partly in a spreadsheet and partly in a WhatsApp thread, you do not have a receipting system.
Paybill is not your only channel
Most schools take money three or four ways at once: M-Pesa, bank transfer, cheque and cash at the office. Reconciliation only works if all of them land in the same ledger. A system that handles M-Pesa beautifully but treats bank payments as a separate spreadsheet has moved the problem rather than solved it.
If you also collect through a bank partner, that flow should post the same way. The Mzizi and KCB partnership covers bank collection, and the M-Pesa school fees page covers the mobile side in more detail.
Telling parents, and chasing balances
Payment instructions belong wherever a parent looks for them: the fee structure, the portal, the reminder message and the school's WhatsApp. Keep the wording identical in all four.
Reminders are a separate discipline. Sent well they bring payments forward; sent badly they annoy the parents who have already paid — usually because the reminder went out against a balance that had not been reconciled yet. Reconcile first, then remind. We have templates and the ground rules in WhatsApp fee reminders for schools.
Setting it up: a checklist
| Step | Detail |
|---|---|
| Paybill | Arrange with Safaricom, and ask them which collection product suits a school your size |
| Reference | Standardise on the admission number; use one phrase for it everywhere |
| Fee structure | Loaded per class and term so invoices exist for payments to attach to |
| Invoices | Raised before the term opens, not after payments start arriving |
| Posting | Automatic by admission number, with a named person owning the exception queue |
| Receipts | Generated on payment and delivered to the parent |
| Other channels | Bank, cheque and cash posting into the same ledger |
| Parent view | Balance visible to parents, matching the office exactly |
| Daily routine | Ten minutes each morning clearing exceptions |
Before you commit: Paybill terms, transaction charges and the available collection products are set by Safaricom and change from time to time. Confirm the current details with Safaricom directly rather than relying on any vendor's description, including ours.