Payroll preparation vs payroll processing for staffing agencies

“Does it do payroll?” is the question every staffing software vendor gets asked, and the honest answer is nearly always “which half?”. Two genuinely different jobs hide behind the one word, and agencies that conflate them either buy a workforce tool expecting it to file taxes, or buy a payroll bureau expecting it to understand shift work. Both mistakes are expensive.

The two jobs behind “payroll”

Payroll preparation is the operational half: turning what actually happened on your events into correct gross-pay numbers. It answers: who worked, for how long, at what rate, with what adjustments — and it produces a locked, exportable record of the result. This half lives where your scheduling and timesheets live, because that is where the facts are.

Payroll processing is the statutory half: PAYE and National Insurance calculations, RTI submissions to HMRC, pension auto-enrolment, payslips, and moving actual money to workers. This half lives with a payroll provider, bureau, accountant or dedicated payroll system — specialists whose whole job is keeping up with tax rules.

Where pay errors actually come from

Here is the operational reality: by the time numbers reach the statutory half, the damage is usually already done. The classic agency pay dispute is almost never a tax miscalculation — providers are good at tax. It is a preparation failure:

• hours re-typed from a spreadsheet with a finger slip,
• an unapproved timesheet paid, or an approved one missed,
• the wrong rate applied because someone’s rate changed mid-month,
• overtime or allowances worked out differently by two coordinators,
• the same shift accidentally paid twice across two pay runs.

So the useful question when evaluating tools is not “does it do payroll?” but “does it make the preparation half boringly reliable?”.

What a clean preparation-to-processing handoff looks like

• Pay starts from approved time. Only approved timesheets enter a pay run — not raw clock data, and not memory.
• Rates are frozen with the work. The rate that applied when the shift was worked is the rate that pays it, even if the rate card changes later.
• Runs lock. Once a pay run is checked and locked, its lines stop moving. Late corrections happen as a deliberate reopen, with a trail — not as silent edits to a spreadsheet.
• A shift is paid once. The system, not a coordinator’s concentration, guarantees a worked shift cannot drift into two runs.
• The output is an export, honestly labelled. The deliverable is gross-pay data — a CSV your payroll provider or finance team takes forward into the statutory half.

This is exactly the boundary Keruja is built to: it runs gross-pay preparation and payroll exports from approved hours and frozen rates, and deliberately stops there. Keruja does not calculate PAYE or National Insurance, does not submit RTI, does not produce payslips and does not pay your workers — your payroll provider does, from numbers that finally arrive clean.

Questions to ask any vendor (including us)

Whatever tools you choose, keep the boundary explicit in your own head: preparation where your operations live, processing with the specialists, and a clean, locked export between them. Plans and what’s included in every Keruja plan are public if you want to see where we draw that line.