Rate definitions: what one unit of absence costs

How a rate definition prices a single unit of absence — categories (Derived Rate, Element, Value by Criteria, Grade Rate, Formula), contributors with periodicity and factors, conversion to the return periodicity, and min/max rules — which of the four absence payment rate rules reference it, and why the rate is only resolved in payroll, never in Absence Management itself.

advanced18 min readFor HCM Functional Consultant, Absence Management Specialist, Payroll Integration Specialist, Learner new to Oracle HCMRelease FA Latest
  1. 1.State what a rate definition determines and where the rate is actually calculated and resolved
  2. 2.Associate a rate definition with an absence plan and name the four absence payment rate rules that use rate definitions
  3. 3.Choose a rate definition category and explain the Element storage types (Amount vs Factor) and their calculation paths
  4. 4.Build a derived rate: contributors, balance dimensions, periodicity conversion, factor rules
  5. 5.Apply minimum/maximum validation with the limit violation action, and decide live calculation versus the Generate HCM Rates process

An absence plan decides *how much* leave a worker has; the rate definition decides *what one unit of it costs*. Without it, the entitlement is a number with no price, and payroll has to improvise. But the boundary matters as much as the object: Absence Management names the rate rule and may point at a rate definition, while the actual calculation happens only in Global Payroll or a third-party payroll — and a derived rate is only as real as the payroll-run balances feeding it.

If you skip this: A plan wired to a rate definition whose contributing balances have never been populated by a payroll run produces no meaningful value at pay time — the absence is entitled, the rate is empty, and the failure appears in payroll, not in Absence.

What it is, why it exists, what breaks

A rate definition has a category — Derived Rate (values from payroll balances or other rates via contributors), Element (an element input value: storage type Amount reads the Primary Input Value of flat-amount elements like salary, Factor reads the Factor value of factor-rule elements), Value by Criteria (a condition tree), Grade Rate (grade details), or Formula — plus contributors (add/subtract, each with balance dimension and periodicity), a mandatory return periodicity, conversion formulas, factor rules, currency/rounding, and min/max rules with a limit violation action. Absence plans reference the rate from their rate rules on the Entries and Balances tab: Absence Payment, Final Balance Payment, Partial Disbursement, and Liability Booking.

The category chooses where the value comes from; the contributors and periodicity conversion make rates composable (salary + car allowance = one absence rate); the min/max rules are the validation that keeps a bad rate from reaching pay; and the four absence rate rules are the only places an absence plan consumes a rate at all.

Three silent breaks: rates are calculated only in payroll, so defining everything in Absence and nothing in payroll leaves the money undefined; factor-based Element rates are not calculated by the payroll run and need the Generate HCM Rates process; and a derived rate whose balances were never fed by payroll runs generates no meaningful value.

Source: ABS-RATE-001, ABS-RATE-003, ABS-RATE-004, ABS-RATE-007

A rate definition as a conversion pipeline

Category picks the source, contributors convert and sum, the total converts once to the return periodicity, min/max validates — and payroll, not Absence, resolves it. Listed in order: Category picks the source, then Contributors convert, then sum, then Total converts to the return periodicity, then Min/max validation, then Plan rate rule, then payroll resolves.

A rate definition read as a conversion pipeline. A category chooses the value source — Derived Rate (payroll balances or other rates via contributors), Element (Amount reads a flat-amount element’s Primary Input Value, Factor reads a factor-rule element’s Factor value), Value by Criteria, Grade Rate, or Formula. Each contributor is converted to its own periodicity, factors (Value multipliers) apply before conversion, and the add/subtract total is converted once more into the mandatory return periodicity and currency using a predefined conversion formula (Standard Rate Annualized, Standard Rate Daily, the working-hours variants) or a custom rule. Minimum and maximum rules with a Limit Violation Action (error, warning, enforce) validate the result; Return FTE Rate pro-rates for part-time workers. The finished rate is referenced from the absence plan’s Entries and Balances tab under one of four rate rules — Absence Payment, Final Balance Payment, Partial Disbursement, Liability Booking — all optional because rates can be defined on the payroll side. The boundary is the point: the rate is calculated and resolved only in Global Payroll or a third-party payroll, and a derived rate whose contributing balances were never populated by payroll runs generates no meaningful value.

