Scheduled Hours Standing In for Actual Ones
Why paying the roster instead of the record makes a time system stop measuring, where it is configured, and what to check first.
One shift where the schedule replaced the record, link by link
The record was complete and correct, and the system paid something else. This is one employer's own configuration, not a statement of what any rule requires.
A system that pays the schedule instead of the record has stopped measuring anything. The punches still happen, the timestamps are still stored, and none of it reaches payroll — which means the organisation has a time system that produces the roster back at itself and has no way to answer a question about what was actually worked.
The workflow in “Scheduled Hours Standing In for Actual Ones” becomes more reliable when captured time, approvals and later changes can be followed separately. For teams exploring remote desktop monitoring software, Monitask resources for remote desktop monitoring software can provide useful operating context, while payroll rules, employee explanations and final decisions remain with accountable people.
This is a configuration, not an accident, and it is almost always inherited. Somebody turned it on to reduce exceptions, it worked, and nobody has looked at it since.
For an independent reference relevant to “Scheduled Hours Standing In for Actual Ones”, consult the European Commission working-time resources. Use it to test record quality, working-time definitions, access, retention and exception handling against the organisation’s real payroll process.
Why it gets switched on
The reason is real. Punch data is messy: missed punches, people clocking in at the wrong terminal, shifts that cross midnight. Substituting the schedule removes almost all of the mess at a stroke.
What it also removes is every signal the system existed to produce. The overrun does not appear, the early start does not appear, and the exception queue is empty because there are no exceptions by construction.
The three places it hides
| Setting | What it says | Effect |
|---|---|---|
| Pay from schedule where a punch exists | "Use the roster, confirm attendance" | Punches become attendance only |
| Auto-correct punches to within a tolerance | "Clean up small variances" | Everything inside the tolerance is lost |
| Pay the lesser of schedule and actual | "Avoid overpayment" | One-directional by design |
The third is the one that should stop a review. A rule that takes the lower of two numbers is not a cleanup; it is a decision that errors should only ever run one way.
How to find out whether you have it
Pick a week and compare three columns: the roster, the raw punches, and the hours paid. Any employee whose paid hours match the roster exactly, week after week, in an operation where shifts routinely overrun, is telling you the answer.
Perfect agreement between schedule and pay is not evidence of a well-organised operation. In any real workplace it is evidence that one of the two numbers is not being used.
Exceptions that are never raised
The deeper problem is silence. A good configuration produces a queue: this person worked forty minutes beyond the roster, somebody should decide whether that was authorised.
Substitution produces no queue. The decision is made by default, in one direction, for everybody, every day — which is the definition of a rule nobody chose.
What a reasonable configuration looks like
Pay from the record. Raise an exception where the record and the schedule differ by more than a stated amount. Require somebody to resolve the exception, with a reason. Report on how many exceptions there are, and on who is resolving them without a reason.
That produces more work in the first month and less thereafter, because the exceptions are mostly real and most of them have operational causes that can be fixed: a terminal in the wrong place, a handover outside the shift, a round that cannot be completed in the time allowed.
Where substitution is legitimate
There are cases. Somebody on a fixed salary with no variable hours, a genuinely missed punch where the schedule is the best available estimate, a system outage.
The distinction is that each of these is an exception with a reason attached. A substitution applied as the default to everybody is a different thing, even though the setting is the same.
Turning it off
Switching substitution off produces a spike of exceptions in the first period, which is usually what stops organisations doing it. The spike is the backlog of everything the setting has been absorbing, and it falls away within about three cycles as the underlying causes get fixed.
Plan for it rather than being surprised by it: warn the managers, expect a fortnight of volume, and track the exception count weekly. A count that stops falling after a month is pointing at a real operational problem rather than at a configuration one.
Checking the reports you rely on
If substitution is on, every hours report the organisation produces is describing the roster. Utilisation, overtime by department, hours per unit of output — all of it is roster data wearing a different name.
That is worth saying to whoever uses those reports, because they are usually making decisions on them. The pay consequence is the one this collection is about; the management consequence is often larger, and it is the argument that gets the setting changed.