Time and Labor
The Time and Labor mental model
What Time and Labor actually decides, why the processing order matters, and how to think about a time problem from the first stage rather than the last.
Learning objectives
- 1.Explain what the Time and Labor module decides and what it deliberately does not decide
- 2.State the five processing stages in order and name who owns each one
- 3.Diagnose a reported-time problem by naming the stage that failed rather than the symptom
- 4.Explain why retroactive changes to upstream data force recalculation
Why this matters
Most Time and Labor support tickets are not configuration bugs. They are people looking at the last stage of a five-stage chain when the failure happened at the first. Payroll is where the symptom appears, but payroll is rarely where the cause lives.
If you skip this: Debugging from the end wastes hours and produces changes to configuration that was working correctly.
What it is, why it exists, what breaks
What it is
Time and Labor takes reported time and decides whether it is valid, what it derives from it, and who is allowed to receive it. It does not decide what someone is paid, what a project costs, or what an absence is worth — those belong to Payroll, Project Costing and Absence Management.
Why it exists
Separating these decisions is what lets each downstream consumer apply its own rules to the same submitted time. Payroll validates against pay elements; Project Costing validates against open projects and cost segments. Neither should have to re-derive the time itself.
What breaks without it
If a consumer receives time it should not have received, the failure surfaces as wrong pay or wrong project cost, and the investigation starts in the wrong system entirely.
Source: OTL-CHAIN-002, OTL-CHAIN-001
Time and Labor processing chain
Each stage feeds the next, in order. A downstream symptom means the failure was upstream.
Reported time passes through five stages in order. Stage one: time entry rules validate the reported time automatically, and raise an entry exception if something is wrong. Stage two: managers resolve any exception raised. Nothing downstream runs until this happens, which is why an unresolved exception is the most common cause of a missing payslip. Stage three: calculation rules derive further time from the validated data, and they run only on data entry validation has accepted. Stage four: consumer validation checks the calculated data once per downstream consumer. Stage five: time consumer administrators transfer the data to payroll or project costing. Stages two and five need a person; the other three are automatic. A symptom at a later stage means the failure was earlier.
What to take from this: Three of the five stages are automatic and two need a person. When a payslip is wrong, ask which stage did not complete rather than which system misbehaved — and remember that a symptom at a later stage means the failure was earlier.
Source: OTL-CHAIN-001, OTL-CONSUMER-051
A project manager worked a full week and was paid nothing for it
A project manager submits their time card every Friday. On the last Friday of the month they query their payslip, find no pay at all for the month, and raise a ticket with the payroll help desk.
- 1.The payroll analyst checks the payroll input and finds no time element. Correct — nothing was transferred.
- 2.They ask whether the time card was submitted. It was, on time, and shows a Submitted status.
- 3.They look for entry exceptions. There is one, raised three weeks ago and never resolved.
- 4.They route it to the line manager, who clears it.
- 5.The time card is recalculated, the transfer runs for that approval period, and the pay appears on the next run.
Takeaway: The employee submitted correctly and the payroll system behaved correctly. The system was waiting for a manager, three weeks earlier. Every stage after the exception never ran.
Configuration model
Objects
Worker Time Processing Profile
Decides which repeating time period, time consumer set, HCM group and rule sets apply to a given population of workers.
Risk if wrong: Validation and calculation silently run against the wrong rules for the affected workers, and nothing announces it.
Time Consumer Set
Identifies which downstream consumers receive time for a group, and holds the consumer validation, approval period and transfer rules.
Risk if wrong: The right consumer never receives the time, or receives it too early.
Repeating Time Period
Supplies the date ranges used as time card periods, approval periods, overtime periods, accrual intervals and balance ranges.
Risk if wrong: Approval windows, overtime boundaries and balance calculations all shift, usually for every worker at once.
Constraints
- A single HCM group cannot be assigned to more than one time processing profile of the same type for an overlapping period.
- Once a time consumer set is associated with a worker time processing profile it can no longer be edited.
- Delivered repeating time periods cannot be edited; only name and description are editable on your own periods.
Source: OTL-CONSUMER-052, OTL-PERIOD-043
Common mistakes
Wrong: Starting the investigation in payroll because that is where the symptom appeared.
Symptom: An employee reports missing pay; the analyst opens the payroll input and finds nothing.
Fix: Ask whether the time card cleared entry validation. If not, nothing downstream ran and payroll was never involved.
Wrong: Re-running calculation repeatedly without resolving the exception first.
Symptom: Totals stay wrong no matter how many times the process is submitted.
Fix: Resolve the entry exception, then recalculate. Calculation rules run on data that entry validation accepted.
Wrong: Treating an empty overtime calculation as a payroll configuration problem.
Symptom: Overtime hours are zero for a worker who clearly worked them.
Fix: Check the overtime period on the worker time processing profile. A period that does not match the time card period is a documented possibility, not a bug.
Diagnosing it
Symptom: Reported time is not appearing in a downstream consumer.
Category: processing
- 1.
Does the time card show a Submitted status for the dates in question?
If no: The problem is submission or approval, not processing. Everything downstream is correctly waiting.
Evidence to capture: Time card status for the period
- 2.
Are there unresolved entry exceptions on the card?
If no: Entry validation passed, so the failure is at calculation, consumer validation or transfer.
Evidence to capture: Exception list on the time card
- 3.
Did calculation produce the entries the consumer expects?
If no: Calculation rules did not derive what this consumer needs. Check the rule sets on the profile.
Evidence to capture: Calculated entries on the time card after entry validation
- 4.
Did consumer validation pass for the specific consumer?
If no: The consumer rejected the data. Consumer validation is delivered by each consumer, so read its message rather than Time and Labor configuration.
Evidence to capture: Consumer-specific validation messages on the entries
- 5.
Did the transfer run for the approval period covering those dates?
If no: The data never left Time and Labor. Check whether the approval period has passed and whether a transfer is due.
Evidence to capture: Transfer status for the period, and the approval period on the time consumer set
Confirm: Once the transfer completes, re-query the consumer. If the data is still absent there, the problem has moved out of Time and Labor and into the consumer.
Recall
State the five Time and Labor processing stages in order, without looking, and say who acts at each one.
Answer shape: 1. Time entry rules validate reported time (automatic). 2. Managers resolve any time entry exceptions. 3. Calculation rules derive further time from the validated data (automatic). 4. Time consumer validation checks the result for each consumer (delivered by the consumer). 5. Time consumer administrators transfer the data (a human role).
Memory hook: Validate, Resolve, Derive, Check, Transfer — VR D C T. Only stages 2 and 5 need a person, and those are the two people forget to chase.
Source evidence
The five-stage order and the reporting channels are Oracle-documented and were read directly from the cited pages on 2026-10-05. The stage-ownership table and the diagnostic framing are the academy's teaching model, not Oracle statements.
Release scope: FA Latest
Recorded gaps
- Oracle publishes no attribute-level mapping between time entries and payroll or project costing fields, so any mapping you encounter is tenant-specific.
Related concepts
- Time entry rulesteaches
Entry validation is stage 1 and decides whether anything downstream ever runs.
- Time calculation rulesteaches
Calculation is stage 3 and is where derived time comes from.
- Repeating time perioddepends on
The periods on the profile define the boundaries every stage operates within.
- Payroll relationshipdepends on
A retroactive change to the payroll relationship forces recalculation of time card data.
Self-check
An auto-graded assessment is attached to this lesson: assessment-otl-mental-model
Lesson progress
Checking your progress…