Time and Labor in Oracle Fusion HCM: Configuring Time Cards Without the Headaches

Time cards are usually the module that looks perfectly fine in testing and then falls apart in the first real payroll cycle. An employee enters overtime, and nothing flags it. A manager approves a time card and the compensatory time balance doesn't move. A brand-new payroll element shows up nowhere on the time card entry screen, even though it was built correctly. None of these are bugs. They're Oracle Fusion Time and labor configuration steps that exist outside the obvious setup screens, and skipping them produces exactly this kind of quiet, confusing failure.

This walkthrough covers the configuration objects that have to exist before a time card can even be entered, how time entry layouts and fields actually connect to what employees see, how time consumer sets control validation and payroll transfer, and what changes when Absence Management and overtime rules get layered on top.

Six pieces need to exist and connect correctly before an employee can submit a usable time card: time card elements built from payroll earnings, a data dictionary generation step that makes those elements available for tagging, time entry layout components and fields, a layout set that bundles those fields for a specific population, a time entry profile assigned to each worker, and a time consumer set that defines validation and approval behavior. Miss the middle step and everything built around it looks correct while quietly not working.

That middle step is the one that trips up more implementations than any other single gap: after creating or editing payroll earnings elements such as Regular, Overtime, or Shift Pay, running the element itself isn't enough. The Generate Time Attributes for the Data Dictionary process has to run before that element becomes available as a time card field option at all. Skip it, and a perfectly configured payroll element simply doesn't appear when someone goes to build the time card layout, with no error message explaining why. It looks like the layout configuration is broken. It's actually a missing process run two steps earlier.

Think of it like building a house where the electrical wiring has to be inspected and signed off before drywall goes up. The wiring itself might be perfect, but nobody can legally close the wall around it until that inspection happens. The data dictionary generation step plays the same role here. The element exists and is technically correct, but it isn't usable by anything downstream until that specific process runs.

For the payroll elements this configuration depends on, Oracle Fusion payroll configuration without the costly mistakes is worth reading first if that setup hasn't happened yet.

Time entry layout components define individual fields on a time card, either single-attribute fields tied to one piece of data or multiple-attribute fields that can hold several related values at once, such as a payroll time type paired with a project expenditure type in the same field. Layout sets then bundle those fields together for a specific worker population or time consumer, controlling what actually renders on screen.

One detail catches people off guard during setup and rarely gets flagged until testing: the matrix page used to build these fields displays drop-down list values truncated to their first fifteen characters. A field or attribute name that reads clearly in the setup screen can become genuinely ambiguous once it's cut down to fifteen characters in that specific dropdown, especially when several similarly named custom attributes exist side by side. Naming conventions that account for this truncation from the start save real confusion later, both for implementers and for the employees eventually choosing between options that all look identical at a glance.

Layouts also support role-based differentiation that's easy to underuse. The same field can behave differently depending on who's viewing it. A night-shift allowance field, for example, can be configured to appear as read-only for the worker submitting the time card while remaining fully editable for the line manager or time and labor manager reviewing it. This isn't a workaround. It's a built-in property of unified fields, and implementations that don't take advantage of it often end up building separate, redundant fields to achieve the same result.

Newer capability worth knowing about here: recent releases added a scheduled hours header row that can display between the period days and the card's attribute rows, showing scheduled start and end times or scheduled hours per day directly on enhanced time cards. Grid columns and rows also became resizable, and that resizing now persists if the same employee reopens their time card on the same device. Small changes, but they meaningfully reduce the friction of comparing scheduled versus actual time without leaving the time card screen.

If configuration details like these are where your team keeps hitting friction, book a free HCM demo class with TechLeads IT's Oracle Fusion HCM training program and see how Time and Labor setup gets covered hands-on, including the data dictionary step most teams discover only after something breaks.

A time consumer set defines the validation rules, approval periods, and transfer rules for one or more applications that actually consume time data, most commonly Global Payroll, Project Costing, and the Project Execution Management offering. It's built on top of a time category, which has to exist first since the time consumer set references it directly. A single time consumer set can be assigned to multiple worker time processing profiles, but each processing profile can only ever use one time consumer set at a time.

Here's the configuration detail with real downstream consequences: a time consumer set can be set to validate only on Submit, or on both Submit and Save. The difference sounds minor until a specific scenario plays out. If someone deletes a time card entry tied to a now-closed project and resubmits the card, that deleted entry doesn't get validated against Project Costing rules under a Submit-only configuration. The same gap shows up if an existing entry gets reassigned from a closed project to an open one. The employee sees no warning. The time card submits cleanly. The problem only surfaces later, downstream in Project Costing, disconnected from the moment it was actually created.

The fix isn't complicated once the cause is understood: any time consumer set that includes Project Costing and validates only on Submit should be replaced with one that validates on both Submit and Save, and the relevant worker time processing profiles need to be updated to use it. A related enhancement addressed a second layer of the same problem: entries validated earlier in the process weren't always re-validated at final submission, meaning a project that closed between initial entry and submission could slip through unnoticed. Enabling re-validation on updated entries, through a dedicated profile option at the site level, closes that gap so time cards are checked against current data at the moment they're actually submitted, not just against whatever was true when the entry was first typed.

