Skip to content
All guides

Payroll · Updated November 9, 2026

Payroll Workflow Guide

Prepare, calculate, review and complete payroll, then reconcile payments separately.

Access and preparation

Payroll requires the PAYROLL licence. Read endpoints use view_payroll; preparing and processing runs uses manage_payroll. Approval and M-Pesa disbursement use approve_payroll. Assign the read and action permissions needed by each operator.

Before calculation, review employee salaries, earnings, deductions, approved attendance, approved unpaid leave and the holiday calendar. Salary structures carry pay frequency; the calculator can convert salary frequency, but pay runs must be monthly. Other run frequencies are rejected at calculation.

Eligible employees include active, on-leave, and employees terminated during or after the period start. Salary lookup can fall back to the employee's base salary. An employee whose Include in Payroll setting is off is left out of every run. It is listed as skipped only when it has one-off lines on the run. Inspect skipped employees instead of assuming every employee was paid.

Workflow

Before your first run

CheckWhere to startWhat to review
Employee payEmployee profile and salary settingsSalary amount, frequency, hire date and any termination date
Earnings and deductionsPayroll → Salary SetupAllowances, bonuses, recurring deductions and their effective dates. Bulk Assign and Import from file add lines for many employees at once; the Payslip calculator previews net pay for a monthly gross
OvertimeAttendance policiesAn active overtime rule and the intended payment basis
Working timeTime & Attendance → AttendanceApproved hours and outstanding correction requests
Leave and holidaysLeave requests and attendance policiesApproved unpaid leave and the holiday calendar
Approval accessRoles & PermissionsWho prepares the run and who can approve it

Create and calculate

Open Payroll → Pay Runs, then New Pay Run. Give the run a recognisable name, such as “September 2026 Payroll”. Set the period start and end to the month being paid, and the payment date to the intended payment day. Use Monthly frequency. Leave Supplementary off for an ordinary monthly run.

Creating the run saves a draft; it does not calculate pay or send money. Open the run's detail page to calculate it, then follow the status sequence below. Only one pay run per company calculates at a time. If you see an "in progress" message, wait a moment and try again.

draft -> calculating -> calculated -> reviewing -> approved -> processing -> completed
                                                                           |
                                                                           v
                                                                        reversed
  1. Create a run with name, period start/end, payment date, frequency and optional Supplementary flag. Regular runs cannot overlap another non-reversed regular run. Supplementary permits overlap, so you can pay people the regular run left out, or pay a bonus, back pay or a correction (see Bonuses, back pay and corrections).
  2. Calculate the draft. The service gathers salary, earnings, deductions, attendance, leave, holidays and effective tax configuration, then stores employee line items and totals. Recalculation replaces previous items.
  3. Preview, when useful, computes projections without saving pay-run items. Review skipped employees here too.
  4. Submit for Review from calculated status. Inspect line items, totals and variance flags. Use Anomaly check on a calculated, reviewing, approved or completed run to list findings from fixed payroll rules, not AI: pay that moved more than usual since the last completed regular run, a new hire or someone with no earlier pay to compare, overtime that is a large share of basic pay, a missing NSSF, SHIF or Housing Levy deduction, a deduction line that dropped off since the last run, PAYE that changed while gross pay held steady, a new earnings line that is a large share of basic pay, and two or more people paid to one bank account or M-Pesa number. On a supplementary run only the shared account check runs. Findings are advisory and do not block approval.
  5. Approve from reviewing status with approve_payroll. When the company turns on Require a separate approver for pay runs (Company Settings → Settings, Payroll Settings tab), nobody can approve a run they created or on which they added, changed or removed a one-off line, and nobody can add, change or remove a one-off line on their own employee record. This setting defaults off.
  6. Process Payroll on the approved run. Processing runs asynchronously, using the background worker where configured or the in-process path. Refresh/poll until completed. Completion produces payslips and journal entries; it is not proof that employees have received money.

Per-employee calculation validation failures, including negative net, are reported as skipped employees while other employees continue. Systemic failures still abort; if all employees fail calculation, the run returns to draft. Always check employee count and skipped reasons before approval.

