Payroll System Migration to a Global HR Platform: The Finance Case

A case: a growing company moves HR, absence, benefits and payroll onto one global platform

A payroll system migration is an HR project with a finance balance sheet attached. Pay rates, allowances, absence balances, benefit deductions and cost centres all move from old systems to a new one, and any error becomes a wrong salary, a wrong liability or a wrong accrual. This case follows a common implementation of a global HR and payroll platform in a growing company, from project set-up and process design through data validation, testing, change management and reporting, to go-live, with the finance checks that belong at each stage. The case is representative, not a named company or vendor. NEO Expertise supports finance teams through the finance side of projects like this one.

The Situation

The company employs about 1,150 people across several countries, after rapid growth that included two small acquisitions. HR runs on a mix of local tools and spreadsheets. Payroll is outsourced to a different provider in each country, and each provider sends its own report to finance, which accountants turn into journals by hand.

Leadership has approved one global platform to standardise HR processes and support further growth. The project plan covers core HR records, absence management, time tracking, benefits and payroll. Finance’s involvement is scheduled for the testing phase. The Financial Controller asks for it to start at the design phase instead, and that change is where this case begins.

Step 1: Assess and Design the Processes

Project management set the plan, timeline, milestones and coordination between the company and the implementation team. The assessment of current HR processes identified manual steps, inefficiencies and gaps, and the design phase defined standard processes, documented each design decision, and set security requirements.

Finance’s design input focused on four decisions that are expensive to change later:

• Cost allocation. Every employee’s cost centre and legal entity, so payroll journals post to the right place without manual reallocation.
• The payroll journal. One standard file per pay run, mapped to the chart of accounts, uploaded rather than rekeyed.
• Segregation of duties. Nobody who can change a pay rate or a bank account can also approve the pay run.
• Absence balances. Accrual rules configured to match the accounting treatment, not only the HR policy.

The last point matters because unused paid leave is a liability. Under IAS 19, as endorsed in the EU in Regulation (EC) No 1126/2008, accumulating paid absences are recognised as they are earned, and the minimum entitlement itself is set by law, for example the four weeks of paid annual leave under the EU Working Time Directive 2003/88/EC.

Step 2: Validate the Data Before It Moves

The business and data analysis workstream defined the HR data requirements, validated employee data, and prepared it for loading. Finance validated the fields that drive money: pay rates, allowances, cost centres, bank details, pension and benefit deductions, and absence balances.

Illustrative: the migrated absence balances averaged 6.5 days per employee. At an average daily employment cost of €240, that is a holiday pay accrual of about €1.79 million across 1,150 employees. A systematic error of one day per employee in the migrated balances would misstate the accrual by €276,000. Balances were therefore reconciled employee by employee to the old records, not accepted as a total.

Employee data is personal data, and pay and health-related absence data is sensitive, so extraction, transfer and loading followed the security requirements of the General Data Protection Regulation. Validation files were shared through the project’s controlled environment, never by email.

Bank details needed a separate check. Every employee’s account number was compared between the old payroll records and the load file, and any record where the two differed was confirmed with the employee directly before the first live pay run. Illustrative: 19 records differed, 17 because employees had changed banks and told HR but not the payroll provider, and 2 because of transcription errors in the load file. Without the check, those two salaries would have been paid to accounts that did not belong to the employees.

Step 3: Test Payroll in Parallel

Testing followed the plan: test scenarios for each process, several testing cycles, issues identified and resolved, and requirements validated. For payroll, the decisive test was a parallel run: the prior month’s payroll calculated in the new platform and compared line by line with what the old providers had paid.

Illustrative parallel run reconciliation for one country:

Item	€
Gross pay, old provider	2,418,600
Gross pay, new platform	2,412,950
Difference	5,650
Shift allowance not configured for 12 employees	4,200
Overtime rate table loaded with the previous year’s rates	1,300
Rounding per pay element instead of per payslip	150
Unexplained	0

