Insights
Insights · Awareness

Why Unit4 payroll defects survive go-live

Buying stage: awareness

The Unit4 payroll went live and the scripts passed. Two years on, the same defects are open. A passing script proves the system accepted an entry. Only a calculation checked against a known-correct answer proves the payment is right.

01

What a parallel run proves about a Unit4 payroll

A parallel run is the best evidence a payroll implementation can produce, and it proves less than most project boards assume.

It runs pay group by pay group, comparing new-system output with the legacy calculation for a real period and population, and proves parity for the employees, elements and statutory events inside that window.

Everything outside the window stays unproven. The court order that starts next quarter. The back pay that follows a pay award settled after cutover. The honorarium, the special allowance, the overpayment recovery alongside a statutory payment. The sickness that moves from full to half to nil pay in a period the run never reached. The year-end patch not yet applied. None is a testing failure. Each was out of scope. Unless that is written down, the board reads it as proven.

02

What a script pass proves

User acceptance testing runs in phases across the full HR and payroll process set: position administration, applicant, starter, induction and probation, then absence, occupational health, leaver and contractual change, then loans, deductions, pensions and court orders. Done properly, it proves every route a real case can take has been walked once.

It does not prove arithmetic. A tester records a pass when the screen accepted the entry, the workflow routed and no error appeared. Payroll asks whether each pay and deduction element produced the right value against a known-correct reference, in the right period, against the right cost code.

Bear Consulting Services therefore writes the expected value before the script runs, by hand or from the legacy system, and compares to the penny. Conditional elements, half-pay and nil-pay transfer on long-term sickness, back pay spanning a pay award, a deduction that interacts with a statutory payment: none of these shows at screen level. They show only in the comparison.

03

Triage by payroll impact

The defect lifecycle is simple: identification, triage, severity categorisation, assignment, fix verification and closure, in whatever issue tracker or service desk the programme already uses. Severity is where it fails.

Bear Consulting sets severity by what the defect touches, in this order: a payment to an employee, a statutory submission, a deduction owed to a third party, then a report. A defect that under-pays twelve people once a year outranks one that annoys forty managers every week. On a queue sorted by ticket age it loses every time.

The backlog still carried two years later is mostly defects that were real and logged, never severe enough to be scheduled against a release date, and then aged into normality.

Triage works best live. One web migration workshop identified, root-caused and resolved four defects in one session, with the people who could reproduce the behaviour and the person who could read the configuration in one room.

04

The residual-risk statement

A project board asked to authorise a payroll cutover is usually given a status colour. It needs a residual-risk statement with four parts: what was tested and passed, what was deliberately left untested and why, what remains open and at what severity, and which compensating control covers each open item for the first live cycles.

A board can accept and minute that list for a stated number of pay periods.

Two items belong on almost every list. The first is the statutory calendar: year-end and statutory patches land on their own timetable, and each needs its own test plan before the live run. A patch applied three months after go-live is the most common source of a defect with no apparent cause. The second is the population the parallel run could not reach, listed by name and pay group, not as a caveat.

Go-lives with no critical defects outstanding come from parallel payroll testing and regression validation run hard enough to find the problems in time, and from a board told what remained.

05

Worked example: proving a payroll for over 2,500 employees

At an international organisation, payroll, absence, expenses and timesheets were unproven, with no evidence base on which to sign a go-live.

As HR and payroll lead consultant, Mircea Rogojan-Rush designed and ran a parallel run for every pay group. A defect register carried resolution rates to the project board. A test completion evidence pack took a quantified residual risk assessment into the go-live decision.

Parallel runs proved calculation parity across over 2,500 employees.

The case study describes the engagement in full.

06

Next steps

Three places to go from here.

  • Read the worked example. The parallel run, the defect register and the evidence pack behind one go-live decision: proving a payroll for over 2,500 employees.
  • Run the free Unit4 health check. Twelve questions across the six areas a Unit4 X-Ray assesses, scored on the page: the Unit4 health check.
  • Read the diagnostic brief. The Unit4 X-Ray is where Bear Consulting applies this to your Unit4 system, as a fixed-scope consultancy engagement.
07

Contact

A Unit4 payroll that went live with defects still open calls for a scoped conversation, not a project.

Bear Consulting will say what it would check first.