The row in the plan with no name on it
Every HCM programme I have reviewed had a line in the plan for configuration, a line for each integration, and a line for testing. Almost none had a line for the person who sits with two payroll registers, one from the old system and one from Workday or Oracle HCM, and works through the differences employee by employee until each has an explanation. That work decides whether the go-live is safe, and it is usually the smallest number on the plan.
The version I see most often reads parallel run support, two weeks, owner payroll team. The payroll team is three people who also have to run live payroll on the old system every fortnight for the whole parallel period. The first run produces several thousand lines of difference. They work evenings for a week, explain a third, and the steering committee gets a slide saying the parallel run was largely successful. Nobody in that room knows what the other two thirds were. A plan with that row unnamed has planned its build and has not planned its go-live.
Agree the tolerances before the first run, per pay element
A parallel run without agreed tolerances produces a list of differences and an argument. Every line is a defect until someone says otherwise, and the person saying otherwise is usually the consultant who configured the element, which is not a neutral position.
The categories repeat from programme to programme. Rounding, where the old system rounded an hourly rate at a different step than the pay component in Workday HCM or the element formula in Oracle HCM. Timing, where a retro adjustment landed in a different period. Migration, where a year to date balance or a rate was loaded wrong. Configuration, where the new element genuinely calculates differently. And legacy defects, where the old system has been paying someone wrong for years and the new one is right. That last category needs a decision from payroll and HR about what to tell the employee, which the programme cannot make for them.
What I put in front of the group is a single sheet, agreed before the first run. One row per pay element, the tolerance in currency or percentage, the expected sources of difference, and a name. Basic pay might carry a few pence per employee for rounding. Pension contributions might carry zero, because the scheme administrator will reconcile them independently. Tax carries whatever the opening year to date balances imply, and that number has to be known before the run. If the group cannot agree the sheet, the first parallel run will tell you nothing you can act on.
Matching totals hide offsetting errors
The reconciliation that fools programmes is the one done at the top. Gross pay agrees to within a small amount, net pay agrees, employer cost agrees, and the go-live is approved. Three months later overtime is overstated for one group of employees and a shift allowance understated for another, and in the parallel runs those errors happened to cancel.
Reconcile employee by employee and element by element, and use the total only as a check on that work. It takes longer, which is why the person doing it needs the hours. It is also where the matching key matters. The legacy system has an employee number, Workday an employee ID, Oracle HCM a person number, and if the programme has not settled which one carries across, a good share of the differences will be employees matched to the wrong person or to nobody. The advice on choosing a durable business key applies here word for word.
Year to date balances deserve their own pass, because a wrong opening balance produces a payslip that reconciles perfectly and an incorrect year end return months later. I ask for the migrated balances to be reconciled to the legacy system's final register as a separate deliverable with its own sign-off.
Finance needs to reconcile the posting, not the payslip
Payroll cutover reaches the ledger, and the ledger has a different audience with a different question. The controller does not care whether an individual payslip is right. They care whether the journal posted to Workday Financial Management or the corporate general ledger agrees by cost centre and account to what the old system would have posted, and whether the accrual and its reversal behave at month end. The mapping from pay component to account is brand new configuration, and that is where the differences hide.
I have watched a programme run three clean parallel payrolls and then discover at the first live month end that employer pension cost had posted to the wrong account for a whole company. The payslips were right. The journal was wrong. The parallel run had compared registers and never journals, because nobody from finance had been asked what they needed to see. The argument about who owns the financial record applies to payroll accounting just as much.
So a parallel run has two reconciliations, one of the register owned by payroll and one of the posting owned by finance, and the plan should show both with separate hours. Where the old system posted a summarised journal and the new one posts detail, agree the level of comparison up front.
The old system has to stay readable for the audit window
The question I ask in the cutover meeting is a simple one. In eighteen months an auditor, or an employee who left before go-live, asks for a payslip from a period the old system paid. Who opens what? The answers are usually a mix of keep it running read only, export everything, and deal with it later. Each is a decision with a cost, and later costs the most.
Keeping the old system readable means a licence, a tenant, and someone who still knows how to run a report on it, for the whole retention period. Exporting means deciding now which reports leave, at which grain, and where payroll can find them without a ticket to IT. Payslips as documents, the full register by period, year to date balances at cutover, and the statutory submissions are the minimum. Everything else is payroll's call.
This belongs on the programme's retirement list, with a date and an owner, in the way the case for a retirement list in every change plan describes. A programme that has not decided when the old payroll system stops being queryable has not finished its cutover.
Sign-off belongs to payroll and finance
The programme manager's incentive is the date. That is the job, and it is exactly why the programme cannot sign off its own cutover. If the steering committee accepts the programme's own slide saying the parallel run passed, nobody independent has checked the payroll. The signatures that mean something come from the payroll manager, who will be explaining a wrong payslip to an employee, and the controller, who will be explaining a wrong journal to the auditors.
The sign-off document I ask for is short. The tolerance sheet as agreed. The differences from the final run by category, with the count and value in each. The unexplained residual, as a number, and the names of the people who accept it. The status of the year to date and posting reconciliations. Then the two signatures. If the residual is a percentage of lines rather than a value, or the names are a team, send it back.
A change that completes technically and leaves nobody able to fix the problem is a pattern I keep meeting across HCM programmes. The piece on an employee change with no clear owner is the small version. Payroll cutover is the largest. Before your next steering meeting, open the plan and find the row for reconciliation. If the owner column says payroll team, put a name in it, then ask that person how many hours they have between now and the first parallel run. The answer is the real status of the programme.