Review and recalculation

Variance flags compare against the most recent completed regular run (a supplementary run is never the baseline): gross/net changes over 10%, basic salary over 5%, and deductions over 15%. A first-time employee has no prior comparison. Flags are advisory.

Compare gross against salaries and earnings, deductions against the actual breakdown, net against funding requirements, and employer cost against gross plus employer contributions. There is no reliable fixed deduction percentage for every employee.

To recalculate a reviewing run, use Send Back to return it to calculated, then Revert to Draft. An approved run can use Send Back to return to reviewing before processing. Processing failure returns the run to approved for retry.

When a run is calculated, people with approve_payroll get an alert. If it has setup warnings, left-out employees, or net pay that moved more than 10% from the last run, payroll staff get one more. A run that is not approved 3 days before its payment date raises another. See Alerts & Notifications.

Payslips, accounting and payment

Processing creates payslip snapshots and balanced journal entries. The payslip number uses the period-end date and a sequence (PS-YYYYMMDD-0001); a supplementary run adds its place among that period's supplementary runs (PS-YYYYMMDD-S1-0001), and a regular run that replaces a reversed one adds its place among that period's regular runs (PS-YYYYMMDD-R2-0001), so no two payslips share a number. Display/PDF serving hides zero-value line items while preserving the stored snapshot. Employees can access payslips through self-service; payroll also has download/email actions.

Journal entries cover salary expense, employer NSSF/Housing Levy/NITA expense, PAYE, NSSF, SHIF, Housing Levy, NITA and other deduction liabilities, and net pay payable.

These entries stay in Arche unless you connect an accounting system. With the Accounting module, a completed or reversed run can be posted into Xero or QuickBooks Online as one balanced journal against your own chart of accounts. See Accounting Integration.

Pay employees separately through the bank EFT file or M-Pesa disbursement. M-Pesa requires a completed run and approve_payroll; it is not automatically initiated by Process.

On a completed run, open the Bank File menu and pick the bank whose portal you upload to, not the bank your staff use. Arche then splits the run into internal transfers and transfers to other banks (EFT), which banks charge as separate batches. Download them as two files, or as one combined file. An employee whose bank routing code is not 5 digits (a 2-digit bank code plus a 3-digit branch code) is in neither batch, and the menu names them; fix their routing code before you download. Arche prepares the file; it does not move funds.

Reversals and corrections

Reverse a completed run with a reason. A run that supplementary top-ups were taxed against cannot be reversed while those runs stand: reverse the supplementary runs first (or send them back to draft if they are not completed). The original payslips and journal entries remain; reversal posts offsetting journal entries and marks the run reversed. Pending or successful M-Pesa disbursements block reversal. Reconcile payment attempts before deciding how to correct a paid run.

A supplementary run allows an overlapping period. When it has no one-off lines, it pays the people the other runs left out, such as a late joiner, and for them it runs the regular calculation pipeline: full salary, every recurring earning and deduction, and a fresh set of reliefs and statutory caps. In any run, regular or supplementary, anyone already on another non-reversed run for an overlapping period is skipped and named with the run that paid them, unless they have one-off lines on a supplementary run (below). A run where nobody can be paid will not calculate.

Bonuses, back pay and corrections

To pay someone more for a month they have already been paid, use one-off lines on a supplementary run:

  1. Complete the regular run for the month first. A top-up is taxed on what that run withheld, so an employee whose other run for the period is not completed is skipped and named.
  2. Create a supplementary run for the same period, with a payment date in the same month as the regular run's payment date, and open it. The PAYE return groups runs by payment date, and a top-up is taxed with the pay it tops up, so the two must land on the same return. If your June run was paid on 3 July, pay the June bonus in July too. A run that would pay top-ups in another month than the runs they top up will not calculate.
  3. While it is a draft, add lines under One-off lines: pick the employee, choose Earning (a bonus, back pay, an allowance owed) or Deduction (a one-off recovery taken from net pay after tax), and enter a code, the name that prints on the payslip and the amount. Untick Taxable for an earning that is not pay, such as an expense refund; it is then outside PAYE, NSSF, SHIF and the Housing Levy.
  4. Calculate, review and approve as usual. Lines can change only while the run is a draft; send it back to draft to edit them.

