A man with curly hair evaluates documents at a desk, highlighting focused work in a professional setting.
Photo by RDNE Stock project on Pexels

Payroll Links

Part of Payroll software integration

Testing changes with a qualified payroll reviewer

Set expected payroll results before testing an integration change, then document differences and retests.

Editorial responsibility: Cooper Anderson · · 3 min read

This is an editorial pen name used by the publication, not a claim of an independently verified personal identity. Original editorial credit: Desk Payroll.

Involve a payroll reviewer before you approve expected results for an integration test. They establish what payroll should do under the employer's arrangements, check what the system did, and resolve differences. A technically successful transfer is only one part of that test.

Give the reviewer a defined brief

Choose someone with demonstrated knowledge of the workforce's pay arrangements and a way to escalate uncertain rules. That may be an experienced payroll specialist, supported by a workplace relations adviser where needed. A software demonstrator cannot be assumed to know the correct rate or entitlement.

Give the reviewer the approved source record, applicable pay rule or agreed calculation, expected result and payroll output. Record who decided the expected result and when, so a disputed test is not quietly changed to match the software.

Reviewer brief checklist for each test case

  • Approved source record for the case
  • Applicable pay rule or agreed calculation
  • Expected result, stated before the test runs
  • Who decided the expected result, and when
  • The payroll output to compare against that expectation
  • An escalation path for rules the reviewer cannot confirm

Use cases that exercise the change

Build cases around the proposed change: a new code, changed mapping, altered effective-date logic or replacement connector. Include an ordinary case to check that existing behaviour still works. Add edge cases where they reflect a real workforce pattern or plausible failure.

For a changed allowance mapping, a useful test set might include an eligible employee, an ineligible employee, a change partway through a pay period and a correction after export. The reviewer establishes the expected treatment before the interface runs. Amounts and classifications depend on the employer's actual arrangement; the example prescribes none.

Trace each case from approved source through outgoing payload, accepted payroll input, calculation and sample pay slip or equivalent output. Compare the employee, period, category, units and amount. Check the output that will be used to produce the pay slip, not just an import-success message.

Testing a payroll change with a qualified reviewer

  1. Set the briefGive the reviewer the approved source record, the applicable pay rule or agreed calculation, the expected result and the payroll output.
  2. Fix expected results firstEstablish what payroll should do under the employer's arrangements before the interface runs.
  3. Build cases around the changeInclude an ordinary case to confirm existing behaviour still works, plus edge cases that reflect real workforce patterns or plausible failures.
  4. Trace each case end to endFollow approved source through outgoing payload, accepted payroll input, calculation and sample pay slip or equivalent output. Compare employee, period, category, units and amount.
  5. Rule on each caseGive every case one outcome: pass, fail or unresolved. Record differences, likely cause, owner and required retest.
  6. Retest and sign offRetest the corrected case and a related case that could be affected, then sign off tested cases, coverage, open issues and manual controls.

Record the decision

Give every test one outcome: pass, fail or unresolved. For a failure, record the difference, likely cause, owner and required retest.

If the expected result itself is uncertain, mark the case unresolved and obtain the necessary payroll or workplace advice. Document the reason before changing an expected result after seeing the system output.

Retest the corrected case and a related case that could be affected. Keep the source version, interface version and payroll configuration used in the test. If one changes, determine which earlier results need repeating.

The reviewer can sign off the tested cases and known limitations. State the coverage, open issues and any manual controls needed when the change goes live. The pay-run team still needs to reconcile actual records during operation.

What each test outcome requires

  • PassSign off the tested case as part of the reviewer's coverage.
  • FailRecord the difference, likely cause, owner and the required retest.
  • UnresolvedDocument the reason and obtain payroll or workplace relations advice before changing any expected result.

More from Payroll Links