Benefits and Total Rewards

Benefits setup defines benefit plans and eligibility rules. Operations records employee life events, checks eligibility, manages waivers and enrolments, reconciles provider invoices to enrolment and payroll data, and generates versioned total-reward statements. The workspaces are split between HR → Setup → Talent And Benefits Setup and HR → Operations → Employee Lifecycle And Relations → Benefits.

This guide distinguishes a plan, an eligibility decision, an employee enrolment, a payroll contribution, a provider invoice, and a total-reward statement. They are related but not interchangeable records.

Access and prerequisites

The active company-service needs HR Benefits and Total Rewards enabled. User permissions remain a separate requirement. Users also need the particular view/create/update permission for the plan, rule, life-event, waiver, enrolment, invoice, or statement action. A capability does not grant an employee access or a manager/reviewer role; see Capabilities and Access.

Configure and approve the plan before its rules or enrolments. Confirm service scope, contribution values, currency, effective dates, approval configuration, and payroll treatment before opening enrolment. Shared documents used as evidence must be approved and available in the same HR service.

Benefit plans

Benefit Plans are configured under Talent And Benefits Setup. A plan records its name, type, provider, description, employee and employer contribution amounts, currency, effective dates, active state, and approval state. Types in the current form include health and life insurance, pension, dental, vision, education, housing, transport, meal, and other.

The plan defines the contribution basis used by the current enrolment and provider-invoice workflows. It is not, by itself, evidence that an employee is enrolled, that payroll deducted a contribution, or that the provider was paid. Keep new terms effective-dated rather than changing an old plan in a way that rewrites historical statements or invoice expectations.

Eligibility rules and eligibility checks

Create rules for a specific plan. The rule code is generated by the backend from the HR ID template; users enter the rule name and conditions, not the code. The current model supports:

• Base rules: optional employment-type restriction, minimum service days, minimum/maximum age, evidence requirement, waiver allowance, and effective dates.
• Life-event rules: the same base conditions plus an event type and a positive event window. The employee must have an approved matching life event within the configured window; required evidence must be present.

The eligibility check is evaluated for an employee, plan, and as-of date. It can return eligible, waived, pending a qualifying life event, or ineligible, with a reason. An approved waiver covering the as-of date blocks enrolment. An employee may qualify through a base rule or a qualifying life-event rule.

Important current behavior: when no active approved eligibility rule exists for a plan on the requested date, the eligibility procedure treats an approved employee as eligible by default. Configure explicit rules if default-open eligibility is not acceptable for the plan. Creating a rule does not retroactively create enrolments or change prior payroll snapshots.

Eligibility decision order

Use the eligibility result as a decision record, not as an enrolment. Establish the facts in this order:

1. Is the employee approved, active and within the active HR service scope?
2. Is the plan approved, active and effective on the requested enrolment date?
3. Is there an active approved eligibility rule for the plan/date? If not, the current procedure is default-open for an approved employee. This is a consequential policy decision, not an implicit “no rule means deny”.
4. For a base rule, does employment type match, is minimum service met, and is the employee within any minimum/maximum age bounds?
5. For a life-event rule, is there an approved matching event inside its configured event window?
6. If evidence is required, is acceptable evidence actually present and approved? A note that says “seen” is not linked/approved evidence.
7. Does an approved waiver overlap the requested enrollment date? An applicable waiver blocks enrollment during that window.
8. Does an active or suspended enrollment already overlap for this employee and plan? Resolve that record before retrying.

The decision can indicate eligible, ineligible, waived, or pending a qualifying life event/evidence. Investigate its explanation before changing employee data or adding another rule.

Illustrative example only: a tenant defines a base rule requiring 90 days of service and evidence. An employee at day 70 does not meet that base rule. If the same plan has a separately approved qualifying life-event rule and the employee has an approved matching event inside its configured window, evaluate that rule as a separate path. This example illustrates rule evaluation only; it is not a recommended eligibility policy or statutory standard.

Life events

Record an employee's life event in the Benefits operations workspace. Supported event types include marriage, birth, adoption, dependent change, divorce, disability, and other. The record captures employee, event date, details, and an optional approved shared-document reference. A reviewer can approve, reject, or cancel the event; rejection requires an explanation.

