Computing What Is Owed

Rebuild the correct figure period by period rather than estimating an average. The calculation is the same arithmetic as the original, run with the setting fixed, and the difference between the two is what is owed — which means the exercise needs the original data, not a reconstruction of it.

The correction process in “Computing What Is Owed” requires a visible history rather than an overwritten total. If the provider's website supports how to measure employee productivity, 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.

Averaging is tempting when the population is large and it produces a number nobody can defend to an individual. The person affected will ask about their own weeks, and the answer has to exist.

For an independent reference relevant to “Computing What Is Owed”, consult the European Commission project-management guidance. Use it to test record quality, working-time definitions, access, retention and exception handling against the organisation’s real payroll process.

What the calculation needs

• The hours actually worked, by week, from the raw record.
• Every component of pay for the period, by week.
• The setting as it was, so the original figure can be reproduced.
• The setting as it should have been.
• The resulting difference, per week.
• The total per person, per period.

The third is the one organisations skip and then regret. Being able to reproduce the original figure is what proves the difference is a difference rather than a new calculation that happens to be higher.

One model for everybody

Build the calculation once, as a model that takes the data and produces a figure per person per week. Do not compute individuals by hand.

That matters for three reasons: consistency, because hand calculations diverge; auditability, because one model can be checked and four hundred spreadsheets cannot; and speed, because the scope will change at least once during the exercise.

Checking the model

1. Pick three people whose circumstances differ: simple, multi-rate, with a bonus.
2. Compute each by hand, fully.
3. Compare with the model.
4. Investigate every difference, however small.
5. Only then run the model across the population.
6. Keep the three hand calculations as the model's test cases.

Step six is what allows the model to be rerun later with confidence. A model with no test cases is a black box, and black boxes are exactly what produced the original error.

The elements that travel with the correction

A corrected gross figure usually affects more than gross pay: contributions, accruals, year-to-date figures, holiday pay calculated on average earnings, and sometimes benefit entitlements.

Each has to be identified and handled, and the easiest time to do that is while the model is being built rather than afterwards. Holiday pay is the one most often missed, because an underpaid week lowers an average that was used somewhere else entirely.

Interest and additional amounts

Some systems add interest, uplifts or fixed additional amounts to late wage payments, and some agreements do.

Whether anything attaches, and how it is computed, is a question for somebody qualified in the place concerned. The model should be built so that an additional element can be applied without rebuilding it, because the answer frequently arrives after the arithmetic has started.

Rounding and small amounts

Where an individual's correction is a few pence, paying it still matters — not for the amount but because a threshold below which corrections are not made is a decision that will be asked about.

If a threshold is used, it should be stated, applied consistently, and set at a level nobody would describe as avoiding the correction. The administrative saving is rarely worth the explanation.

Documenting the working

For each person: the periods, the original figures, the corrected figures, the difference, and the basis. One page per person, generated from the model rather than written.

Produce the per-person breakdown before paying anything, and send it with the payment. A correction arriving without a breakdown generates exactly the query the correction was meant to resolve.

Where the data itself is doubtful

Sometimes the inputs are unreliable: a period where the time system was being replaced, a site that used paper, a stretch where approvals were not being done.

Those periods have to be identified and handled explicitly rather than run through the model as though they were sound. A reconstruction, built and labelled as described elsewhere on this site, is the right answer — and resolving genuine uncertainty in a way that consistently favours the employer is the wrong one, because the pattern is visible even when each individual decision is arguable.

Reviewing the output before paying

Before anything is paid, somebody should look at the distribution: the largest individual amounts, the smallest, and anybody whose figure is surprising given their role.

Outliers are usually model errors rather than real findings, and catching them before payment is far easier than afterwards. A single corrected payment that then has to be corrected again does more damage to confidence than the original error.

Keeping the model

Keep it, with its test cases and its inputs, for as long as the records it relates to. It is the only artefact that explains what was paid and why, and it is the thing an inspection or a later question will ask for first.