What happens if this configuration gets left at default settings across a large implementation? Nothing visibly breaks during testing, because the scenario that exposes the gap, a project closing between entry and submission, doesn't happen on a predictable schedule. It shows up weeks or months later, as a billing discrepancy nobody can immediately trace back to a validation timing setting made during initial configuration.

Absences don't automatically display or become editable on time cards just because Absence Management is implemented alongside Time and Labor. The Absence Types task controls this directly through an "Enable for time card entry" setting, and the time card itself needs dedicated fields configured to carry the Absence Management Type and, where compensatory time is involved, the Compensatory Time Absence Plan attribute. Without both pieces in place, absences either don't appear on the time card at all or appear without the detail needed to process them correctly.

Overtime works through a related but separate mechanism: time calculation rules. A straightforward example is a rule that flags anything over twelve hours in a single day, generating an error the employee sees before submission rather than a problem discovered during payroll processing. These rules can be built to reflect genuinely different policies across regions or worker populations, which matters for any organization operating in more than one jurisdiction with different overtime thresholds.

One behavior change is worth calling out directly because it contradicts what a lot of implementers still assume: compensatory time balances don't increase the moment an employee saves or submits a time card. They update after the time card is actually approved. Earlier behavior worked differently, crediting the balance as soon as time was reported and saved, which meant an employee could see compensatory time available before a manager had reviewed anything. Current behavior ties the balance update to approval specifically, which is a meaningfully different sequence to design communication and manager training around.

Misconception: once a payroll element exists, it's automatically available as a time card field.

Reality: the Generate Time Attributes for the Data Dictionary process has to run after the element is created before it becomes selectable in the time entry layout setup. Why it matters: teams troubleshoot the layout configuration when the actual cause is a process that was never run.

Misconception: time consumer set validation behaves the same regardless of when it's configured to run.

Reality: a Submit-only validation setting can miss entries tied to a project that was closed and reassigned between initial entry and final submission, while Submit and Save validation catches this. Why it matters: this gap produces no visible error and surfaces later as a billing or costing discrepancy, disconnected from its actual configuration cause.

Misconception: compensatory time balances update as soon as an employee saves their time card.

Reality: balances increase after time card approval, not at save or submission. Why it matters: employees and managers who expect immediate balance updates can misread the system as broken when it's behaving as designed.

Q: What configuration is required before employees can enter time cards in Oracle Fusion?

A: Before anyone can enter a time card, several things need to be in place: payroll elements with the Generate Time Attributes process already run against them, the layout fields and layout set built around those elements, a time entry profile assigned to the worker, and a time consumer set that handles validation and approval. Skip any one of these and the time card either won't show the right fields or won't process correctly downstream.

Q: What is a time consumer set in Oracle Fusion Time and Labor?

A: A time consumer set tells Oracle Fusion who actually uses reported time and how to handle it: validation rules, approval windows, and transfer logic for things like Global Payroll or Project Costing. It sits on top of a time category, which has to exist first. You can reuse one time consumer set across several worker processing profiles, but each profile only ever points to one set at a time.

Q: Why isn't a new payroll element showing up as a time card field option?

A: Nine times out of ten, it's because the Generate Time Attributes for the Data Dictionary process hasn't been run yet. Building the element in payroll is only half the job. Until that process runs, the element just won't appear as an option when you're setting up time entry layout fields, and there's no error message telling you why.

Q: What's the difference between Submit-only and Submit-and-Save validation in Time and Labor?

A: Submit-only validation only checks entries at the moment someone submits a time card. That leaves a gap: if an entry gets tied to a project that closes between the original entry and resubmission, it can slip through unvalidated. Submit-and-Save validation checks at both points instead, which catches that scenario.

Q: How do you configure absences to display correctly on Oracle Fusion time cards?

A: Two things have to happen. First, turn on "Enable for time card entry" for the relevant absence type. Second, add the right fields to the time card layout itself: the Absence Management Type attribute, and if compensatory time is involved, the Compensatory Time Absence Plan attribute too. Miss either step and absences either won't show up or won't carry enough detail to process.

Q: When do compensatory time balances actually update in Oracle Fusion?

A: Not when you'd expect. Balances only update once a time card gets approved, not when it's saved or submitted. Earlier versions worked differently and credited the balance right after saving, so if your team remembers it working that way, that's why it feels off now.

Time and Labor rarely fails because a screen was configured wrong. It fails because a step outside the obvious configuration flow- a data dictionary generation process, a validation timing setting, an approval-linked balance update- gets assumed rather than verified. Each of these has a specific, documented cause and a specific fix. None of them require guesswork once you know where to look.

Book a free HCM demo class with Oracle Fusion HCM training to see Time and Labor configuration covered hands-on, including the exact sequence of steps most implementations only learn after something quietly breaks in production.