Which System Owns Which Rule
Overtime calculated in two places is the classic workforce management defect. A register that prevents it takes an afternoon.
The joins · Procedure
Pay rules can be implemented in scheduling, in time capture, or in payroll. Most organisations have them in two of the three and do not know it.
How it happens
Time capture is configured to classify overtime, because the vendor offered it.
Payroll also calculates overtime, because that is what payroll does.
Nobody compares the two definitions, which differ slightly — daily against weekly, or a different threshold.
The result is double-counted or under-counted hours, surviving for years because each side assumes the other is not doing it.
The register
A list: every pay rule, and which system applies it.
Overtime, by threshold and basis. Unsocial hours. Shift premiums. Call-out. Short-notice premiums. Holiday pay averaging. Sick pay.
One owner per rule, stated.
An afternoon to produce, and it is the single most valuable artefact in this subject.
Why one owner and not a review
Because a review catches a discrepancy once.
Ownership prevents it recurring when someone reconfigures a module.
And it answers the audit question directly: why was this person paid this amount, and which system decided.
Where each rule usually belongs
Rules needing the schedule — anything about shift patterns, rest premiums, short-turnaround pay — belong upstream, because payroll cannot see the rota.
Rules needing cumulative pay history — averaging, thresholds over a reference period — belong in payroll.
Rules needing actual times belong in time capture.
Where a rule needs two of these, the data has to move rather than the rule being split, and splitting it is what produces the defect.
The check
Take three people with complex pay — overtime, a premium, an absence — and reconstruct their pay from the raw records.
By hand, following the register.
Compare against what was paid.
A difference means a rule is implemented somewhere the register does not say, and finding it is the point.
Keeping it current
Review when any module is reconfigured, which is the trigger everyone misses.
Review after a vendor upgrade, because new calculation features arrive enabled.
And version it, so a question about a payment two years ago can be answered with the rules that applied then.
Review it after every reconfiguration
The trigger everyone misses.
A module reconfigured, a vendor upgrade applied, a new pay element added.
Each can enable a calculation that the register says lives elsewhere.
And nothing announces it, because to the vendor a new calculation feature is an improvement.
Twenty minutes after each change, checked against the register rather than from memory.
Connect policy and data
The choices in this note can be compared with this consulting workflow. Keep the written purpose in control and enable only the information needed at this boundary.