Shift-based operations

Statutory rules are effective-dated rows per jurisdiction. A flat rule carries rates and a ceiling; a banded rule carries its bands for progressive tax; each names the wage base it applies to and the component it posts to. The employee’s side, the tax code or filing status, allowances and declared reliefs, is a verified record per employee per tax year. Implementation configures and verifies the rules and filing formats for the agreed entities and jurisdictions. This specification does not certify any jurisdiction or supply current statutory rates. A later change requires an effective-dated revision and repeat checks before use.

Yes. A pay calendar sets frequency, cutoff and pay day for a group of employees in an entity and generates its periods. Monthly salaried staff and weekly hourly staff run separately in the same entity, and their journals land in the same ledger month. Hourly staff carry an hourly rate on their compensation record.

Configured and tested device, mobile or web connections, imports or manual entry build daily attendance rows against the rostered shift. Approved leave marks the days, managers correct flagged rows, and hourly staff submit a timesheet with a line per day that the manager approves. At cutoff the attendance status, approved hours and shift premiums become inputs to the run with their source record as the reference.

An exit record runs notice and clearance, then a final settlement run pays to the last working day. It includes the terminal amounts approved by HR and applies configured entitlement, recovery and tax rules. Final settlement needs payroll approval, independent payment authorisation and journal posting. Agree former-employee access and retention during rollout.

Salary fields are visible to HR Managers, Payroll Officers and the Finance Controller. National ID and bank account are masked for everyone except HR Managers and Payroll Officers. A bank account change is a separate request tied to the exact verified proof. A Payroll Officer other than the requester matches the proof and proposed account before it becomes the current verified account. The preparer of a run cannot approve it, and the bank authoriser must be different from both the preparer and approver.