Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
For schools & education
Fees that reconcile themselves, stores that measure the kitchen, procurement on the term calendar, assets with custodians, and payroll with statutory handled — one system for the bursar's whole world.
If any of these ring true, you are exactly who this was built for.
M-Pesa, three banks, cash at the office — and a bursar matching payment narrations to student names after dark.
Consumables bought by the lorry, issued by memory — and 10–20% of the spend evaporating between the two.
Term dates known for years, yet every term starts with urgent purchases at whatever price was quoted on the phone.
Labs, dorms, and sports stores replacing items nobody can find — an invisible annual tax.
Each capability links to a deeper feature tour.
One invoice per fee payer with a unique reference, M-Pesa payments quoting it matched automatically, and receivables aged with reminders. The payer is a customer record — there is no student entity, so no arrears by class or by family.
Receipts against POs, daily kitchen issues recorded with a reason and a person, and blind counts with valued variance weekly. Issues per head is arithmetic you do — the system holds no student count.
Consumption-planned buying, RFQs for the big four contracts, committee approvals on the record.
Labs, ICT, dorms, kitchens, buses — named custodians, movement history and condition on every hand-off, verified on your own term rhythm. No maintenance schedule: an asset carries no service interval and no next-service date.
PAYE, NSSF, SHIF, and housing levy for teachers and support staff; casuals paid with proper records.
Term spend vs budget, store variances, arrears aging, and the asset report — generated, not typed.
Running in the product now
The school-specific layer — on the roadmap, and commissionable now
What we would decline, and would rather say now
The four items in the middle column are absences rather than positions, and every one of them is commissionable now on the same terms as everything else here — a written specification, a timeline and a price, before any money moves. The evidence that this is a real offer rather than a sales line is Kenya itself, where the eTIMS transmission and the maintained statutory payroll engine were both built exactly this way, because schools and other clients asked for them. We will not name a date on this page, and we will name one in a quote.
The split is clean and worth taking seriously before a demo: the bursar's money, materials, assets and payroll are genuinely covered, and the school — students, classes, fee structures — is not modelled at all. Schools run on us today with the fee payer as a customer, which works when one payer means one bill and gets awkward across a large roll. If you need a student ledger this term, buy a school management system and keep us for stores, procurement, assets and payroll, which is where the leakage actually is.
One term of receipts, issues, and counts — the variance report pays for the project by itself.
One referenced invoice per payer, and the unmatched-receipt queue in place of the evening ritual — referenced payments attach themselves, the rest you attach from a list.
Procurement plans, asset verification rhythms, and payroll — the full bursar's calendar, systematized.
Schools are three businesses in one uniform — fees, logistics, and assets. What operations software must handle, and where school money actually leaks.
Term dates are known years ahead — yet week one is always a buying emergency. The term procurement cycle, the big four contracts, and kitchen arithmetic.
One invoice per student, a unique payment reference, all channels into one ledger — how bursars end the evening matching game and make arrears report themselves.
Questions we are asked here
No — it governs the operations side: money, materials, assets, and payroll. Academic systems handle admissions, exams, and timetables; the two coexist, and many schools run both. If your academic system already invoices fees well, start AWRA at stores and procurement.
To the right *invoice*, yes, and that is the honest wording. A payment quoting the invoice number attaches to it automatically and updates the balance. It does not match to a student, because there is no student record — the fee payer is a customer, and an admission number works only if you use it as the invoice reference yourself. Unreferenced receipts land in an unmatched queue where you attach them by hand against a list of open invoices; there are no phone-number matching suggestions, and the list is capped at 300 open invoices, which a large school will exceed. Bank statement matching is not built at all — only M-Pesa.
Boarding schools feel the store pain most, but day schools with significant assets, multi-channel fee collection, and staff payroll recover the cost quickly too. Start with the module that hurts most — fees for day schools, stores for boarding.
Go-live is timed to a term boundary: stores open with a count, and fees open with a verified opening balance per payer at term start. One term of parallel discipline and the routines are set — mid-term big-bang migrations are what we avoid. Note that the fee ledger is per customer rather than per student, so a family with three children is one payer unless you choose to create three.
One store, one term of fee data, one asset room — see the term run governed. Then ask to see a student record, and we will show you the customer that stands in for it; decide from there.