PAYE, NSSF, SHIF and Housing Levy: Kenyan Payroll Compliance Explained

Running payroll in Kenya means getting four statutory deductions right, every single month, without exception. Get one wrong and it’s not just an accounting error — it’s a compliance problem with KRA, NSSF, or SHA. Here’s what each one actually requires.

PAYE (Pay As You Earn)

PAYE is band-based income tax, deducted at source. The part that trips up generic payroll software isn’t the tax bands themselves — it’s how personal relief is applied. Personal relief is a fixed monthly amount subtracted from the tax calculated, not from taxable income before tax is calculated. Software that applies relief at the wrong stage of the calculation produces numbers that look plausible but are wrong, and the error compounds every payslip.

NSSF (National Social Security Fund)

NSSF contributions run on a two-tier structure:

• Tier I — contributions on pensionable pay up to the lower earnings limit
• Tier II — contributions on pensionable pay between the lower and upper earnings limits

Both employee and employer contribute matching amounts. The earnings limits are set centrally and change periodically, so payroll software needs to apply whatever the current limits are — not whatever was hardcoded when the system was built.

SHIF (Social Health Insurance Fund)

SHIF replaced NHIF as Kenya’s social health insurance scheme. Unlike NHIF’s old banded-amount structure, SHIF is a flat 2.75% of gross salary, with no upper cap. This is a meaningfully different calculation from NHIF, and payroll systems that were only ever configured for NHIF’s band table need real reconfiguration, not a patch.

Housing Levy

The Affordable Housing Levy is charged at 1.5% of gross salary from the employee, matched by 1.5% from the employer — 3% total, split evenly. Both halves need to be calculated, tracked, and remitted correctly.

Why this keeps catching businesses out

None of these four rules are exotic. Individually, they’re documented, public, and not particularly complicated. What causes problems is that most ERP and payroll software sold in Kenya was built for a different market first and Kenyan compliance was added afterward — as a configuration layer bolted on top, rather than a rule engine designed around these calculations from the start. That’s usually where the PAYE-relief-applied-in-the-wrong-place bug, or the NSSF-tier-boundary bug, or the “still calculating NHIF bands instead of SHIF’s flat rate” bug comes from.

It’s also why KRA reporting (P9A and P10 returns) and NITA employer levies need to be generated directly from the same payroll run that calculated the deductions — not reconciled separately afterward, which is where small discrepancies quietly become audit findings.

What we built RoyceERP around

RoyceERP runs on ERPNext, with this compliance engine built in as a first-class part of the payroll module rather than an add-on: PAYE with relief applied to tax (not taxable income), NSSF Tier I & II at current limits, SHIF at 2.75% of gross, Housing Levy split correctly between employee and employer, and P9A/P10 and NITA reporting generated from the same payroll run.

If you’re currently reconciling payroll numbers by hand every month to catch what your software gets wrong, that’s usually a sign the underlying calculation engine wasn’t built for these rules in the first place.

See how Royce ERP handles this →