A derived rate over balances no payroll run populated yields no value at pay time, and the failure shows in payroll, not in Absence.

What to take from this: Read the diagram as a conversion pipeline, not a lookup: contributors are each converted to their own periodicity, added or subtracted with factors applied first, then the total is converted once more into the return periodicity and currency — and only after min/max validation does a rate exist, which payroll (never Absence) then resolves against the plan’s rate rule.

Source: ABS-RATE-007, ABS-RATE-008, ABS-RATE-001

The entitled absence with no price

A sickness qualification plan grants 90 days at 75% pay via bands, and the implementer creates a rate definition for the Absence Payment Rate Rule but forgets that its contributors are balances — Regular Salary and Car Allowance — with dimension Assignment State Period to Date, while no payroll run has ever populated those balances for the workers in scope.

  1. 1.The plan is configured correctly: bands define the 75%, the Absence Payment Rate Rule points at the rate definition, and the rate definition itself looks right — Derived Rate, daily return periodicity, both contributors Add.
  2. 2.A worker records sickness and is entitled per the plan; the rate rule fires and asks the rate for its value.
  3. 3.The balances behind the contributors are empty for the dimension period, so the rate generates no meaningful value — the process note says exactly this.
  4. 4.Payroll resolves the absence payment with no rate behind it, and the discrepancy surfaces in payroll results, not in any Absence page.

Takeaway: A derived absence rate is a payroll object wearing an Absence interface. Before wiring it into a plan, confirm the contributing balances are populated by payroll runs for the dimension period, and set Process Contributor Total as FTE Amount when part-timers must be pro-rated — otherwise the entitlement exists but the price does not.

Source: ABS-RATE-009, ABS-RATE-003

Configuration model

Navigation paths

  • Absences work area > Manage Rate Definitions task — create the rate definitionABS-RATE-002
  • Home > My Client Groups > Rate Definitions quick action > Search Results > CreateABS-RATE-009
  • Absences work area > Manage Absence Plans > Entries and Balances tab — select the rate definition from the rate rule lists (e.g. Disbursement Rate Rule)ABS-RATE-002

Objects

Rate definition

Prices one unit of absence: category (Derived Rate, Element, Value by Criteria, Grade Rate, Formula), name and short name, legislative data group, effective start date, status (active/inactive), employment level for derived and criteria rates.

Risk if wrong: An inactive rate cannot be assigned; an effective start date earlier than the referenced objects’ creation dates breaks the references.

Rate contributors

The add/subtract inputs of a derived rate — Balance contributors name the balance and balance dimension (e.g. Assignment State Period to Date) with a periodicity; factors (Value multiplier) apply to contributors or the total before periodicity conversion.

Risk if wrong: Balances not populated by payroll runs for the dimension period yield no meaningful value; a factor applied after conversion instead of before changes the result.

Returned rate details

The mandatory return periodicity (hourly, daily, weekly, annually), currency, decimal display, rounding, factor rule, Return FTE Rate for part-time pro-rating, and minimum/maximum with a Limit Violation Action (error, warning, enforce).

Risk if wrong: No periodicity means no conversion target; min/max without an action lets out-of-range values through silently or blocks them without explanation.

Absence plan rate rules

On the Entries and Balances tab, the four rules that consume a rate definition: Absence Payment Rate Rule, Final Balance Payment Rate Rule, Partial Disbursement Rate Rule, Liability Booking Rate Rule — all optional in Absences; rates can instead be defined on the payroll side.

