Summary
Payroll exception methodology explains how time review state becomes safe payroll action. It separates raw time rows, operator edits, exception rules, source refreshes, sync blockers, and external dispatch.
Reader Question
How do time rows, pay types, edits, source refreshes, sync blockers, and exceptions become reviewable payroll state?
Methodology
Time review services build row and day-level state from source data. Operators apply edits, overrides, and exception decisions in the review surface. Cell rules, blockers, risk checks, and sync scope logic decide whether the selected state can be dispatched.
Source refresh remains separate from sync dispatch. If data is stale or a prior sync failed, blockers keep the operator in review instead of pretending the write succeeded. External sync jobs consume explicit requests and payloads.
Boundaries
The UI presents review state. API routes adapt operator intent. Time-review services own rules and sync requests. Data-sync jobs own external payroll write behavior.
Tradeoffs
The method makes payroll sync more deliberate than a bulk submit. That is appropriate because payroll mistakes require explicit review, repair, and auditability.
Related Threads
- Payroll Sync And Exceptions Workflow
- Payroll Time Review Workflow
- Payroll Sync Blockers