PAYE, NSSF, SHIF & Housing Levy: Running Kenyan Payroll Without Surprises
Four statutory deductions, four sets of rules, and rates that move. What a Kenyan payroll run should actually do, why date-effective rules matter more than the arithmetic, and the reconciliation that catches errors before the money leaves.
Kenyan payroll is not difficult to calculate. It is difficult to calculate the same way twice, across twelve months, through a rate change, for a workforce that keeps changing — and it is that consistency, not the arithmetic, that a payroll system is actually for.
This guide covers what a run should do, in what order, and what to check before you approve it. It deliberately states no rates, bands or thresholds: they are set by the authorities, they change, and a guide that quotes them ages into a liability. Confirm every current figure with KRA, NSSF, SHA or your accountant. Nothing here is tax or legal advice.
Four obligations, four different shapes
The reason spreadsheet payroll breaks is not that any one deduction is complex. It is that they are complex in different ways, so one clever formula cannot cover them.
| Deduction | What makes it awkward | What a system must handle |
|---|---|---|
| PAYE | Banded and progressive, with reliefs and allowable deductions interacting | Band logic held as data with effective dates, not hard-coded percentages |
| NSSF | Tiered contributions that have changed, with employer and employee portions | Tier structure versioned by date, so old periods stay computed on old tiers |
| SHIF | Its own basis and rules, distinct from the scheme it replaced | A separate component, not a renamed old one carried forward |
| Housing levy | Employer and employee sides, applied on its own basis | Its own component with its own base definition |
The pattern worth noticing: every one of them is a component with a basis, a rate and a period during which that rate applied. A system that models them that way copes with change. A system that hard-codes today's numbers into a formula becomes wrong the first time anything moves, and — worse — becomes retroactively wrong about the past.
Why date-effective rules matter more than the maths
This is the single most important thing to test in a payroll demo, and almost nobody tests it.
When a statutory rate changes, there are two ways a system can absorb it. It can overwrite the old rate with the new one — quick, and it silently falsifies every historical payslip that was computed on the old rate. Or it can close the old rule with an end date and open a new one, leaving every past period attached to the rules that actually governed it.
Overwriting a statutory rate does not just change the future. It rewrites your own history — and you will only discover it the day someone asks you to explain a deduction from eighteen months ago.
The second approach is what makes an employee query answerable and an inspection uneventful. You re-open the payslip, it computes on the rules of its own period, and it matches what the employee was actually paid. In AWRA the statutory rules resolve per country and per period, and payslips carry the rule version they were computed under, precisely so this holds.
The one-question demo test
Ask any payroll vendor: "Open a payslip from before the last statutory rate change and show me it still computing on the old rule." A system built properly does it in a click. A system built on a settings field will either recompute it wrongly on today's rates or explain why you would never need that. You would need it the first time anyone queries anything.
The run, in order
-
Freeze the inputs
Joiners, leavers, pay changes, allowances, overtime and absence all in before the run opens. Variable inputs arriving by message after this point are the main source of payroll rework.
-
Resolve compensation per employee
Basic, allowances and recurring items from the employee's compensation record rather than from last month's spreadsheet copied forward.
-
Pull attendance into the calculation
Overtime, unpaid absence and casual days as captured records, so a payslip line traces to an attendance entry someone can point at.
-
Compute statutory components on the period's rules
PAYE, NSSF, SHIF and housing levy, each on its own basis, each on the rule version effective for that period.
-
Reconcile before approving
Headcount, gross, deductions and net against last period, with every movement explained. This is the control that actually catches errors.
-
Approve, pay, then post the cost
Approval separate from preparation, payment recorded in the same ledger as every other outflow, cost allocated to department, project or grant.
The reconciliation, in detail
Four numbers, compared against the previous period, before anyone authorises payment. Every movement must be explainable from a list of joiners, leavers and authorised changes.
A payroll movement you can actually explain
Do the same for gross, total deductions and net. If a number moved and you cannot name the joiner, leaver or authorised change behind it, stop the run. Unexplained movements are how a leaver stays on the payroll for four months.
The most common finding is not fraud. It is a leaver processed at the point of noticing rather than the point of leaving, an overtime claim double-counted because it arrived twice through different channels, or an allowance that was agreed verbally and applied by one person's memory. All three are visible in a four-number comparison and invisible in a payslip-by-payslip review.
What we do and do not do
What AWRA OpsHub does today
- PAYE, NSSF, SHIF and housing levy computed as separate components, each on its own basis.
- Date-effective statutory rule sets — payslips compute on the rules of their own period, and historical periods stay reproducible.
- P9 certificates per employee per year, generated from finalised payslips.
- Attendance and leave feeding the run as captured records rather than re-keyed inputs.
- Approval separate from preparation, with an audit trail over pay and deduction changes.
- Cost allocation to department, project or grant, posted into the same ledger as every other outflow.
What it does not do
- We do not submit to iTax, NSSF or SHA portals. Filing is your process; we produce the figures and the reports behind them.
- We do not set or interpret the rules. Bands, tiers, thresholds and bases are the authorities' domain and your accountant's call.
- We do not advise on employment law — contract terms, terminations and disputes are for your HR adviser or advocate.
- We do not chase your deadlines. Remittance timetables remain yours to run.
Rates and rules change. Confirm current PAYE bands, NSSF tiers, SHIF and housing-levy rules with KRA, NSSF, SHA or your accountant before relying on any figure here or in the product. This is not tax or legal advice.
Remittance is a separate discipline
Computing a deduction and remitting it are two different jobs, and the gap between them is where liabilities accumulate quietly. Each period, tie what was deducted to what was actually remitted, per obligation. A discrepancy caught in one period is administrative; the same discrepancy caught in twelve has become a balance you owe with company money.
This reconciliation is unglamorous and nobody enjoys owning it, which is exactly why it should be a scheduled task with a name against it rather than something that happens when there is time. The wider statutory calendar is laid out in the Kenya compliance calendar — treat the deadlines as fixed and confirm them against the authorities, because they do shift.
Our take
Judge Kenyan payroll software on one demo request: re-open a payslip from before the last rate change and show it still computing on the old rules. Everything else — bands, tiers, bases — is arithmetic any vendor can claim. Reproducible history is the thing that makes an employee query, an audit or an inspection a five-minute conversation instead of a week.
See a payroll run you can reproduce
PAYE, NSSF, SHIF and housing levy on date-effective rules, attendance and leave feeding real inputs, P9 certificates, and cost allocated where the work happened.
Explore AWRA PayrollFrequently asked questions
Does the system file our PAYE returns to iTax?
No. It computes PAYE, NSSF, SHIF and the housing levy and produces the figures and supporting reports, including P9 certificates, but submission to iTax, NSSF or SHA remains your process. Ask every payroll vendor this question specifically, because "handles Kenyan statutory payroll" and "files your returns" are very different claims and they are often priced as though they were the same one.
What happens to old payslips when a statutory rate changes?
They keep computing on the rules that applied when they were produced. Statutory rules resolve by country and period, and a payslip carries the rule version it was calculated under, so re-opening a payslip from an earlier period reproduces what the employee was actually paid rather than retro-fitting today's rates. This is the property that makes an employee query or an inspection straightforward, and it is worth testing explicitly in any demo.
Are the statutory rates kept up to date for us?
The rule sets are maintained for Kenya, which is the one country where we do this rather than asking you to configure it — and it is why our guides for Nigeria, Ghana, Uganda, Tanzania and Rwanda recommend local payroll specialists instead. That said, rates and rules are set by the authorities and change, so confirm current figures with KRA, NSSF, SHA or your accountant rather than treating any software as the source of truth on tax.
How do we stop leavers being paid after they have gone?
Process the exit on the leaving date rather than when someone notices, and run a four-number reconciliation before approving every payroll: headcount, gross, deductions and net compared against the previous period, with each movement explained by a named joiner, leaver or authorised change. Leavers still on payroll is the most common and most expensive payroll error in every market we work in, and this ten-minute check catches it reliably.
Can one person prepare and approve payroll?
They should not, and the system supports separating the two. Payroll is the process where separation of duties matters most, because the preparer controls both who gets paid and how much. In a genuinely small team where the roles cannot be separated, make the audit trail the compensating control, have an owner or director review the pre-approval reconciliation, and document that reasoning — an auditor responds far better to an acknowledged constraint than to a pretended separation.
