Skip to main content
Every time you approve a payroll run, Hitaji 360 recognises the statutory amounts you owe the authorities — the PAYE you withheld for URA, the NSSF (employee and employer) you owe the fund, the LST you collected — and parks each in its own payable account. Remitting is the act of actually paying that money over to the authority and clearing the payable. This page is where you do it. There are two surfaces: the statutory remittances screen on a run, where you build and pay the period’s liabilities, and the statutory deductions report, a read-only matrix you use to prepare your filings. You’ll find this at: /payroll/:id/statutory-remittances (from a run). The report is at /payroll/reports/statutory.
📷 Screenshot: the statutory remittances page with the Pending/Paid totals and a “Pay” action on a pending row — to be added.
Multi-business: remittances belong to one business and post to its accounting book. The screen refuses to show or pay another business’s liabilities. Confirm the business switcher first.

​
Employer vs employee statutory

A common source of under-payment is forgetting the employer side. For NSSF in particular there are two contributions: the employee’s portion (withheld from pay) and the employer’s portion (an additional cost to the business). Both are credited to the same NSSF payable at run approval, and Hitaji 360 builds the remittance from both arms together — so the amount you pay over is the full liability, employee plus employer, not just the part deducted from payslips. PAYE and LST are employee-side withholdings.

​
Building the remittances

Open Statutory remittances from an approved (or paid) run. The run must be linked to a payroll period. Choose Build remittances to materialise the period’s liabilities as payable rows — one row per statutory kind (PAYE, NSSF, LST, and any other statutory item) for that period. Each row shows: Building is idempotent — re-running it never duplicates rows; a kind already built is left as is.
Period-scoped, not date-scoped. The build sums each statutory liability by the payroll period the run belongs to (not by when the run happened to be processed). This means a run processed late — for example May’s run finalised in June — still contributes to May’s remittance exactly once, and never bleeds into June’s. If you remit by period, your figures reconcile to the period regardless of processing dates.

​
Paying a remittance

On a Pending row choose Pay. The pay dialog asks for: Paying records the cash going out, stamps the row Paid with the reference and date, and posts the journal that clears the payable (see Behind the scenes). Paying is idempotent — re-submitting a paid row does nothing.

​
The statutory deductions report

/payroll/reports/statutory is a read-only matrix: one row per employee, one column per statutory component found in the date window, plus a per-component totals row at the bottom. Filter by a from/to date range and export to CSV. Use it to prepare returns and reconcile what you are about to remit. (The report shows the employee-side deductions; the employer contributions are still included in what you remit on the remittances screen.)

​
Permissions

Building and paying are gated on payroll:approve because they recognise and disburse real money to authorities.

​
Behind the scenes — the accounting

At run approval each statutory amount (employee and employer) is credited to its dedicated payable: paye_payable, nssf_payable, lst_payable. Those payables sit on your balance sheet as a liability until you remit. When you pay a remittance, the payable is cleared and cash leaves the business: So building never posts anything new — it just reads the liabilities already on the books and lines them up to be paid. Paying draws the payable down to zero for that kind and period.
If a remittance is for an amount that looks too low, check that the employer contribution was configured (e.g. employer NSSF rate) — without it, only the employee portion accrues to the payable. See Payroll settings.