Multi-country by design
Payroll is deliberately the last HR area to set up, because it touches money and carries statutory and legal liability — get employee and attendance data clean first, or you compute wrong salaries from wrong inputs. The defining architectural choice is that statutory rules — income tax, social security, health, and local levies — are region-scoped, versioned, effective-dated configuration, never hard-coded. Adding a country is a set of configuration rows, not a code change, and the calculation engine itself stays generic and jurisdiction-agnostic.
Versioning is what makes this trustworthy over time. Once a payslip has referenced a particular rule-set version, that version is frozen; a rate correction is published as a new version with its own effective date, and the old version stays exactly as it was. This is why a correction can never retroactively alter a closed run — the payslip keeps pointing at the rules that were actually in force when it was calculated. Kenya is the launch jurisdiction (PAYE bands and personal relief, NSSF, SHIF, and the Housing Levy), and it is the first data set, not the scope.
The practical consequence for an operator is that you resolve each employee's rule set from their work country and the pay period, and you never edit a published version's numbers in place. When rates change, you add a new version and set the previous one's end date. Carry this model forward: the engine is generic, the country is data, and versions are frozen once used.
Key takeaways
- Payroll is last because it touches money and statutory liability — clean employee/attendance data first.
- Statutory rules are per-country, versioned, effective-dated config; the engine is generic, the country is data.
- A published version referenced by a payslip is frozen; corrections are new versions, never edits.
- Kenya (PAYE, NSSF, SHIF, Housing Levy) is the launch data set, not the scope.