A life-event record does not automatically enroll the employee or change a contribution. The event must be approved and must match a rule's event type and window. The eligibility check/enrolment process then evaluates the event alongside the plan's base conditions and evidence requirement. Keep sensitive supporting material in the approved document workflow rather than placing confidential details in free-text notes.

Record the event type/date and a minimal descriptive summary, attach the approved document reference where required, then have an authorized reviewer approve, reject or cancel it. Rejection needs a reason. After approval, run eligibility for the intended plan and effective date, then create the separate enrolment. Do not backdate coverage merely because the event occurred earlier; use the supported effective date and retain the decision history.

Waivers

A waiver is an employee's dated request to decline a specific plan. It records employee, plan, valid-from/to dates, a required reason, optional notes, and optional approved life-event and evidence references. A reviewer records the outcome; statuses include Submitted, Approved, Rejected, and Expired.

An approved waiver only applies during its validity window. An approved waiver covering the enrolment date prevents enrolment in that plan. A waiver is not the same as an eligibility denial: eligibility asks whether the employee qualifies; the waiver records that the employee declines or opts out despite the offer. Reassess eligibility and contribution effects through the supported workflow after a waiver is rejected, expires, or is superseded.

Employee enrolments

Create an enrolment by selecting an approved employee and plan, then recording the enrolment date, optional end date, status, and notes. The employee must be approved, active, and in the selected HR service; the plan must be approved, active, in service scope, and effective on the enrolment date. When rules exist, the procedure checks eligibility and any approved waiver. It also prevents overlapping active or suspended enrolments for the same employee and plan.

Current enrolment statuses are Active, Suspended, Terminated, and Expired. The enrolment status describes operational coverage; approval status separately shows whether the record is approved or awaiting/requiring a decision. End dates must not precede the enrolment date or extend beyond the plan's effective end. Use suspension to pause coverage without erasing its history, and end-date/terminate an enrolment when coverage actually ends.

Enrollment state	Operational meaning	Review question
Active	Coverage is in force for its effective interval.	Is the employee, plan, eligibility result and contribution effective for the payroll/invoice period?
Suspended	Coverage is paused but history remains.	Is there a dated reason and a clear resumption/end decision? Confirm payroll treatment rather than assuming suspended coverage is active.
Terminated	Coverage ended by an explicit action/date.	Does the end date agree with the employee's choice or lifecycle event and provider record?
Expired	The effective interval elapsed.	Is renewal/re-enrolment required, or should coverage remain closed?

Approval state is separate. A submitted enrollment is not approved coverage; an approved record is not currently effective when its start date is in the future or end date has passed.

An approved active or suspended enrolment that overlaps an invoice coverage period can contribute to the provider invoice's expected amounts. The current reconciliation considers plan contribution values and the coverage window; confirm the plan's contribution model is suitable before relying on this calculation for complex tiered or dependent-based pricing.

Payroll deductions and employer contributions

When the payroll input policy includes Benefits, approved eligible enrolments can provide benefit inputs to payroll. Employee contributions and employer contributions are distinct amounts and payroll source lines. The payroll run consumes approved inputs into its snapshot; later edits to a plan or enrolment must not be assumed to rewrite a run that has already consumed its sources.

Verify the applicable payroll policy, source ledger, approved run, and run lines before representing a deduction or employer contribution as processed. A configured plan amount or an approved enrolment alone is not proof of a payroll deduction, a GL posting, or payment to a provider. See Payroll for period, snapshot, approval, posting, payment, and remittance steps.

Provider invoices and reconciliation

Record an invoice with the benefit plan, provider, invoice number/date, coverage window, billed employee and employer contributions, total, and one or more employee-enrolment lines. A payroll run may be linked when it is approved or posted and its period exactly matches invoice coverage dates.

The Reconcile invoice action compares each invoice line with an eligible enrolment and the plan contribution values, totals billed and expected employee/employer amounts, and—when linked—checks consumed approved benefit inputs in the selected payroll run. It records variance, source counts, notes, and a reconciliation status. An invoice can become Matched or Exception. A matched invoice can be approved; an exception should be investigated and corrected or rejected rather than approved as though it reconciled.

