School ERP in Kenya: A Buyer's Guide for Bursars & Directors (2026)
A buyer's guide for directors and bursars — what school operations software must handle in Kenya: fees reconciliation, term-cycle procurement, boarding stores, staff payroll, and the asset register the board keeps asking about.
A school is three businesses wearing one uniform: a service business that bills fees and must collect them, a logistics operation that feeds and supplies hundreds of people on a term calendar, and an asset-heavy institution with labs, buses, dormitories, and kitchens to maintain. Most "school software" serves the first business — admissions, exams, sometimes fee invoices — and leaves the bursar running the other two on exercise books.
This guide is about those other two businesses: the operations side, where most of a school's money actually moves and most of it leaks.
Where school money actually leaks
- The store. Rice, beans, cooking oil, detergent — boarding consumables bought by the lorry and issued by the cup, with no stock card between the two.
- Term-start procurement. Everything is urgent in the first week of term, so quotations are theatre and prices are whatever the regular supplier says.
- Fees that almost reconcile. M-Pesa here, three bank accounts there, cash at the office — and a bursar spending evenings matching narrations to student names.
- Assets without custody. Lab equipment, sports gear, kitchen appliances — issued to departments, returned never, replaced annually.
- Casual wages. Groundsmen, cooks, term-time staff paid in cash with records that would not survive one KRA question.
The capability checklist
1. Stores and consumables control
The school store needs real inventory: receipts against purchase orders, daily issues to the kitchen against expected consumption per student count, and stock counts that make the storekeeper's numbers public. A boarding school that starts measuring kitchen issues per student-day typically finds 10–20% of consumable spend was evaporating.
2. Procurement on the term calendar
Term dates are known years ahead — there is no excuse for emergency buying in week one. The system should hold procurement plans tied to the calendar, run real quotations for the big term contracts (food supply, transport, uniforms), and enforce approval thresholds so the deputy's signature means something. Our procurement policy template adapts directly to school boards.
3. Fees reconciliation
Invoicing per student per term, payments arriving by M-Pesa, bank, and cash — matched to students automatically, with arrears visible per class and per family. The full discipline is in our fees reconciliation guide.
4. Asset registers with custodians
Every microscope, bus, and cooker registered with a named custodian and location — the discipline in our school asset register guide — so the January question "where are the lab thermometers?" has an answer other than a shrug.
5. Payroll with statutory
Teachers on payroll, support staff, and term-time casuals — PAYE, NSSF, SHIF, and housing levy computed on current rules, with casuals paid through proper records instead of envelope arithmetic.
Questions for any vendor
Make them show, not tell
- A term's consumables: PO → delivery → store → daily kitchen issues → variance report.
- A fee payment arriving by M-Pesa and matching to the right student automatically.
- Arrears by class, by stream, and by family — on one screen.
- An asset issued to the science department, verified physically, and traced after a staff exit.
- A casual worker paid for eight days with PAYE handled.
- The board report: term spend vs budget, store variances, arrears — generated, not typed.
Then apply the same commercial diligence as any Kenyan institution buying software: the 10 provider questions and the three-year cost math. For how AWRA answers all of this, see ERP for schools in Kenya.
What AWRA OpsHub does today
- Procurement with enforced approval thresholds, requisition approval before ordering, and RFQ comparison — term buying, governed.
- Stores and stock per location, with blind cycle counting and valued variance, for the kitchen store, the lab and the general store.
- An asset register with named custodians across departments, with movement history and retirement.
- Budgets per department and period, with expenses coded to category and project. Test this one on a demo: there is no department on an expense, so a departmental budget's actual spend is matched on category alone and reads across the whole school rather than the department named on the budget line.
- Payroll for staff with Kenyan PAYE, NSSF, SHIF and housing levy on date-effective rules.
More we can add to your workspace
- A student information system: a student, a class, an enrolment and a guardian record.
- A fee ledger: a fee structure, a student invoice, a fee payment and an arrears position — the whole fee stream.
- Bank reconciliation for matching incoming payments.
- A timetable, attendance-by-class, results or transport module.
The article talks about "one fee stream" and that is the one thing we do not have. Be direct about the split when you evaluate: your school management or fee system keeps doing fees, students and academics, and we take the operations side — buying, stores, assets, staff costs. Schools looking to replace a fee system will be disappointed; schools whose stores and procurement are run on paper will not.
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 needsBring one term's chaos to a demo
Governed term procurement, stores counted per location, an asset register with custodians and staff payroll — the operations side of running a school.
See AWRA for schoolsFrequently asked questions
We already have a school management system for exams and admissions. Does this replace it?
Not necessarily — academic systems and operations systems solve different problems and often coexist. AWRA governs the money-and-materials side: stores, procurement, fees reconciliation, assets, payroll. If your academic system already does fee invoicing well, start with stores and procurement, where the leakage is.
How big does a school need to be for this to pay off?
The trigger is boarding or scale: a 300-student boarding school moves more consumables than most shops move stock. Day schools with significant assets, staff payroll, and multi-stream fee collection also recover the cost quickly — typically from store variance alone.
Can parents pay by M-Pesa directly?
Yes — payments to the school's till or paybill reconcile against student invoices, with the matching automated and exceptions listed for the bursar rather than the bursar doing all the matching by hand.
Who in the school runs the system day to day?
The bursar and storekeeper are the primary users; the principal and board get dashboards and reports. Role-based access keeps the storekeeper in stores and the accounts clerk in fees — with every action attributed.