Risk if wrong: Selecting Transfer absence payment information without defining rates anywhere leaves payroll to resolve payments with no rate source.

  • A rate definition determines the rate of a single unit of absence for payment during an absence period, but rates are calculated and resolved only in Global Payroll or a third-party payroll application.
  • Create the rate definition with the Manage Rate Definitions task in the Absences work area (or the Rate Definitions quick action under My Client Groups); associate it with the plan on the Entries and Balances tab of the Manage Absence Plans task.
  • The four absence payment rate rules supporting rate definitions are Absence Payment, Final Balance Payment, Partial Disbursement and Liability Booking.
  • Element category storage types: Amount reads the Primary Input Value (flat-amount elements such as salary); Factor reads the Factor input value (factor-rule elements) — salary rates support Factor but the payroll run does not, so use Generate HCM Rates for those.
  • Employment Level (Payroll Relationship, Term or Assignment) is mandatory for Derived Rate and Value by Criteria definitions.
  • Periodicity is mandatory for the returned rate and each contributor; contributors are converted to their own periodicity, summed, then converted to the return periodicity and currency via predefined or custom conversion formulas.
  • Factor rules apply before periodicity conversion; minimum/maximum can be a fixed value, based on another rate (loops are a runtime error), or a value by criteria, with a limit violation action of error, warning or enforce.
  • Reporting Required stores the calculated value on the rate table via the Generate HCM Rates batch process and feeds HCM extracts to third parties.

Source: ABS-RATE-001, ABS-RATE-002, ABS-RATE-003, ABS-RATE-004, ABS-RATE-006, ABS-RATE-007, ABS-RATE-008, ABS-RATE-010

Common mistakes

Wrong: Expecting Absence Management to compute the payment.

Symptom: The plan has a rate rule selected and the entitlement is right, but the payslip shows nothing or a default — the rate was never calculated, because only payroll resolves rates.

Fix: Rates are calculated and resolved only in Global Payroll or a third-party payroll; wire the absence element entry through the absence interface so payroll receives it.

Wrong: Defining a factor-based Element rate and expecting the payroll run to calculate it.

Symptom: The rate value is missing in the payroll run even though the definition is valid.

Fix: Salary rates support Factor storage, but the payroll run does not calculate it — run the HCM Generate Rates process and let payroll retrieve the stored value.

Wrong: Building a derived rate over balances no payroll run has populated.

Symptom: The rate generates no meaningful value when the absence is paid; the error appears in payroll, not in Absence.

Fix: Confirm the balance dimension (e.g. Assignment State Period to Date) is covered by payroll runs, as the worked example warns.

Wrong: Summing contributors in mixed periodicities directly.

Symptom: The rate is wrong by a conversion factor; the UI converts each contributor to its own periodicity first, sums, then converts to the return periodicity.

Fix: Set a periodicity on the returned rate and on every contributor; the conversion formulas (Standard Rate Annualized, Standard Rate Daily, and the working-hours variants) do the rest.

Wrong: Setting a min/max based on another rate that loops back.

Symptom: A runtime error when the rate is evaluated: Rate A’s minimum is based on Rate B whose minimum is based on Rate A.

Fix: Keep the min/max reference graph acyclic; use a fixed value or a value by criteria instead.

Diagnosing it

Symptom: An absence is entitled and the plan names a rate definition, but the payroll result shows no absence payment (or a wrong one).

Category: configuration

  1. 1.

    Is the rate definition actually selected on the right rate rule (Absence Payment, Final Balance, Partial Disbursement, Liability Booking) on the plan’s Entries and Balances tab?

    If no: The plan never asks the rate for a value; the rule fields are optional, so nothing transfers and payroll has no rate source.

    Evidence to capture: The Entries and Balances tab of the plan versus the payroll result

  2. 2.

    Was the rate ever calculated — live in the payroll run, or via Generate HCM Rates into the rates reporting table?

    If no: Absence only defines the rate; if no calculation path ran, there is no value to resolve. Factor-based element rates need the Generate HCM Rates process specifically.

    Evidence to capture: The rates reporting table for the worker, and the payroll run log

  3. 3.

    For a derived rate, are the contributing balances populated by payroll runs for the balance dimension period?

    If no: The rate generates no meaningful value — the worked example states this explicitly for Assignment State Period to Date.

    Evidence to capture: Balance values for the dimension and period on the worker’s payroll results

  4. 4.

    Do the contributor periodicities and the return periodicity convert as expected — factors applied before conversion, total converted once to the return periodicity?

    If no: The value is off by a conversion step; check each contributor’s periodicity and the conversion formula used.

    Evidence to capture: The rate definition’s contributors and Returned Rate Details

  5. 5.

    Did a min/max limit violation action (error/warning/enforce) silently clamp or block the returned rate?

    If no: The rate may have been enforced to the limit; check the Limit Violation Action against the raw calculated value.

    Evidence to capture: The min/max settings and the returned value versus the calculated one

