Cutting Over a Payroll System in the Tax-Change Month
A Malta-based logistics firm with 480 employees paid monthly on the 28th is replacing a 12-year-old COBOL payroll system with a SaaS product. There are three outbound interfaces: a bank file (SEPA XML), a pension provider CSV and the tax department's monthly return. The vendor proposes a single big-bang cutover on 1 January, the same month as the annual tax-rate change. During a pilot using October data, 37 of 480 net-pay figures differed from the legacy system, all by less than one cent, and two employees who changed grade on the 15th were paid the old grade for the whole month. The legacy system rounds half up at line level then sums; the SaaS rounds at the total. The finance director wants to go live on time. The payroll officer wants to keep the old system running for a year, which the vendor says would cost an extra 18,000 euro and require duplicate data entry.
1. Recommend a cutover strategy: big-bang on 1 January, a one-year parallel run, or something in between. Justify using the evidence, including the 18,000 euro.
Read the worked answer
Separate the two defects from the timing.
The 37 differences under one cent are explained by a rounding-rule mismatch. That is a known, controllable difference: pick one rule, document it, get the auditor's agreement and retest. On its own it is not a reason to delay.
The two mid-month grade changes are unexplained and worse. The SaaS did not prorate to match, and grade changes happen every month. That rule must be fixed and retested before go-live.
Timing is the strongest argument against 1 January. January already carries the annual tax-rate change, so a big-bang puts a new system and a new rate into one run. If payslips are wrong you cannot tell which change caused it: two variables, one test.
Recommendation: neither big-bang nor a one-year parallel run. Run in parallel for two cycles, December (a normal month, proving the rounding rule) and January (absorbing the rate change), then cut over in February with the legacy system read-only. The 18,000 euro buys two reconciled cycles; weigh it against recalling a SEPA file for 480 employees, reissuing payslips and correcting the tax return. That comparison, not the price alone, is the decision.
If the vendor cannot prorate mid-month changes correctly by December, delay the cutover rather than parallel-run indefinitely. A year of duplicate entry creates its own errors and trains staff on the wrong system.
2. Are 37 differences of less than one cent acceptable? Explain how you would decide and what you would do about the cumulative effect.
Read the worked answer
Treat acceptability at three levels.
Per payslip: not acceptable as a silent difference. A cent is trivial in cash, but each employee must be able to have their net pay explained, and a difference the payroll officer cannot account for is a control failure whatever its size. If the cause is the documented rounding rule and that rule is signed off, the difference is explainable and can be accepted. If it cannot be explained, it cannot be accepted.
In aggregate: 0.01 x 37 = 0.37 euro in one month. As a control total this is noise, and it should be tolerated in reconciliation. Chasing 0.37 euro finds more errors than it fixes. Use a defined tolerance for the aggregate check only.
Cumulative and year-to-date: this is where it matters. Rounding differences do not necessarily cancel. They feed year-to-date tax and the end-of-year return, and a method that always rounds in one direction drifts systematically by a few euro per employee. Test the January-to-December cumulative figure in the pilot, not just one month.
Action: choose one rounding rule for the whole payroll, have the vendor implement it, record it in the system documentation, reconcile monthly on the aggregate, and explain any individual difference beyond tolerance. Report the decision, not just the number, to the finance director.
3. Design the reconciliation and rollback plan for the first live run.
Read the worked answer
Reconcile before transmission, not after.
Control totals from both systems: headcount, total gross, deductions by type, employer contributions, total net. Compare each and investigate any break beyond the agreed tolerance.
Row level: match every employee on payroll number; flag anyone present in one system and not the other, and anyone whose net differs by more than tolerance.
Output files: validate the SEPA XML against the scheme schema, check the control sum equals the sum of individual amounts, and that the transaction count equals headcount. The pension CSV and tax return are separate reconciliations; a green bank file does not prove the other two are right.
Sign-off by the payroll officer and finance director, recorded, before the file is released to the bank.
Rollback: keep the legacy system read-write and its data current until the first live payroll is paid and reconciled. Read-only is not enough if you may have to run next month on it. Define the trigger in advance: any employee paid the wrong grade, a control-total break beyond tolerance, or more than an agreed number of unexplained differences. On trigger, void the SEPA file before the bank cut-off, re-run on legacy and communicate.
Once money has left, rollback becomes correction. That is why the gate sits before transmission, and why the bank cut-off time belongs in the plan.