Kaimai DHB payroll migration

Binary floating point cannot represent many decimal fractions exactly. For example, 0.1 is stored as a value slightly above 0.1. Accumulating thousands of such values, or multiplying an hourly rate by fractional hours, can produce a result that is a cent or more away from the decimal calculation. In payroll, a cent matters: it changes a bank payment and, across 3,200 staff, becomes a material discrepancy.

The legacy system's round-half-up at four decimal places on the hourly rate is itself a policy choice. The new system's “round at the final line” is a different policy, and the two will not agree even if both are internally consistent. The first step is to state the policy explicitly: store monetary amounts as integer cents, or use a decimal type with a defined scale, and apply rounding at documented points. The fair work recommendation is to round intermediate rates to four decimal places using half-up, and round the final payable amount to two decimal places half-up, matching the legacy policy unless the settlement agreement says otherwise. Any change to rounding that could reduce pay must be negotiated, not assumed.

Overtime at 1.5× and night-shift allowances compound the issue. The order of operations matters: rate × hours × multiplier, then allowance, then tax. Each step needs a documented rounding rule. Audit traceability requires storing the full-precision input, the rounded intermediate values, and the final amount, with a calculation identifier. A “penny reconciliation” report should compare legacy and new calculations line by line.

The safest design is to avoid floating point for money entirely, use decimal arithmetic in the application and integer cents in the database, and add automated tests with known edge cases such as 0.005, 1/3 of an hour, and a 1.5× multiplier on a four-decimal rate.

Two cycles is the minimum for a fortnightly payroll with overtime and allowances. The parallel run should process the same input data through both systems and compare outputs at three levels: the employee-level payslip, the pay-run totals by cost centre, and the general-ledger postings. Employee-level comparison should check gross pay, each allowance, overtime, tax, deductions, employer contributions, and net pay. Totals matter because a compensating error at employee level can still produce a correct total and hide a problem.

Discrepancies should be classified before they are fixed. A difference caused by a documented rounding-policy change is expected, but it still needs sign-off and a communication plan if any employee is paid less. A difference caused by a missing allowance rule or an incorrect overtime multiplier is a defect and must be fixed and retested. A difference that cannot be explained is a red flag; it should block sign-off until the calculation path is traced end to end. Each discrepancy should have an owner, a root cause, and a test that proves the fix. The audit office will want this log, not just a statement that the totals matched.

The backdated pay-equity settlement adds risk because it affects historical periods and may recalculate prior overtime. The test should include a sample of employees with backdated changes, leave without pay, and multiple rates in one pay period. The union should be shown the reconciliation method and the treatment of any underpayment, with a commitment to top up rather than claw back.

I would recommend delaying go-live if any unexplained discrepancy remains, if the number of employee-level mismatches exceeds an agreed threshold (e.g. more than 0.5% of staff), if the backdated calculation cannot be audited, or if the vendor cannot support a rollback to the legacy system for the first two live cycles. A two-cycle parallel run that is rushed is worse than a delayed go-live, because payroll errors damage trust and are expensive to unwind.

The single subject-matter expert is the largest non-technical risk. If that person is unavailable, the project loses its ability to interpret legacy rules, and the vendor may fill the gap with assumptions. The expert's knowledge should be externalised early: a rule catalogue covering overtime eligibility, night-shift definitions, allowance triggers, leave interactions, and the backdated settlement, each with a worked example and a test case. This is not documentation for its own sake; it is the acceptance-test oracle.

The time-zone gap makes synchronous decision-making expensive. The project should define a decision log with named owners and response times. Routine configuration decisions can be delegated to the vendor lead against the rule catalogue; policy decisions that affect pay must go to the payroll manager and, where the union agreement applies, to the union. A daily written stand-up and a twice-weekly overlapping call are more reliable than relying on ad hoc messages. Escalation criteria should be explicit: any change to rounding, any change to an allowance rule, and any discrepancy that affects more than a handful of staff go to the payroll manager.

Knowledge transfer should be bidirectional. The vendor should run walkthroughs of the new calculation engine for the expert and a backup, and the expert should run walkthroughs of the legacy rules for the vendor. A second payroll officer should be trained as a backup. The audit requirement means the rule catalogue and the decision log become part of the evidence pack.

Finally, the governance group should include someone with authority to delay go-live. If the expert is overloaded and the vendor is making policy decisions by default, the project is drifting; a visible decision log and a named backup are the cheapest mitigations.