An employee with lines who is already paid for the period becomes a top-up: the run pays only their lines, with no salary or recurring items, and charges each statutory amount on the month as a whole less what the other runs already deducted:

  • PAYE is the tax on the month's total taxable pay, less the reliefs the month already granted, less the PAYE already withheld. No second personal relief is given, so the extra pay is taxed at the employee's top band. If the regular run paid nothing (a full month of unpaid leave), it granted no relief, so the top-up grants the month's personal relief once.
  • NSSF is taken only up to what is left of the monthly limit. Someone whose regular run reached the limit pays no more NSSF.
  • SHIF is 2.75% of the month's total gross less what was already paid. The KES 300 minimum is not charged a second time.
  • Housing Levy is 1.5% of the extra taxable pay, for the employee and the employer.
  • NITA was charged by the first run and is not charged again, unless that run paid nothing: then the top-up charges it.

For example, an employee on KES 100,000 a month paid in the regular run and given a KES 50,000 bonus has KES 480 NSSF (the rest of the KES 6,480 limit), KES 1,375 SHIF, KES 750 Housing Levy and KES 14,218.50 PAYE taken from the bonus. The pay run line shows the month figures it used.

An employee with lines whom no other run paid is calculated in full, with the lines added. An already-paid employee with only deduction lines is skipped: there is no pay to take them from, so recover the amount in the next regular run. A supplementary run that has one-off lines pays only the employees with lines: anyone else the regular run left out is not paid by it. To pay a late joiner their salary, use a supplementary run with no lines, or give them a line on the bonus run. Check the preview before you calculate.

Codes the engine or the statutory returns already use cannot be used for a one-off line (for example BASIC, PAYE, NSSF, SALARY_ADV, a pension or insurance code on a deduction, or a non-cash benefit code on an earning). To take back money from a payslip already paid, reverse the run and pay the period in a new one, or add a deduction in the next regular run.

How gross-to-net works

  1. Convert the salary frequency, then prorate salary using active calendar days divided by total period calendar days. Monetary rounding happens after applying the full ratio.
  2. Subtract approved unpaid leave using the prorated salary divided by working days in the active sub-period. Working-day counts use the rule's working-days-per-week setting and holidays.
  3. Add fixed/percentage earnings and any payable overtime. Non-taxable earnings remain in gross payout but are excluded from chargeable earnings used for statutory contributions and PAYE.
  4. Subtract employee statutory pre-tax contributions and eligible custom pre-tax deductions to calculate taxable income.
  5. Calculate PAYE, then apply personal and qualifying insurance relief.
  6. Subtract post-tax deductions, apply the configured deduction cap, and compute net and employer costs.

Overtime

Payroll reads approved attendance. An active overtime rule is required for overtime pay, even when recorded overtime hours exist. Its normal daily hours and working-days-per-week determine expected period hours and the hourly rate.

premium_only adds hourly rate times (multiplier minus one) times overtime hours. full_rate adds hourly rate times the full multiplier times hours. Rest-day mode is configurable; Saturday/Sunday classification is only the weekend default. See Time & Attendance.

Overtime an employee took as leave is not paid in the run. The payslip shows an information line, Overtime taken as leave, with the hours and no amount. If the employee leaves with converted hours unused, they are paid at termination on an Overtime returned from leave line. See Taking Overtime as Leave.

Implemented Kenya defaults

These tables describe the fallback code in the Kenya PAYE engine, not a guarantee of current legal requirements. Effective company configuration can override tax brackets and statutory rates; verify the saved values used for the run.

You do not need to add tax brackets or statutory rates to follow these defaults. The NSSF limit is stored with the date it took effect, and a pay run uses the limit in force on its period end date.

