Payroll errors that cause underpayments—and how to fix them

Which payroll errors can lead to underpayments?

Payroll errors include missing or incorrect inputs, rules applied to the wrong circumstances and failures between systems. Some cause underpayments; others create overpayments, reporting differences or a variance that needs explanation. This guide focuses on errors that leave employees short and the controls needed to prevent them recurring.

Use the examples below to frame an investigation, not to determine an entitlement. Confirm the applicable instrument and approved methodology for the employee's circumstances.

These are illustrative investigation paths, not findings about a particular employer. Avoid treating "human error" as the final explanation: identify what allowed the incorrect input or decision to reach payroll and why the checking process did not catch it.

Where should an underpayment investigation start?

Start with one specific pay outcome and trace how it was produced. That gives the team a testable question before it labels the problem a system error or a payroll mistake.

Capture the employee scenario, relevant period, actual payment and basis for the expected result. Then follow the information through its journey: work performed, record captured, approval, interface, rule application and payment.

Rebecca’s practitioner input identifies configuration, process, policy and data as useful investigation areas. They help frame the questions; they are not mutually exclusive categories or a complete legal classification of underpayment causes.

This investigation sits inside the wider payroll remediation programme. Its purpose is to connect the finding to an effective correction and assess whether other employees or periods may share the exposure.

What should you check across systems, processes, policies and data?

Check both the rule and how the organisation actually operates it. The same headline discrepancy can have very different causes and require different owners.

Fair Work recommends drawing on a broad range of information, including actual working patterns and relevant enterprise systems, when diagnosing an issue. Its remediation guide, pages 6–7, also discusses manual processes, record practices and local behaviour as investigation areas.

An interview can explain a process; transaction evidence helps establish what happened. Use both. A policy document alone will not tell you whether a manager regularly bypassed the intended workflow.

How do you distinguish a symptom from a cause?

A symptom is the observed result. A cause explains the mechanism that produced it and points to an action that can be tested.

“The allowance was missing” describes a symptom. “The approved allowance code was dropped during the time-system interface, and the reconciliation did not check that code” identifies a testable mechanism and a control gap.

Ask successive questions without assuming the answer:

1. What evidence establishes that the payment differed from the applicable entitlement?
2. Was the source information present and accurate?
3. Did it survive each handoff and transformation?
4. Did the correct rule apply at the correct time?
5. Which control should have detected the discrepancy, and what happened to it?

Different answers may change the review scope. Finding a shared mapping issue, for example, gives a reason to examine other transactions using that mapping rather than limiting the review to the original complaint.

What does a root-cause investigation look like in practice?

Consider a hypothetical employer where a review identifies unpaid allowances for a group of employees. This is an illustrative scenario, not a TPS client result or advice about a particular award.

The starting evidence: the approved methodology says an allowance is payable in the scenario, and source records show the qualifying activity. The payment records do not show the allowance.

The investigation: the team traces the records through the time-system export and finds that the allowance code is missing from the interface mapping. It also finds that the monthly reconciliation compares overall hours, so it does not expose the missing code.

The correction: the responsible system owner updates the mapping under change control. The process owner adds a reconciliation for the affected transaction type. The programme assesses which employees and historical periods used the same mapping.

The validation: the team retests the original scenario and relevant variations, including an employee moving between eligible and ineligible roles. It checks that the change has not introduced duplicate allowances or altered unrelated payments.

The ongoing control: a named owner reviews the exception report and records how discrepancies are resolved. The programme agrees when the evidence is sufficient to move from intensive monitoring to normal controls.

The example contains both a technical defect and a process weakness. Addressing both produces a stronger corrective action than changing the mapping alone.

What belongs in a root-cause and corrective-action register?

Keep the finding, its evidence, the action and the verification together. This makes it easier for leaders to see what remains open and for delivery teams to know the next step.

Use these fields as a starting template:

• Finding and affected scenario: a specific description with links to source evidence.
• Cause and contributing factors: what the investigation establishes, with assumptions marked separately.
• Potential scope: related employees, periods, entities or rules requiring examination.
• Current-pay protection: any interim measure and its limitations.
• Corrective action and owner: the change, accountable person and dependencies.
• Test and acceptance evidence: expected outcome, actual outcome, exceptions and approval.
• Ongoing control: who monitors what, how often and where an exception goes.

Avoid closing an action simply because a task was completed. “Updated the policy” records activity. “Tested the revised process and retained evidence that the affected scenarios now pay correctly” describes a more meaningful outcome.

How should you test a corrective change?

Test the change against an agreed expected result and check for unintended effects. Include the original failure, relevant edge cases and neighbouring rules that share data or configuration.

For example, a change involving effective dates may need cases on either side of the date boundary. A classification change may require a mid-period transition. Select cases from the actual risk and methodology rather than using a generic list as proof of compliance.

Keep the result reproducible: record the data version, rule version, test scenario, expected outcome, actual outcome and the reviewer’s decision. Where the expectation is uncertain, resolve the methodology question before treating a matching output as a pass.

Our guide to validating payroll remediation results explains how to turn those checks into a documented strategy.

How do you prevent the driver from returning?

Assign ownership for the control after the remediation project ends. Build the relevant check into normal operations, change management and team learning.

A correction can fail later if the control depends on one person’s memory. Make the handoff explicit: who owns the rule, who checks the source data, who investigates an exception and who approves a change?

Use a short scenario from the investigation in team training. Ask participants to identify the decision owner, evidence required and escalation point. That connects payroll compliance responsibilities to work people actually do.

Fair Work’s guidance on future compliance, pages 27–31, covers ongoing assurance, governance, systems and capability. Return to the remediation hub to connect corrective action with employee outcomes and programme closure.

Where can your team get remediation support?

If your team needs help turning these checks into a working program, explore our payroll remediation support. We can discuss root-cause investigation, program management, validation, reconciliation and the employee-payment journey, with responsibilities agreed around your existing providers and advisers.

Sources and scope

This article draws on practitioner input from Rebecca Wade and the Fair Work Ombudsman’s Payroll Remediation Program Guide. The hypothetical scenario and register are original editorial tools; they do not establish compliance or describe a completed client engagement.

Portions adapt the Payroll Remediation Program Guide, April 2025. © Fair Work Ombudsman, www.fairwork.gov.au, under CC BY 3.0 Australia. Guidance has been summarised and combined with original explanations and examples. No FWO endorsement is implied.