Payroll that starts from attendance, not a spreadsheet.
Payroll that starts from verified attendance and approved changes — so the run is a calculation, not an investigation.
Most payroll pain is not caused by the calculation. It is caused by the inputs: attendance that arrived late, a change nobody approved, a record missing an identifier, a rate that changed mid-period. PiPO HRIS Payroll is built directly on top of the records that produce those inputs — the employee record, the attendance ledger and the leave balance — so by the time the run opens, the numbers going into it have already been verified by the people who are accountable for them.
Why payroll day is the day everything surfaces
A payroll team spending the first week of the month reconciling is not a payroll problem. It is a data problem arriving late.
- Attendance is still being chased on the morning of the run.
- A change to someone's pay was made in a spreadsheet and never approved.
- A missing KRA PIN is discovered inside a formula rather than on a record.
- Nobody can explain why the total moved, only that it did.
- Corrections are made in the payroll file, so the source records stay wrong.
- The statutory position is assembled after the fact, from three exports.
The run opens on inputs that are already verified
Attendance closes and leave reconciles before the cycle opens. Changes to pay elements carry an approver and a date. Records with incomplete statutory identifiers are visible as a held list rather than as a failure mid-run. The pre-run checks are not advisory — the run cannot be locked until they pass.
- Attendance, leave and change approvals close before the cycle opens
- Every change to a pay element carries who approved it and when
- Records with missing identifiers are held, listed and explained
- Variance against the previous period attributed to a cause, not just reported
- The run is locked on approval, and corrections go back to the source record
What the payroll module handles
Configured to your pay structure during implementation — including which elements are taxable, which are pensionable, and how each behaves in a mid-period joiner or leaver.
Earnings
- Basic pay and salary structures
- Overtime from approved attendance
- Allowances and recurring additions
- One-off payments and arrears
- Daily-rate and casual earnings
Deductions
- Statutory deductions
- Loans and advances with balances
- Voluntary and third-party deductions
- Court and welfare orders
- Deduction limits and priority
Outputs
- Payslips, by employee
- Payment file for the bank
- Statutory schedules and filing extracts
- Payroll register and journals
- Cost allocation by department or site
On statutory calculation. Statutory deduction handling is configured per implementation against the rules that apply to your organisation, and the configuration is reviewed with you before go-live. Where rates or thresholds change, the configuration is updated as part of ongoing support. We do not claim that every statutory scenario in every sector is automated out of the box — what applies to you is confirmed during scoping.
Payslips employees can get themselves
Most payslip requests are not disputes. They are people needing a document for a loan, a landlord or a visa application. Self-service removes that queue entirely, and gives employees the year-to-date position that usually prompts the second question.
- Payslips available to the employee as soon as the run is released
- Year-to-date earnings and deductions
- Historical payslips retained and downloadable
- Fewer requests arriving at the payroll desk in the last week of the month
Payroll day should be a calculation,
not an investigation.
Everything in this module is arranged around that one idea: fix the inputs, and the run stops being the week of the month everybody dreads.
What changes
Common questions
It works best that way, because attendance becomes a verified input rather than a submitted one. It is not a requirement — payroll inputs can be loaded from an agreed structured format where attendance is captured elsewhere.
Pro-rating rules are configured to your policy during implementation, including which elements pro-rate and which do not, so a mid-period movement is handled consistently rather than decided case by case.
Yes. Organisations commonly run a monthly payroll for permanent staff alongside a separate cycle for casual and frontline workers, in the same environment and against the same employee records.
The run is locked, so the correction is made on the source record and carried through the next cycle or a formally raised adjustment. That keeps the approved history intact and the audit trail honest.
Payment file formats are configured per implementation to match the banks you actually use. The specific format is confirmed during scoping.
Bring us your worst payroll month.
We will walk through what PiPO HRIS would have caught before the run opened, and what it would still have needed from you.