Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Tax rates change. Finance Acts amend thresholds. A payroll system that recomputes history against today's rates will hand your employee a P9 that disagrees with the payslips it was built from. AWRA OpsHub rebuilds every certificate from frozen snapshots and the exact rule versions each payslip used — so a reprint is a reproduction, not a recalculation.
Versioned law data that freezes when used · P9A certificate and PDF · Encrypted payout details · Every decrypt audited
| Month | Gross | Taxable | Relief | PAYE |
|---|---|---|---|---|
| Jan | 88,100 | 80,100 | 2,400 | 17,442 |
| Feb | 88,100 | 80,100 | 2,400 | 17,442 |
| Mar | 92,400 | 84,400 | 2,400 | 18,732 |
| Apr | 88,100 | 80,100 | 2,400 | 17,442 |
| … | eight further months | |||
| Year | 1,061,500 | 965,500 | 28,800 | 210,594 |
This is a deliberate separation. Your allowances and deductions are yours to configure. Tax bands, social security rates, health insurance and levies are law — and treating them as a workspace setting is how a payroll ends up with a tax rate somebody changed to make a number look right.
income_tax Progressive bands, a personal relief amount, and a computation order that always puts it last — because it depends on everything else.
social_security Tiered contributions with their own ceilings, applied to the pensionable base rather than to gross.
health_insurance Its own rate and its own base, with minimum and maximum caps where the law sets them.
local_levy For the housing and training levies that sit outside the other three, each with its own basis.
Not by editing a number. By sealing the old version and opening a new one.
Its bands and thresholds are exactly as they were. Payslips that used it still point at it and still reproduce from it.
Its effective-to date is set to the day before the next version begins, so the timeline has no gap and no overlap.
A new version with the amended numbers and its own effective-from date — the day the change takes legal effect, not the day somebody typed it.
And the freeze is enforced, not merely advised. The mechanism that loads rule data refuses to write over a version that real payslips have already referenced. It will happily add a new version, and it is safe to re-run as often as you like, but a published rate is not editable — which means the arithmetic behind a payslip issued three years ago cannot be quietly rewritten by a well-meaning update today.
Every payslip line for a statutory deduction stores the identifier of the exact rule version it was computed from. That is what makes a P9 reproducible and what makes a payroll query answerable: you can point at a deduction and say precisely which set of bands produced it.
Seeded rates are worth nothing if nobody has ever checked them against reality. Kenya's income tax, social security, health insurance and housing levy figures were reconciled line by line against a real employer payslip — a gross of 71,789 producing exactly 14,112.54 of gross tax before relief.
Every band, rate and threshold the sample's pay actually reached:
Social security's second-tier upper ceiling. The sample employee's pay never reached it, so while the figure is taken from the published schedule, it has not been proven against an actual payslip the way everything else has.
We would rather say that than let you assume it carries the same evidence as the rest. If you employ above that threshold and want it independently confirmed before you rely on it, tell us and we will confirm it.
A correction that shipped, and why it is worth telling you about. An early social security version was seeded with a first-tier ceiling of 8,000. A real payslip proved it was 9,000. Because published versions are frozen rather than edited, the fix was a new version — and the wrong one was left in place, superseded and never in force for any real calculation, because deleting it would have broken the test payslip that referenced it. That is the version chain doing exactly what it exists for.
Rates change through Finance Act amendments. Kenya's figures are the configured jurisdiction today, and any other country's statutory rules are a matter of adding versioned data in the same shape — which is work we do rather than something you configure, precisely because it is law and not a preference.
It aggregates a full tax year of monthly PAYE for one person, for their own annual return — so it has to agree with every payslip inside it, permanently.
It is built entirely from frozen evidence. Each month's row is reconstructed from that payslip's stored line items and the statutory rule versions it referenced — never from live rates. That is what makes the document reproducible: print it now, print it in 2031 after four Finance Acts, and it is the same certificate.
The available years come from the payslips that actually exist, so the year selector offers what there is rather than an empty calendar. Figures are added with decimal-exact arithmetic rather than floating point, because a year of monthly rounding is exactly where a cent-level drift becomes a figure an employee queries.
view_payroll HR, for any employee Produces a certificate on screen and as an A4 landscape PDF, named for the year and the employee's own number, and viewable inline or downloadable.
self-service The employee, for themselves A separate route behind a separate, lower-trust permission — because being allowed your own tax certificate is not the same as being allowed everybody's.
work_country Scoped to the person, not the company Eligibility is checked on the employee's work country rather than the organisation's, because a business headquartered anywhere can employ people in Kenya — and those people are owed the certificate.
That last point is a small thing that reveals the whole approach. The buttons leading to a P9 are already hidden for employees who do not work in Kenya — but the URL is checked as well, so the address cannot be typed by hand to produce a Kenyan tax document out of a German employee's payslips. Two layers agreeing is the difference between a hidden button and a rule.
And the payroll engine underneath stays jurisdiction-agnostic. The P9 is a country-specific report layered on top of generic output, rather than Kenyan assumptions baked into the calculation — which is what makes adding another jurisdiction a matter of data and a report, not a rewrite.
Bank account numbers are the single most abusable field in an HR system. Someone who can read them can redirect a salary, and the theft looks exactly like a payroll run.
view_bank_detailsview_employees See that details exist The list of payout methods, masked, with the primary one marked. Enough to know somebody is payable without seeing anything you could misuse.
edit_employees Manage which exist Adding, removing and changing the primary — the ordinary employee-record grant, because managing which details exist is an ordinary HR edit.
view_bank_details See the actual number A separate, higher-trust grant, and the only one that decrypts. Every use is audited. This is the split that matters.
Why split those two apart? Because the HR administrator who onboards forty people a month needs to enter payout details constantly and almost never needs to read one back. Granting both together means everyone who does data entry can also harvest account numbers, and nothing in the system distinguishes the two activities. Splitting them means the read is rare, deliberate, permissioned and logged — and a decrypt at two in the morning from an unfamiliar address is a thing you can actually find.
The same treatment covers statutory identifiers — tax numbers, social security numbers, health scheme numbers. Encrypted at rest, displayed as the last four characters only, and revealed through the same audited path.
Two smaller behaviours worth knowing: the first payout detail you add is automatically the primary one, so nobody can be left payable-in-theory with no designated account; and deleting the primary promotes another rather than leaving an employee with details but no primary. Mobile money is a first-class method alongside bank transfer, with its own network and number, rather than a bank account with the fields used loosely.
When you post an approved run, AWRA writes a payment transaction for each payslip — routed to mobile money or bank according to that employee's primary payout method, referenced to the run and the employee, carrying the masked account it was directed to — and posts the accounting: payroll expense against payroll payable, then payable against bank.
What it does not yet do is instruct your bank or mobile-money provider directly. The transaction is recorded as settled, and the actual transfer happens through your existing banking channel. So the ledger, the payslips and the payments register all agree with each other and with what you paid — but the instruction to pay is still yours to send.
We are telling you this on a marketing page because it is the sort of thing that is far better learned now than on a payroll day. Direct payout rails are the natural next piece, and the seam is already drawn in the right place for them — the payment record, the routing decision and the masked destination all exist, waiting for a provider on the other side.
Statutory payroll is the least appropriate place in software for a vague claim, so here it is exactly.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Direct payout rails and additional jurisdictions are the two biggest items here, and both are additive rather than structural — the payment record and routing decision already exist for the first, and the versioned rule shape already exists for the second. Tell us your provider or your country and we will come back with a written spec, a timeline and a price.
Worth planning around on your first payroll day: posting a run records the payments as settled and posts the ledger, and the actual transfer still goes through your own banking channel. Everything reconciles; the instruction to pay is the part that is still yours to send.
Sealed rule versions, certificates rebuilt from frozen evidence, account numbers nobody can read without leaving their name — and a straight account of the one place the money still leaves by your own hand.