Preparing payroll for JSL

Joint and several liability changes the question an umbrella company has to answer. It is no longer only “did we run payroll correctly?” but “can we show, on demand, that we did - to a party who is now exposed to our mistakes?”

That is a different operational problem. Running payroll correctly is a calculation exercise. Proving it is an evidence exercise, and evidence is very hard to reconstruct after the fact from spreadsheets, email threads and a payroll system that records outcomes but not decisions.

Where reconstruction fails

Most umbrella operations can produce a payslip and an FPS. Far fewer can produce, for a given pay run, the answer to all of the following at once:

• Which controls ran, and which of them passed, needed review or blocked.
• Who approved an exception, when, and on what basis.
• What the PAYE and NI liability was, and whether the funds to meet it were held.
• Which version of a rate, contract or right-to-work document was current at the moment of calculation.

None of those are exotic. They are simply not things a system records unless it was built to record them while the work was happening.

Compliance should happen during payroll - not be reconstructed afterwards.

A practical starting position

Before changing any system, it is worth establishing where your current evidence actually lives. Pick one recent pay run and try to assemble the four items above without asking anyone to remember anything. The gaps you find are the specification for what needs to change.

• Map the controls you rely on, and mark which are enforced by a system and which by a person remembering.
• Identify every point where data is rekeyed between systems - each is a place evidence breaks.
• Agree who owns each control, and what the escalation is when one fails.
• Decide what your retention period needs to be, and whether your current tooling meets it.

That exercise is useful whatever software you run. It tends to be uncomfortable, which is generally a sign it was worth doing.