Payroll went live and people are underpaid. Where do you look?

In early July 2026, Sydney Water switched more than 4,000 employees to a new payroll system, Dayforce, replacing Aurion. The system cost $38 million². By 25 September, three unions were running work bans and rotating four-hour stoppages, and union members had pledged not to chase unpaid water bills, not to give contractors access to capital works sites, and not to drive on toll roads¹. Their complaint: some staff were paid late, and some did not receive allowances and overtime they were owed. The unions say hundreds of workers have been underpaid by thousands of dollars¹.

Sydney Water has apologised and says teams are correcting discrepancies, running regular reconciliations and offering hardship payments¹. Its managing director wrote on 20 August that staying on Dayforce was “the lower risk, least disruptive solution”, because reverting to Aurion would take an estimated five to six months².

Why would a new payroll system pay people wrong?

Sydney Water has not published a root cause, and an independent review it promised had not reported in the coverage we found². The union’s account is specific, though. Its secretary says the system cannot account for the allowances and additional payments that many workers’ incomes depend on¹.

If that is right, it is a familiar failure. The old system was applying rules, some configured, some baked in over years, some worked around by a payroll clerk every fortnight. The new system was set up from the rules someone could list. The ones nobody listed did not move.

What is the rule nobody listed?

Usually one of four things:

• A configured rule that was never inventoried. An allowance table edited in 2014 for one depot.
• A behaviour of the old system. Rounding, ordering of deductions, how a split shift is counted. Nobody chose it, so nobody documented it.
• A manual step. A clerk adds a payment by hand when a certain shift pattern appears.
• An agreement outside the system. A side letter or local arrangement that payroll honours from memory.

None of these appear in a requirements document, because the people writing it did not know they existed. They show up on the first payslip.

How do you find them before go-live?

A parallel run is the standard answer, and it helps. It catches the rules that affect the sample you ran. It does not tell you why a figure differs, and it cannot catch a rule that applies only to a pay period you did not run.

The stronger move is to build the list of rules first, from the old system and from the people around it, and to ask an owner about each one. For every rule you want to know what it does, why it exists, who decided, and whether it still applies. A rule nobody can explain is not a reason to drop it. It is a question to settle before cutover, while the old system is still running and the person who knows is still in the building.

What does that look like in AppThentic?

AppThentic reads the legacy system and the documents, tickets and conversations around it. Every rule it finds goes on a migration list with a status. Approved rules move as they are. Stale rules go to their owner with a question on whether to retire them. Unknown rules go to the person most likely to know, starting with those that touch money, dates and customers. Your team ports from the list, and each decision on what moved and what was left behind is kept with its evidence.

Rules marked Unknown or Disputed are the allowances to ask about now. See Legacy migration.

What can you do this week?

If a payroll, billing or benefits cutover is on your calendar, ask one person in payroll or finance operations to list every payment they adjust by hand or correct after a run. That list is a short, honest inventory of rules the old system does not apply on its own. Check that each one has an owner and a place in the new configuration.

Sources