The right payroll source is not the most convenient one
If your payroll figures, scheduling records and job costing all show different versions of the same day, the problem is usually not just staff forgetfulness. It is often that the business has never clearly decided which time record is the governing source for pay.
That decision matters more than many businesses realise.
A technician might clock in on their phone at 7:02am, write 8 hours on a timesheet, and move a job to completed at 3:48pm. All three records say something useful. None of them necessarily means the same thing. If payroll treats them interchangeably, disputes start. So does bad reporting.
The core issue is that these records answer different operational questions:
- a timesheet usually captures claimed effort
- a clock event usually captures attendance or presence
- a job status usually captures workflow progression
Those are related, but they are not identical.
If you want reliable payroll, job costing and reporting, you need to separate two things that are often blurred together:
- how work time is captured
- how payable time is approved
That distinction is where many control problems start.
Effort capture is not the same as payroll approval
A timesheet, clock event or job status can all be input signals. None of them should automatically be assumed to be final pay without some thought about what the record actually represents.
For example:
- A field worker may be on site from 7:00am to 3:00pm, but only 6.5 hours are billable to the job once breaks, travel and depot loading are separated.
- An installer may complete a job status at 4:15pm, but payroll still needs to account for travel back, rework, or waiting time caused by the customer not being ready.
- An office employee may not have meaningful job statuses at all, but still needs accurate payable hours and leave treatment.
This is why “what people did” and “what should be paid” are connected but not identical.
A good payroll design acknowledges that:
- raw time data may need interpretation
- some adjustments should be rule-based
- some exceptions require human approval
- the governing source for pay must be defined clearly
Without that, people end up arguing from whichever record suits them at the time.
Timesheets: flexible, familiar, and easy to argue with
Manual timesheets are still common because they are simple to understand. Staff enter the hours they worked, often allocating time across jobs, cost codes or activities.
That makes timesheets useful for one important reason: they capture intent and context.
A worker can record things that other systems often miss, such as:
- time spent on a callback
- workshop preparation
- travel between jobs
- waiting for materials
- training
- admin work
- overtime that happened outside normal scheduling
That flexibility is a strength. It is also the weakness.
Where timesheets work well
Timesheets are often suitable when:
- work is varied and not tightly structured
- staff split time across multiple tasks in a day
- off-job work is common
- labour allocation to cost codes matters
- supervisors are expected to review and approve claims
In those environments, a timesheet can be the most practical record of labour effort.
Where timesheets create problems
Timesheets rely heavily on memory, discipline and interpretation.
Common issues include:
- staff filling them in late
- rounded or estimated hours
- inconsistent allocation between jobs
- missing breaks
- duplicated travel claims
- supervisors approving without checking
- differences between timesheets and actual attendance
They also create friction when the business wants precise start and finish records but only collects reconstructed end-of-day entries.
If you pay directly from timesheets, you need to accept that you are paying from a claimed record, not necessarily an observed one. That is not automatically wrong, but it must be a deliberate choice with controls around it.
Clock events: better attendance evidence, but not a complete pay model
Clock events usually come from mobile apps, kiosks, vehicle tablets or location-aware field tools. They are often seen as more objective because they record an actual event: start, stop, break start, break end, site arrival, depot departure.
That can make them valuable for payroll control, particularly where attendance reliability matters.
Where clock events work well
Clock events are usually strong when the business needs:
- clear evidence of start and finish times
- tighter attendance control
- reduced reconstruction after the fact
- an audit trail for disputes
- more consistent break recording
- a record tied to location, device or timestamp
For high-volume field teams, clock events can reduce the amount of guesswork in payroll.
Where clock events fall short
Clock data tells you that an event happened. It does not always tell you what that time should mean for pay.
For example:
- clocked time may include unpaid breaks unless rules are applied correctly
- a worker may forget to clock out
- depot time and on-site time may need different treatment
- travel may be payable in some circumstances and not others
- a worker may be physically present but not working on a costed job
- employees may do internal work that has no matching job record
Clock events are good at recording presence. They are less good at explaining labour allocation and exceptions on their own.
If payroll is driven from clock events, the business still needs rules for interpreting those events into payable time.
Job statuses: useful for workflow, risky as a direct pay source
Job statuses can look attractive because they reflect real operational progress. A job moves to “en route”, “on site”, “work started”, “awaiting approval”, “completed” and so on. That sounds close to how labour happens in the field.
The problem is that workflow status is usually designed to move the job, not calculate wages.
Where job-derived time can help
Workflow-derived events can be powerful when used to support:
- job costing
- customer communication
- operational visibility
- stage-based handovers
- identifying delays
- measuring time between process steps
They can also help derive useful labour estimates where staff reliably update status in real time.
Why job statuses are dangerous as the sole payroll source
Status changes are often too coarse or too inconsistent to drive pay directly.
Common issues include:
- staff update statuses late or in batches
- a completed status does not show all labour on the job
- non-job work disappears completely
- multiple people work the same job but only one status is updated
- breaks, travel and waiting time are not represented properly
- a job can be operationally complete while payroll-relevant work is still happening
A workflow record is not automatically a payroll record. Using it as one without careful design usually creates disputes and distorted labour reporting.
If a technician marks a job complete to trigger invoicing, that action should not accidentally become the definitive payroll end time unless the business has explicitly designed it that way.
The real question: what should be the governing source for pay?
Most businesses do not actually need one source to do everything. They need one governing source for pay, with other records used as validation or supporting evidence.
That is a different design decision.
A practical way to think about it is this:
- Which source best reflects payable labour in your real operating model?
- Which source gives enough detail for job costing?
- Which source can be approved before payroll is processed?
- Which source produces an audit trail you can defend?
- Which exceptions are common enough that they must be built into the process rather than handled ad hoc?
The right answer depends on how the business actually works.
If your team works across varied tasks and indirect labour matters
A reviewed timesheet may need to be the governing source for pay, with clock events used as a control check rather than the pay source itself.
If attendance discipline is the main issue
Clock events may be the governing source, with supervisors adjusting exceptions and allocating time appropriately before payroll approval.
If work is highly structured and event-driven
Workflow data may support payroll, but it usually still needs an approval layer and an exception process rather than being used raw.
In other words, the question is not which data source is best in theory. It is which one most reliably represents payable time in your operating reality.
Mixing sources without rules creates bad payroll and bad reporting
Many businesses end up with a hybrid model by accident.
For example:
- payroll uses timesheets when they exist
- managers refer to clock events during disputes
- job costing uses scheduled hours or job statuses
- overtime is approved via email
- travel is added manually in payroll
- missing data is patched up at the end of the week
That may keep the pay run moving, but it creates a control mess.
When multiple sources exist without clear rules, you get problems such as:
- staff disputing which record counts
- inconsistent overtime treatment
- labour costs being booked differently from paid hours
- supervisors making undocumented adjustments
- reporting that cannot be reconciled later
- no reliable audit trail for how final pay was derived
This is where businesses often feel like their software is the problem. Often the bigger problem is that no one has defined the hierarchy of records.
A better design usually states something like:
- clock events are the raw attendance record
- timesheets are the labour allocation record
- payroll is calculated from approved payable hours
- job costing uses approved labour allocations, not unreviewed raw events
- any manual adjustment requires a reason and approver
Those rules do not need to be complicated. They do need to be explicit.
Travel, breaks and off-job work are where the model usually breaks
Most payroll control problems do not come from normal hours. They come from the edges.
If your source model does not handle exceptions well, managers start bypassing the system manually.
The main exception areas usually include the following.
Travel
Travel is rarely as simple as “clocked equals paid”.
You may need to distinguish between:
- travel from home to first site
- travel between sites
- travel back to depot
- special out-of-area travel
- travel for material collection
- passenger time versus driver time
Some of that may be payable. Some may be costed differently. Some may be recoverable to the customer. If your model cannot separate those cases, payroll and job costing both become unreliable.
Breaks
Breaks seem simple until they are not.
Questions usually include:
- Are breaks automatically deducted or explicitly clocked?
- What happens when someone misses a break?
- What if a break is interrupted?
- Do all roles follow the same rule?
- Does the job-costing view need break time separated from productive labour?
If the answer is “the payroll officer knows how to work it out”, the process is too dependent on individual memory.
Off-job work
A lot of payable time does not sit neatly inside a scheduled customer job.
Examples include:
- warehouse prep
- loading and unloading
- vehicle checks
- toolbox talks
- meetings
- training
- warranty rework
- quoting support
- admin follow-up after a completed job
If your model only recognises customer job time, this work either disappears or gets forced into the wrong place. That creates both pay issues and misleading profitability reporting.
Job costing and payroll should agree on labour logic
One of the most common operational problems is that payroll and job costing appear to use the same labour data but are actually built from different logic.
For example:
- payroll pays from clocked hours
- job costing uses timesheet allocations
- scheduling uses planned hours
- completed jobs report against estimated labour, not approved actual labour
That leads to endless confusion.
A manager looks at a job and thinks labour was 12 hours. Payroll paid 14. The scheduler says 10 were planned. Finance reports something else again. None of the numbers can be trusted because they come from different systems with different assumptions.
Good system design does not necessarily mean every number is identical. It does mean each number has a defined purpose and a traceable relationship to the others.
At a minimum, the business should be able to explain:
- what source creates raw time records
- how those records become approved payable hours
- how approved hours are allocated to jobs or cost codes
- how non-job labour is classified
- how payroll totals reconcile to labour reporting
If that chain is unclear, reporting will keep being challenged.
What a defensible audit trail actually looks like
An audit trail is not just “the data exists somewhere”. It is the ability to explain how final pay was produced.
For payroll time records, that usually means you can see:
- the original record
- any edits made to it
- who made the edit
- when they made it
- why it was changed
- who approved the final payable time
That matters for internal disputes as much as external compliance questions.
For example, if a clock-out time was corrected from 2:30pm to 4:00pm, the system should not simply overwrite the original and pretend it never existed. The same applies to manual adjustments for travel, overtime or missed breaks.
Without that history, payroll becomes hard to defend and managers start relying on memory and screenshots.
Approval before pay run is where control becomes real
Whatever your input model, the business needs an approval workflow before payroll is finalised.
That approval step is where raw records become payable time.
It should answer questions such as:
- Is this time complete?
- Does it match what actually happened operationally?
- Have breaks been treated correctly?
- Is travel handled according to policy?
- Has time been allocated to the right jobs or codes?
- Are there exceptions that need review?
- Is there a documented reason for any manual adjustment?
This approval should sit with someone who has enough operational context to judge the record properly. That may be a supervisor, service manager or team lead depending on the structure of the business.
If payroll is approving time without operational visibility, errors are more likely. If operations is approving without clear payroll rules, inconsistency follows.
The process needs both operational knowledge and defined control rules.
A practical way to choose the right model
If you are deciding which source should drive pay, it helps to work through the design in this order.
1. Map the types of time you actually need to pay
Start with reality, not software features.
List the categories that matter in your business, such as:
- ordinary hours
- overtime
- travel
- breaks
- workshop time
- meetings
- training
- standby
- leave
- rework
- internal admin
Until those categories are clear, no time-capture method will behave properly.
2. Decide which source best captures each category
One source may not be best for everything.
For example:
- clock events may capture attendance best
- timesheets may capture labour allocation best
- workflow statuses may support stage timing best
That is fine, as long as you still define which record governs pay and which records provide support or validation.
3. Define the hierarchy of truth
Be explicit.
For example:
- payroll starts from approved timesheets
- clock events are used to flag variances
- job statuses are used for operational visibility, not direct pay
- manual adjustments require notes and approval
Or:
- payroll starts from clock events
- supervisors allocate hours across jobs before approval
- unmatched time must be classified before export to payroll
The exact model varies. The clarity should not.
4. Design exception handling before automation
Do not build a “normal flow” and hope managers sort out the rest later.
Work through exceptions such as:
- forgotten clock-out
- split shifts
- emergency callouts
- travel outside standard rules
- incomplete job allocation
- work done without a scheduled job
- jobs that span multiple days
- shared labour across crews
If exceptions are frequent, they are part of the system, not edge cases.
5. Make final approval visible
Before the pay run, there should be a clear state showing that time is:
- submitted
- reviewed
- adjusted if required
- approved for payroll
That state matters because it creates accountability. It also prevents payroll from being driven by half-finished operational data.
What good looks like
A good payroll time model is usually less about clever automation and more about clean operational rules.
In a well-designed process:
- staff know what record they are responsible for entering
- the business knows which source governs pay
- exceptions have defined handling rules
- supervisors approve time before payroll processes it
- edits are visible and attributable
- payroll totals can be reconciled back to underlying records
- job costing uses approved labour logic rather than disconnected estimates
- reporting does not depend on someone manually stitching together three conflicting datasets
That does not mean every discrepancy disappears. It means discrepancies become visible, explainable and manageable.
The best source is the one that matches how your business really runs
There is no universal answer to whether your team should be paid from timesheets, clock events or job statuses.
Timesheets are flexible but subjective. Clock events are stronger for attendance but incomplete on their own. Job statuses are useful operational signals but often too weak to serve as direct payroll records.
The right model depends on:
- how structured the work is
- how much indirect or off-job labour exists
- how often exceptions occur
- what level of auditability you need
- how closely payroll and job costing need to align
What matters most is that the business chooses a governing source deliberately, defines how supporting records are used, and builds an approval process that turns raw activity into defensible payable time.
If your current setup mixes timesheets, clock data and job progress without clear rules, the underlying problem is usually not the staff or the software. It is the control model.
Where payroll, job costing and workflow all intersect, mapping the process properly before changing tools is usually the worthwhile step. That is the kind of operational design work 5M Consulting helps businesses think through.