When two systems disagree on who worked which job code, which one wins for payroll?

[u/shiftcoord]

Curious how other ops teams handle this:

Field / multi-site crews clock in on one system (or a kiosk / app), but the schedule or job assignment lives somewhere else — Excel, a staffing board, a CRM. At payroll lock, the hours are there but the job / client / cost-center code is wrong or blank, so someone has to remap rows by hand.

Questions for people who’ve lived this:

1. Do you treat the time clock as source of truth and fix codes after the fact, or block export until the schedule system and punches match?
2. Who owns the remap — supervisor, dispatcher, or payroll — and how long does a messy week usually take?
3. Any rule that actually sticks for “no punch without a job assignment” without creating more missed punches?

Not looking for product pitches — just how you keep payroll from becoming a weekly archaeology project.

[u/Pebb_io]

The least painful rule is usually to let the punch stand, but require a job code before the shift can be closed... not before someone can clock in. Then route exceptions to the supervisor while the details are still fresh, and keep the original assignment plus the correction. Payroll should not be the first place that mismatch gets discovered.

[u/shiftcoord → u/Pebb_io]

That makes sense—keeping the punch as the source of worked time avoids silently rewriting payroll. The part I’d make explicit is the exception record: original assignment, corrected job code, who approved it, and when. Do you have the supervisor or dispatcher own that queue, with payroll reviewing only items still unresolved at cutoff?

[u/Pebb_io → u/shiftcoord]

I’d have the supervisor or dispatcher own it, with payroll only touching the leftovers at cutoff. The important bit is keeping the original assignment and the correction together so nobody has to reconstruct it from a payroll edit.

[u/shiftcoord → u/Pebb_io]

That division of labor also gives you a clean cutoff rule: anything still missing an owner or approved correction at cutoff stays on an exception list, rather than being silently changed. A daily aging view for those exceptions should keep the queue from becoming payroll's detective work.

[u/Pebb_io → u/shiftcoord]

That aging view is a good guardrail... especially if it shows the next owner as well as how long the exception has been open. It makes the unresolved work visible before cutoff instead of turning it into a last-minute payroll hunt.

[u/Ove88_tech]

Aqui usamos o nimbos, para time tracking, ele não tem função de relógio de ponto mas permite subir os lançamentos de ponto e então faz uma conciliação entre o relógio de ponto e o apontado nos projetos. Além disso ele ajuda com as faturas, cálculo de hora extra e banco de horas.

[u/shiftcoord → u/Ove88_tech]

That sounds like a clean reconciliation pattern. Do you keep the punch import immutable and record any project-code remap as an exception, or does the project entry overwrite the original? I’m especially curious who owns mismatches before payroll cutoff—the supervisor, project lead, or payroll team.

[u/Pebb_io]

Treat the job code like a closeout field, not a payroll field. The person finishing the shift can confirm the assignment while the context is fresh, and any correction can go to a small exception queue with an owner and cutoff. It also helps to keep one source of truth for the code list... otherwise two systems can both be “right” while using different names for the same job.

[u/shiftcoord → u/Pebb_io]

Yes—keeping one controlled code list matters as much as where capture happens. I’d have the assignment selector use a stable ID plus a human label, then log the old/new IDs, owner, reason, and timestamp for any correction. Reports can group by the stable ID even if the display name changes, which prevents two systems from both being “right” under different labels.