Three Kinds of Staff, One Payroll Run
A Kenyan school pays some of its staff, records others it does not pay, and takes on more each term than its establishment says it has. There is exactly one payroll run per month, it cannot be split into groups, and getting government-paid teachers to sit quietly in the same system is a decision you make once — deliberately.
The staff list of an ordinary Kenyan secondary school contains three populations that behave completely differently in a payroll. There are TSC teachers, who are on your establishment and on the government's payroll rather than yours. There are board-employed teachers and support staff, who are genuinely yours to pay. And there are the people you take on for a term — a matron, a games coach, casual labour for the maize harvest or the new classroom block.
Every bursar knows those three groups. The question is what happens when you put all of them into one HR module that has exactly one payroll run per month and no concept of a pay group.
One run, per month, per country
This is the structural fact to absorb before anything else. A payroll run is unique on the combination of the period and the work country — one run for August 2026 in Kenya, and there cannot be a second. There are no pay groups, no sub-runs, no separate cycles for teaching and non-teaching staff, and no mid-month run for people you pay weekly.
What the run does is sweep every employee in that country whose employment status says they are currently employed, and try to calculate a payslip for each. An employee who is not ready — no locked timesheet for the month, or no active contract with a salary on it — is skipped, and the reason is recorded on the run rather than blocking everybody else. That skip-and-report behaviour is the seam you will be working with.
| Your three staff groups | Should be an employee record | Should be in the payroll run | Needs an active contract with a salary |
|---|---|---|---|
| TSC teachers (paid by government) | Yes | No | No |
| Board-employed teachers | Yes | Yes | Yes |
| Support staff — cooks, matrons, grounds, security | Yes | Yes | Yes |
| Term-contract staff (games coach, locum) | Yes | Yes | Yes |
| Casual labour, paid daily in cash | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
| Board members and trustees | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
The first row is the interesting one and the reason this article exists. You want those teachers in the system — they hold classes, they have leave, they are custodians of laboratory equipment, they raise helpdesk tickets, they appear on your establishment returns. You do not want them in the payroll run, because you do not pay them.
Keeping government-paid staff out of a run that sweeps everybody
There is no exclude-from-payroll flag on an employee. So the only lever is the one the run itself uses: an employee with no active employment contract carrying a basic salary cannot be calculated, and is therefore skipped and listed with the reason.
That is the honest answer, and it comes with a cost you should accept openly rather than discover in month three: every run will list your TSC teachers as skipped, every month, forever. Forty teachers means forty lines of expected noise in a report designed to show you exceptions. The bursar has to learn to read past them, which is exactly the kind of thing that erodes a control.
The workaround to avoid
You could set those teachers to a status that the run does not sweep, and the skip list would go quiet. Do not: employment status is read by headcount reporting, the establishment view, task assignment, ticket routing and the access audit, and lying to all of them to tidy one report is a poor trade. A predictable skip list is honest. A wrong employment status is a bug you introduced yourself.
There is no exclude-from-payroll flag. The absence of a contract is the exclusion — which means your skip list is also your list of people you do not pay.
What the run actually computes
For everybody it does pay, the calculation is a fixed sequence, and each step is worth knowing because each is a place your figures come from.
-
Prorate the basic salary
The contract's monthly basic is prorated across the run's standard working days, less approved unpaid leave days for the period. Unpaid leave is read from approved leave requests against leave types marked unpaid, not from a raw day count — so paid leave does not reduce anybody's pay.
-
Add cash allowances and benefits
Each is a fixed amount or a percentage of basic, taken from the employee's compensation package. Non-cash benefits are deliberately excluded from gross pay, and each component carries its own taxable and pensionable flags — so a house allowance and a non-cash meal benefit are treated differently, correctly.
-
Add ad-hoc earnings for the period
A one-off — a project payout, an invigilation allowance, an acting allowance for a term — is queued against the employee for that period and picked up by the run once. Each carries its own taxable and pensionable flags.
-
Apply statutory deductions, in order
PAYE, NSSF, SHIF and the Affordable Housing Levy, each from a date-effective rule version with its own bands, base and clamps. Order matters: a deduction flagged as reducing the PAYE base is subtracted before income tax is computed, and the tax base is read live so the sequence is respected.
-
Apply voluntary deductions
Sacco contributions, welfare, a salary advance recovery — each a component on the employee's package, deducted after statutory.
-
Freeze everything onto the payslip
Every figure, including the exact statutory rule versions used, is snapshotted. A payslip regenerated after a Finance Act change reproduces the same numbers, and the annual P9A is rebuilt from those frozen snapshots rather than from live rates.
A term-contract hire, from engagement to payslip
One games coach, one term, three months of payroll
Illustrative; the June proration assumes 22 standard working days. The point of the third row is a defect fixed in this batch — an employee on probation used to be omitted from the run entirely, and omitted silently, because they were not swept and therefore never appeared on the skipped list either. A probationer is an employee who must be paid.
Two things on a payslip that are not what they look like
First, overtime hours are recorded and not priced. Approved overtime is derived from attendance against shifts and carried onto the payslip as a number of hours — but no earning line is created from it, because there is no hourly rate on a contract and no hours-based pay component. What those hours are worth is your policy, paid as a component or a period earning. The payslip label now says "overtime hours recorded" and points at the earnings section, because printing a bare hours figure beside a net pay that excluded it read as a claim that they had been paid.
Second, posting a run records payment rather than making it. Approving and posting writes one money-out transaction per employee into the Payments Register — routed to bank or to M-Pesa B2C depending on the payout method on their primary bank details — and two journal entries: the expense against payroll payable, then payable against bank. Those transactions are recorded as successful because there is no payout rail wired to a bank. There is no bank payment file to hand your bank, so the actual transfer is done in your banking platform and the system holds the record of it.
Questions to settle before the first run
Who locks the timesheets, and by which day of the month?
What good looks like
A named person and a fixed date, before the run is calculated.
If the answer is otherwise
An unlocked timesheet means that employee is skipped. If nobody owns the lock, your first run pays a fraction of your staff and reports the rest as exceptions.
Does every paid employee have an active contract with a basic salary on it?
What good looks like
Yes, checked once before the first run and once each term.
If the answer is otherwise
No contract, no payslip. This is the single most common reason a first run comes out short, and it is silent apart from the skip list.
How will you know a TSC teacher on the skip list is expected?
What good looks like
A written list of who should always be skipped, reviewed each term.
If the answer is otherwise
Without it, the exception list is indistinguishable from noise and a genuinely missing payslip hides among your government-paid teachers.
Which leave types are unpaid?
What good looks like
Configured explicitly, because proration reads that flag.
If the answer is otherwise
Leave marked paid when it is not means nobody is ever prorated. The flag on the leave type is what drives the arithmetic.
Who approves the run, and who posts it?
What good looks like
Two different people — approval is a status change, posting is money out and cannot be undone.
If the answer is otherwise
Only an approved run can be posted and a posted run cannot be posted twice, but nothing stops the same person doing both if you give them both permissions.
How are daily-paid casuals handled?
What good looks like
A written decision: through payroll on a monthly-equivalent basis, or outside it as an expense.
If the answer is otherwise
There is no daily or piece rate anywhere and no weekly run, so a genuinely daily workforce either becomes a monthly figure or does not belong in payroll at all.
What we do and do not do
What AWRA OpsHub does today
- Date-effective Kenyan statutory rules — PAYE with relief, NSSF, SHIF and the Affordable Housing Levy — each versioned with its own bands, base scope, computation order and clamps, including employer contributions.
- Frozen payslip snapshots, so a payslip reproduced after a rate change reproduces the original figures, and a P9A rebuilt from those snapshots.
- Proration on approved unpaid leave, read from leave types flagged unpaid rather than from a raw day count.
- Pay components as fixed amounts or percentages of basic, with taxable, pensionable and cash/non-cash flags, plus ad-hoc period earnings for one-offs.
- Approve-then-post separation, with a posted run locked against a second posting, and money-out transactions written to the Payments Register with the journal entries behind them.
- Employees who are not system users, so cooks, matrons and grounds staff hold full records without a login.
What it does not do
- One run per month per country, and no pay groups. Teaching and non-teaching staff cannot be run separately, and there is no weekly or mid-month cycle.
- No exclude-from-payroll flag. Government-paid staff are kept out by having no active contract, which puts them on the skipped list every month.
- No daily, hourly or piece rate. A contract carries a monthly basic and nothing else, so variable pay is computed outside and entered as an amount.
- Overtime hours are recorded, not priced. No hourly rate, no multiplier, no hours-based component — the money is a component or a period earning you enter.
- No bank payment file or payout rail. Posting records payments as made; the transfer happens in your banking platform.
- No statutory filing. The figures and the P9A are produced; submission to iTax, NSSF and SHA remains your process, on your deadlines.
The one-run constraint is the item to check against your own establishment before committing. For a school paying everybody monthly it is invisible; for one running a weekly casual wage alongside a monthly staff payroll, it decides how much sits outside the module.
A setup order that avoids the usual first-run disaster
- Create every employee record first, including the TSC teachers you will never pay, and write down which of them should always be skipped.
- Give an active contract with a basic salary to exactly the people you pay — and to nobody else.
- Configure leave types and mark the unpaid ones, before any leave is approved.
- Set the compensation package for each paid employee: house, commuter, responsibility, and the deductions they have agreed to.
- Lock the month's timesheets on a fixed date, then calculate a run and read the skipped list line by line against your written expectations.
- Approve and post with two different people, and reconcile the posted total against the bank transfer you actually made.
The fifth line is the one that saves the term. The first run is not a payment, it is a diagnostic: calculate it, read every skipped line, fix the causes, and calculate again. Runs are recalculable before approval, which is exactly what that step is for.
Our take
Put all three groups in as employee records and let contracts decide who gets paid — that is the mechanism, and there is no cleaner one. Accept the permanent skip list for government-paid teachers and write down who belongs on it, because an exception list you cannot read is not a control. And decide early where daily casual labour lives, since one monthly run with no daily rate is a constraint you work around rather than configure away.
See payroll and statutory deductions
Date-effective PAYE, NSSF, SHIF and housing levy, frozen payslips, P9A certificates, approve-then-post separation and money-out on the Payments Register.
Explore payrollFrequently asked questions
Can we run teaching and non-teaching staff as separate payrolls?
No. A payroll run is unique per period and work country, so there is one run for a given month and no concept of a pay group or sub-run. Everybody currently employed in that country is swept into it. If your groups need genuinely different cycles — monthly staff and weekly casuals, say — the second group has to be handled outside payroll, as expenses or vendor payments, rather than as a second run.
How do we keep TSC teachers in the system without paying them?
Create the employee records and do not give them an active employment contract with a basic salary. The run cannot calculate a payslip without one, so each is skipped and the reason recorded. The cost is that they appear on the skipped list every single month, so keep a written list of who is expected there — otherwise a genuinely missing payslip hides among them. Do not fix the noise by changing their employment status; that field drives headcount, task assignment, ticket routing and access auditing.
Is overtime paid automatically?
No. Approved overtime is derived from attendance against shifts and carried onto the payslip as a number of hours, and no money is computed from it — there is no hourly rate on a contract and no hours-based pay component. What an hour is worth is your policy, entered either as a pay component or as an ad-hoc earning for that period. The payslip now labels the figure "overtime hours recorded" and points at the earnings section, because the bare number read like a payment that had been made.
What happens to an employee on probation?
They are paid, like anybody else who is currently employed. Until this batch they were not: the run swept only employees marked active, so a probationer was omitted — and omitted silently, because they never entered the loop that builds the skipped list, so nothing on the run said a person was missing. Both statuses that mean currently employed are now included, which is what every other module in the product already assumed.
Does posting a payroll run pay our staff?
It records the payment, not the transfer. Posting writes one money-out transaction per employee into the Payments Register — bank or M-Pesa B2C depending on their primary payout method — plus two journal entries taking the expense through payroll payable to bank. Those transactions are recorded as successful because no bank payout rail is connected, and there is no payment file to upload to your bank, so the transfer itself happens in your banking platform.
Can a cook or a matron have a payslip without a system login?
Yes. An employee record is independent of a user account, so staff without logins hold contracts, leave, attendance and payslips normally. Getting the payslip into their hands is a separate question with its own answer — the self-service portal reaches people without company email, and nothing emails payslips automatically when a run completes.
Do you file our PAYE and SHIF returns?
No. The figures are computed from date-effective rule versions and frozen onto each payslip, the P9A is rebuilt from those snapshots for the annual return, and the reports behind the remittances are there — but submission to iTax, NSSF and SHA is your process and the deadlines remain yours. We also do not set or interpret the rates: bands and thresholds are the authorities' domain and your accountant's judgement.
