Edits, Corrections and Who Made Them

Every edit to a time record should carry three things: who made it, when, and why. Systems almost always support all three and the reason field is almost always empty, which means a record of what somebody worked was changed by somebody else and nobody can say on what basis.

The correction process in “Edits, Corrections and Who Made Them” requires a visible history rather than an overwritten total. If the official Monitask website supports how employee monitoring works, 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.

That is a problem on its own, and it is a larger problem because the edit log is the only place in the chain where a human intervened deliberately. Everything else is settings. This is decisions.

For an independent reference relevant to “Edits, Corrections and Who Made Them”, consult the Acas working-hours guidance. Use it to test record quality, working-time definitions, access, retention and exception handling against the organisation’s real payroll process.

What a good edit record contains

• The original value, retained rather than overwritten.
• The new value.
• Who changed it, by name rather than by shared account.
• When, to the minute.
• Why, in words, from a short list plus free text.
• Whether the employee was told.

The last is the one nobody has and the one that resolves most disputes. An employee who knew their Tuesday was corrected from 9.2 to 8.7, and why, does not raise it six months later.

Volume before content

The instinct on seeing an edit log is to read the edits. The more useful first step is to count them.

1. Total edits in the period, and as a proportion of all time entries.
2. Edits by editor, to see whether one or two people account for most.
3. Edits by reason, where reasons exist.
4. Edits by direction: how many increased hours, how many reduced them.
5. Edits by delay: same day, same week, after the pay run.
6. Edits with no reason recorded at all.

Row four is the one to look at hardest. Corrections in a functioning process go both ways in roughly comparable numbers. A log where ninety per cent of edits reduce hours is describing something other than correction.

High volume is a process signal

A supervisor making four hundred edits a quarter is not careless. They are patching something upstream: a terminal that does not register, a shift pattern the system cannot express, a round that always overruns.

That is why volume comes first. The edits are the symptom, the cause is elsewhere, and fixing the cause removes the edits — whereas tightening the edit process just makes the same patching slower.

Editing after the pay run

Edits made after pay has been calculated are a separate category and need their own handling: the money has already moved, so the correction has to produce an adjustment rather than a changed number.

Lock time records at the point of pay calculation. After that, changes go through an adjustment with its own record, rather than by editing history. A record that can be altered after it has been paid cannot evidence what was paid.

That single change answers most of the awkward questions an inspection or a claim will ask about edits.

Reading the log fairly

An edit log looks incriminating and usually is not. Most edits are genuine corrections made by people trying to get somebody paid properly, often for time the system failed to capture.

Approaching it as an audit of individuals destroys the information, because the next quarter's edits will be made more carefully and less honestly. Approaching it as a description of where the capture process fails produces answers people will help with.

Self-service edits

Where employees can correct their own records, the same requirements apply and one more: the correction should be visible to a manager without requiring approval for every instance, or the mechanism becomes unusable.

Self-service with a light review is generally better than manager-only editing, because the person who knows what happened is making the record. The common failure is a system where the employee can request but not record, and requests expire unanswered.

Shared accounts

Edits made from a shared supervisor login are edits by nobody. The log records an account rather than a person, which removes the single most useful field in the record.

This is usually a hangover from a terminal in a workshop or a till area where individual logins were impractical. It is worth fixing for this reason alone, and it is cheap: the alternative is an audit trail that cannot answer the first question anybody asks of it.

What to report on

Two numbers, monthly: edits as a proportion of entries, and the proportion of edits with no recorded reason. Both should trend towards zero and neither usually does without somebody watching.

Those two numbers are also the ones an outsider will ask for, and an organisation that has been watching them for a year is in a very different position from one producing them for the first time because somebody asked.