Finding an Underpayment First

Run six tests on a schedule and most wage errors surface before anybody complains. Each takes under an hour, each needs only data the organisation already holds, and together they cover the large majority of what goes wrong in the chain between a punch and a payment.

The correction process in “Finding an Underpayment First” requires a visible history rather than an overwritten total. If learn more on this page supports interview reimbursement policy, administrators should test amendment, approval and export workflows so a later review can distinguish the original entry, the question asked, the correction and the person who accepted it.

The alternative is finding out from a query, a claim or an inspection — at which point the error has been running for as long as it has been running, and the organisation is responding rather than deciding.

For an independent reference relevant to “Finding an Underpayment First”, consult the Xero accounting resources. Use it to test record quality, working-time definitions, access, retention and exception handling against the organisation’s real payroll process.

The six tests

1. Weeks above the threshold with no premium paid, by person.
2. Premium rates below the person's own composite rate for that week.
3. Multi-rate weeks where the premium used a single rate.
4. Weeks straddling a pay period boundary where a premium vanished.
5. Unapproved or expired time entries at each cut-off.
6. Effective hourly rates below any applicable minimum, for anybody not paid hourly.

None of these requires a project. All of them are queries against payroll and time data, and any of them returning rows is a finding rather than a suspicion.

Running them as a routine

Monthly for the first two, quarterly for the rest, by one named person, with the results recorded even when they are empty.

The empty results matter as much as the full ones. An organisation that can show it has tested for a specific failure every quarter for two years is in a different position from one producing the same test for the first time because somebody asked.

What to do in the first week

• Establish the scope: how many people, which periods, what cause.
• Stop the cause, so the error is not still running while it is investigated.
• Preserve the data, including the raw timestamps and the configuration as it was.
• Avoid changing anything retrospectively in the records themselves.
• Decide who needs to know internally, and tell them.
• Take advice, if the scope is beyond a handful of people or a short period.

Stopping the cause first is the one organisations reverse. Investigating for six weeks while the setting continues to produce the same error adds six weeks to the eventual total.

Scope before arithmetic

The instinct on finding an error is to start computing what is owed to the person who surfaced it. The more useful first step is to establish who else is affected, because the answer determines almost everything that follows.

A setting applies to a pay group, a site or a shift pattern. Finding the boundary of the affected population takes an afternoon and prevents the situation where corrections are made in three waves as the scope keeps growing.

Preserving the evidence

Configuration as it stood, raw time data, the payroll outputs, and a record of what was changed and when.

Take a copy of the system configuration before fixing it. An organisation that corrects a setting without recording what it was cannot later describe its own error, which makes every subsequent conversation harder than it needed to be.

Who to tell internally

Whoever owns payroll, whoever owns the time system, and somebody senior enough to authorise paying what is owed without a second round of approval.

Keeping it inside payroll while the scope is assessed is a common instinct and a poor one. The decisions that follow are not payroll decisions, and discovering that three weeks in loses three weeks.

The honest accounting

Some findings are small and can be corrected in a cycle. Some are large and involve several years and several hundred people, and those need advice before anything is communicated or paid.

The distinction is usually clear within a day of establishing scope. What is not acceptable is treating a large one as small because the small version is easier to handle — the scope does not change because the response was chosen first.

Who runs the tests

The tests should not be run by the person who owns the configuration they are testing, for the same reason that nobody checks their own arithmetic well.

In practice that usually means payroll runs the tests on the time system settings and the time system owner runs them on payroll, which is awkward and effective. Where the organisation is too small for that, the tests still get run and the results go to somebody else — which is the minimum separation available and is better than none.

Keeping the tests

Write them down as queries, with the reason each exists and the date each was last run. Six entries.

That document is what survives a change of staff, and it is also the thing that turns a one-off audit into a control. An audit finds what is wrong today; a scheduled test finds it next year, which is when the next configuration change will have introduced something new.