The gross pay difference was small, but the same errors also changed employer social charges and pension contributions. The test was repeated at net pay and at employer cost level, and a second cycle was run after each fix. The payroll journal from the new platform was test-loaded into the general ledger each time, so the posting and the cost allocation were proven before go-live.

Step 4: Reporting, Training and Change

HR reporting was standardised and aligned with the new processes. Finance added one requirement: headcount and employment cost reports from the platform must reconcile to the general ledger every month. Before the project, HR and finance reported different headcounts to the board, because each counted leavers and contractors differently. One agreed definition ended that.

Change management assessed the impact on employees and managers, prepared them for new processes and managed adoption. Training materials and sessions covered payroll approvers and finance users as well as HR, so the people approving pay runs understood the new reports they were signing off.

Step 5: Go-Live and the First Closes

Go-live readiness was confirmed against the test results, the data reconciliations and the fallback arrangements with the old providers. After go-live, finance monitored the first three payroll cycles closely: gross-to-net reconciliations, payroll liability accounts (tax, social security, pensions) cleared to nil after payment, and absence accruals rolled forward correctly.

The same checks apply when payrolls from acquired companies are consolidated onto a group platform, which is one of the steps in the first 100 days finance integration roadmap. Employee and payroll data also forms part of our post-acquisition data check.

Where Payroll Migrations Go Wrong for Finance

• Finance joins at testing. By then, cost allocation and journal design are already built, and fixing them delays go-live.
• Balances accepted as totals. Absence and deduction balances that agree in total can still be wrong for individual employees.
• Testing gross pay only. Employer costs and liabilities carry the same errors at a larger scale.
• Two headcount definitions. HR and finance reporting different numbers undermines both.

This approach assumes payroll moves onto the new platform at the same time as HR. Where payroll stays with local providers and only HR data moves, the interface between the platform and each provider becomes the main risk, and it needs its own reconciliation every pay run.

The Payroll Migration Finance Checklist

Use this as a working checklist. Each item is a check to complete, not a topic to consider.

Design

• ☐ Confirm the cost centre and legal entity for every employee
• ☐ Design the payroll journal and its mapping to the chart of accounts
• ☐ Separate who can change pay rates and bank details from who approves the pay run
• ☐ Configure absence accrual rules to match the accounting treatment

Data validation

• ☐ Validate pay rates, allowances, deductions and benefit elections
• ☐ Reconcile absence balances employee by employee, not in total
• ☐ Compare bank details between old records and the load file, and confirm differences
• ☐ Follow data protection requirements for every extract and transfer

Testing

• ☐ Run the prior month’s payroll in parallel
• ☐ Reconcile at gross pay, net pay and employer cost
• ☐ Explain every difference, fix the cause and rerun
• ☐ Test-load the payroll journal into the general ledger

Go-live

• ☐ Agree a fallback cycle with the existing provider
• ☐ Reconcile gross to net for the first three cycles
• ☐ Clear payroll liability accounts to nil after each payment
• ☐ Reconcile headcount and employment cost to the ledger monthly

Frequently Asked Questions

What should finance check in a payroll system migration?

Cost centre and entity allocation, the design of the payroll journal, segregation of duties over pay rates and bank details, migrated pay rates, allowances, deductions and absence balances, a parallel payroll run reconciled at gross, net and employer cost level, and payroll liability accounts after go-live.

How do you run a parallel payroll test?

Calculate a prior month’s payroll in the new system using the same inputs, then compare it with what was actually paid, employee by employee and element by element. Explain every difference, fix the cause, and repeat the run until gross pay, net pay and employer costs all agree.

Why do absence balances matter to finance?

Unused paid leave that employees can carry forward is a liability that finance accrues. If absence balances are migrated incorrectly, the holiday pay accrual is misstated. Reconcile migrated balances employee by employee to the old records rather than accepting a matching total.