Invoice approval is a control decision, not settlement. The current Benefits invoice workflow does not itself show a provider payment or GL settlement action. Record and verify any actual provider payment through the appropriate payment/accounting workflow; do not infer payment from an Approved invoice status.

Invoice reconciliation checklist

Before approving, reconcile each employee line and then the totals:

1. Check provider, invoice number/date, plan, currency and coverage dates against the provider invoice.
2. Confirm every employee/enrolment line refers to approved enrollment that overlaps the invoice coverage interval.
3. Compare billed employee and employer contributions separately with the expected plan amounts. Do not net employee withholding against employer contribution or compare only a combined total.
4. If a payroll run is linked, confirm service scope, approval/posting state and exact coverage dates. Reconcile against benefit inputs actually consumed by that run, not only planned enrollment amounts.
5. Review the result. Matched means internal reconciliation passed; Exception means a variance or missing source needs investigation. Fix the source or reject/return the invoice as permitted.
6. Approve only after invoice, line totals and payroll match are acceptable. Then settle through the owning finance/payment workflow and verify payment settlement and GL separately.

Retain the invoice, reconciliation outcome, variance explanation, reviewer decision, payment reference and GL readback together under the organization's retention rules.

Total-reward statements

Generate a statement for an approved employee and period, optionally selecting an approved or posted payroll run. If a run is not selected, the procedure resolves an eligible run for the employee/period. The generated record stores a source snapshot and hash, statement version, source payroll run, and any prior statement it supersedes.

The calculation uses payroll-run lines for pay, deductions, employer costs, employee benefit contributions, employer benefit contributions, and configured monetary rewards. The current source snapshot explicitly separates employee benefit deductions from the value counted as employer reward. Statements are generated as final versions; a regeneration creates a later version linked to the statement it supersedes rather than silently replacing that historical version.

A statement is a disclosure derived from payroll data. It is not a new payment, payroll run, provider invoice, or accounting journal. It will only include values represented by its selected payroll/source snapshot; confirm upstream payroll data and benefit inputs before sharing it with an employee.

When reviewing a statement, confirm employee and period first, then trace each monetary component to the selected payroll run and source lines. Distinguish employee gross/net pay and deductions from employer benefit contributions and other employer-paid rewards. Employer cost is not cash paid to the employee. Compare the statement version with any superseded version: regeneration makes a later version linked to the old one; it does not recall a previously downloaded or distributed copy. Share through the approved access-controlled channel only.

Suggested end-to-end operating sequence

1. Approve a plan with correct provider, currency, contribution values, and effective dates.
2. Add explicit base and/or life-event rules where default-open eligibility is not intended.
3. Record and review a qualifying employee life event and approved evidence when needed.
4. Run the eligibility check for the intended date; resolve a waiver or rule outcome before enrolment.
5. Create and approve the enrolment with dates/status that do not overlap another active enrolment.
6. Enable the Benefits source in the payroll input policy, calculate the period, and inspect consumed employee/employer inputs in the payroll run.
7. Record a provider invoice with line-level enrolments and exact coverage dates; reconcile to enrolment and optionally payroll.
8. Approve only a matched invoice, and manage its actual payment separately.
9. Generate and inspect the versioned total-reward statement from the approved/posted payroll run.

Troubleshooting and control checks

Symptom	Check
Plan not available	Service scope, approval, active state, effective dates, and capability/permission.
Eligibility result says pending life event	Approved event type/date, event window, rule effective dates, and required evidence.
Enrolment blocked	Employee/plan approval and service scope, active employment, plan dates, eligibility, approved waiver, and overlap.
Enrolment exists but payroll has no benefit line	Approval state, enrollment status/date, payroll policy source, period eligibility, and source-ledger consumption.
Invoice shows Exception	Compare coverage window and invoice lines with eligible enrolments, plan contribution amounts, billed totals, and linked run's consumed benefit sources.
Invoice is Approved but provider unpaid	Approval is not payment; locate the separate provider payment record and its settlement/GL proof.
Statement values look wrong	Check the source run, run approval/posting state, source snapshot/version, benefit input lines, and period dates.

Related guides

• HR Overview
• Capabilities and Access
• HR Setup
• Employees
• Payroll
• Travel and Expenses