Payroll checks your setup before every calculation and on the Salary Setup page:

  • It will not calculate on a setup that cannot give a correct result: a custom tax band set that does not start at 0, has a gap or an overlap, or has no last band without an upper limit; a rate above 1 (type 6% as 0.06); a negative amount. The message says what to correct.
  • It warns when a rate you added differs from the default, and when your rate is dated before a change to the default. The warning shows both values and both dates, and it stays on the pay run for whoever reviews and approves it.
  • A rate you added stays in force until you change or delete it.
Monthly PAYE band as configured (KES)Rate
0 to 24,00010%
24,001 to 32,33325%
32,334 to 500,00030%
500,001 to 800,00032.5%
800,001 and above35%
ContributionEmployee defaultEmployer default
NSSF6%, capped at KES 6,480 monthly; pre-tax6%, same cap
SHIF2.75%, minimum KES 300 monthly; pre-taxNone
Housing Levy1.5%; pre-tax1.5%
NITANoneKES 50 monthly

Personal relief defaults to KES 2,400 monthly. Insurance relief uses qualifying premiums, at 15% capped at KES 5,000 monthly; SHIF is not itself the insurance-relief premium base. Custom pre-tax pension/retirement/provident deductions share a KES 30,000 monthly cap; PRMF uses KES 15,000 and mortgage/owner-occupier interest KES 30,000.

Worked example: KES 100,000 monthly gross

This example uses the defaults above for a full month, with all earnings taxable, no custom deductions and no qualifying insurance premiums. It illustrates the calculation; use your actual run breakdown when company rates or employee inputs differ.

StepAmount (KES)
Gross pay100,000.00
Employee NSSF−6,000.00
SHIF−2,750.00
Employee Housing Levy−1,500.00
Taxable income89,750.00
First 24,000 at 10%2,400.00
Next 8,333 at 25%2,083.25
Remaining 57,417 at 30%17,225.10
Gross PAYE21,708.35
Personal relief−2,400.00
PAYE after relief19,308.35
Total employee deductions29,558.35
Net pay70,441.65

The company also pays KES 6,000 employer NSSF, KES 1,500 employer Housing Levy and KES 50 NITA. Total employer cost is KES 107,550.00. These employer contributions are additional company costs, not further deductions from the net pay above.

Deduction cap

The fallback cap ratio is two-thirds of gross, configurable through an effective DEDUCTION_CAP statutory-rate row. If total deductions exceed it, the engine reduces custom post-tax lines, salary-advance recovery first. It does not reduce statutory, PAYE or pre-tax lines. Consequently the cap does not guarantee one-third take-home when protected lines already exceed the ratio.

Stored breakdowns and repayment events use the amount actually deducted. If the cap trims a salary-advance recovery, the unpaid part stays on the advance balance, and later runs keep taking the monthly instalment until the balance reaches zero. For any other deduction, a trimmed amount is not collected later; follow it up yourself. See Salary Advances.

Frequently asked questions

An employee is missing from the calculated run. What should I check? Review the skipped-employee reasons, employee status and employment dates, and salary configuration. A run can finish calculating even when individual employees were skipped. Resolve those issues and recalculate before approval.

Why is recorded overtime missing from pay? Check that the attendance is approved, an overtime rule is active and its payment basis and multipliers match your policy. Recorded overtime hours alone do not establish overtime pay.

Can I change a run after review? Return it through the allowed statuses to draft before recalculating. Recalculation replaces its previous items. For a completed run, use the reversal/correction workflow described above.

Does a completed run mean everyone has been paid? No. Completion creates payslips and accounting entries. Reconcile your bank or M-Pesa payment separately before treating salaries as received.

Why was a deduction smaller than the configured amount? Inspect the payslip breakdown and deduction-cap handling. If the cap trims a salary-advance recovery, the unpaid part stays on the advance balance, and later runs keep taking the monthly instalment until the balance reaches zero. For any other deduction, the trimmed amount is not collected later, so follow it up yourself.

Where do I get the monthly statutory schedules? Open Payroll → Statutory Reports after completion. Check the payment month, which determines the runs included. See Reports & Statutory Filings.