Confirm: Work outward from the payroll result: rate rule selected on the plan, calculation path ran (live or Generate HCM Rates), balances populated for the dimension, conversion and factor order correct, limit action understood — Absence defines, payroll resolves.

What does a rate definition determine, where is the rate actually calculated, and how does a derived rate get its value?

Answer shape: A rate definition determines the rate of a single unit of absence for payment during an absence period, but rates are calculated and resolved only in Global Payroll or a third-party payroll. It is created with the Manage Rate Definitions task (Absences work area) or the Rate Definitions quick action under My Client Groups, and associated with the plan on the Entries and Balances tab via one of four rate rules: Absence Payment, Final Balance Payment, Partial Disbursement, Liability Booking — all optional; rates can live on the payroll side. Categories: Derived Rate, Element (Amount or Factor storage), Value by Criteria, Grade Rate, Formula. A derived rate sums contributors — each converted to its own periodicity, factors applied before conversion — then converts the total to the mandatory return periodicity and currency; min/max rules with a limit violation action validate the result. Factor-based element rates need the Generate HCM Rates process; Reporting Required rates are stored on the rate table for reporting and extracts.

Memory hook: Absence defines the rate, payroll resolves it. Contributors convert, sum, convert again. Balances need payroll runs first.

Source evidence

Chapter 6 of the Implementing Absence Management book (faiam) was read directly on 2026-11-07: the four absence payment rate rules and the payroll-only resolution rule, the rate definition categories and overview, the full configuration field set (storage types, employment level, periodicity conversion, factor and min/max rules, override/defaulting), and the worked Derived Rate leave example.

Release scope: FA Latest

Recorded gaps

  • The pages describe rate definition fields generically; the exact field labels of the Create Rate Definition page beyond the worked example’s tables are not enumerated, so they are not asserted.
  • How the absence interface passes the entry to payroll (the handoff mechanics) is named only as "the absence interface" on the example page; the detail lives in the payroll integration books and is not asserted here.
  • The predefined conversion formula list is quoted from the options page; their internal math is not reproduced.
  • The accrual plan, configureddepends on

    The accrual plan lesson wires the Final Balance Payment, Disbursement, Absence Payment and Liability Booking rate rules on the Entries and Balances tab — this lesson is what a rate definition actually is.

  • Fast formulas in Absence Managementextends

    The payment-rate formula (Global Absence Plan Use Rate) calculates payment during the absence; the rate definition supplies the underlying value that formula may consume.

  • Absence certificationsreferenced by

    Certification phases reevaluate entitlements with Override payment percentages — the money those percentages resolve against comes from the rate definition.

An auto-graded assessment is attached to this lesson: assessment-absence-rate-definitions

Start self-check

Checking your progress…

Rate definitions: what one unit of absence costs · Oracle Fusion Cloud HCM · HCM Studio by Digi Tracks · www.digitracks.net · contact@digitracks.net

Claims: ABS-RATE-001, ABS-RATE-003, ABS-RATE-004, ABS-RATE-007, ABS-RATE-009, ABS-RATE-002, ABS-RATE-006, ABS-RATE-008, ABS-RATE-010

Oracle, Oracle Fusion Cloud HCM and the Oracle logo are trademarks of Oracle Corporation. HCM Studio is an independent training product, not affiliated with or endorsed by Oracle.