Oracle Cloud Payroll: How to Pay a Retiree’s Beneficiary, Survivor, Charity, Guardian, or Estate/Trust

Introduction

Most Oracle Cloud Payroll implementations focus on standard employee and retiree payment scenarios. However, real-world payroll operations often involve less common, but critically important, special payment cases.

Examples include:

• Payments to a retiree’s beneficiary or surviving dependent
• Payments assigned to a charitable organization
• Payments made through a guardian or custodian
• Payments issued to an estate or trust

These scenarios typically arise in pension payroll, retiree benefit administration, deferred compensation processing, survivor benefits, legal settlements, or special retirement payment arrangements.

The common question becomes:

How do we correctly configure Oracle Cloud Payroll to pay someone other than the retiree while maintaining accurate tax reporting and payment handling?

This blog walks through practical configuration guidance for these special payroll payee scenarios.

---

Why This Matters

These are not just payment routing scenarios. They directly impact:

• Payroll check generation
• Payee naming
• Tax reporting, including Form 1099-R
• TIN / SSN handling
• Mailing address configuration
• Legal compliance
• Contact relationship setup for informational and audit purposes

Incorrect setup can result in:

• Checks issued to the wrong legal entity
• Incorrect tax reporting
• IRS reporting issues
• Payment delivery failures
• Compliance risks

---

Understanding Special Retiree Payment Scenarios

Oracle Cloud Payroll supports several special payee configurations where the payment recipient differs from the retiree.

The exact setup depends on the legal payment recipient and reporting requirements.

Note: All employee names, addresses, and screenshots used in this blog are sample/fake data for demonstration purposes only.

---

Scenario 1: Paying a Retiree’s Beneficiary or Survivor

Business Scenario

A retiree passes away, and pension or survivor payments must continue to the designated beneficiary.

Examples:

• Surviving spouse pension payments
• Beneficiary annuity continuation
• Survivor benefit plans

Recommended Setup

Field	Value
Payroll Payee	Beneficiary
Oracle Person Type	Retiree
SSN/TIN	Beneficiary SSN
Name	Beneficiary / Survivor Name
Address	Beneficiary mailing address
Contact Name	Actual retiree name
Contact Relationship	Contact

Payroll Behavior

When payroll is processed:

• Payment is issued to the beneficiary
• Tax reporting uses the beneficiary name, address, and SSN

This is especially important for Form 1099-R reporting.

[Screenshot: Beneficiary Payee Name, Address, SSN, and Date of Birth]

[Screenshot: Contact Setup]

[Screenshot: Check Payment Output]

---

Scenario 2: Paying a Charity

Business Scenario

A retiree elects to direct payment to a charitable organization.

Examples:

• Charitable assignment
• Pension donation instructions
• Structured contribution arrangements

Recommended Setup

Field	Value
Payroll Payee	Charity
Person Type	Retiree
SSN/TIN	Charity TIN
Name	Charity legal name
Address	Charity mailing address
Contact Name	Retiree name
Contact Relationship	Contact

Payroll Behavior

When payroll runs:

• Payment is issued to the charity
• Tax reporting uses the charity name, address, and TIN

[Screenshot: Charity Payee Name, Address, TIN, and Date of Birth]

[Screenshot: Contact Setup]

[Screenshot: Check Payment Output]

---

Scenario 3: Paying Through Guardian or Custodian

Business Scenario

A retiree may be legally unable to manage payments.

Examples:

• Incapacity
• Court-appointed guardian
• Conservatorship
• Custodian-managed payments

Recommended Setup

Field	Value
Payroll Payee	Guardian / Custodian
Person Type	Retiree
SSN/TIN	Retiree SSN
Name	Retiree legal name
Address Line 1	C/O Guardian Name
Address Line 2+	Retiree or guardian address
Contact Name	Retiree name

Address Example

Address Line 1: C/O John Doe
Remaining Address: 123 Main Street, Dallas, TX 75001

Payroll Behavior

Payroll processes the payment:

• Payment is payable to the retiree
• Payment is delivered using the guardian/custodian address routing

Tax reporting remains under:

• Retiree name
• Retiree SSN

This is because the payment is still legally attributable to the retiree.

[Screenshot: Guardian/Custodian Payee Name, Address, SSN, and Date of Birth]

[Insert Screenshot: Check Payment Output]

---

Scenario 4: Paying an Estate or Trust

Business Scenario

Payments must be made to a deceased retiree’s estate or trust.

Examples:

• Estate settlement
• Trust-administered benefits
• Executor-managed pension disbursement

Recommended Setup

Field	Value
Payroll Payee	Estate / Trust
Person Type	Retiree
SSN/TIN	Estate or Trust TIN
Name	Estate legal name
Address	Estate or trust mailing address
Contact Name	Retiree name
Contact Relationship	Contact

Executor Address Example

C/O Jane Smith, Executor
456 Estate Blvd
Chicago, IL 60601

Payroll Behavior

Payroll issues payment to:

• Estate
• Trust

Tax reporting uses:

• Estate/trust legal name
• Estate/trust TIN

[Screenshot: Estate/Trust Payee Name, Address, TIN, and Date of Birth]

[Screenshot: Contact Setup]

[Screenshot: Check Payment Output]

---

Contact Relationship

Maintain proper contact relationships to preserve auditability.

For Scenario 1, Scenario 2, and Scenario 4, create or select the actual retiree record as a contact. This is primarily for informational and audit purposes.

---

Common Mistakes

Incorrect Beneficiary SSN Usage

Using the retiree SSN instead of the beneficiary SSN can create reporting errors.

Estate Setup with Retiree SSN

Estate payments should generally use the estate or trust TIN.

Guardian Payments with Guardian SSN

Guardian scenarios typically still use the retiree SSN because the payment is legally attributable to the retiree.

Incorrect Mailing Address Design

Missing “Care Of” routing can result in failed payment delivery.

---

Final Thoughts

Oracle Cloud Payroll provides flexibility to support complex retiree payment scenarios beyond standard employee or retiree direct payments.

The key is understanding:

• Who is the legal payee?
• Who owns the tax reporting obligation?
• Where should the payment be delivered?

Getting those three questions right makes implementation straightforward.

For pension and retiree payroll teams, these scenarios may be uncommon, but when they occur, correct configuration is essential.

Oracle HCM Extract Best Practice: Draft vs Final Vendor Delivery Using Report Category

Introduction

One of the most common operational requirements in Oracle Cloud HCM and Payroll integrations is not just generating outbound vendor files—but controlling when those files are transmitted.

Typical outbound integrations include files sent to:

• Benefits providers
• Retirement vendors
• Garnishment agencies
• Payroll banking partners
• Insurance carriers
• Tax agencies
• External payroll processors

A very common business requirement looks like this:

Run the HCM Extract → Validate the output → If the results look correct, send the file to the vendor via SFTP

At first glance, teams often assume this requires:

• Custom orchestration
• Middleware intervention
• Manual file download/upload
• Duplicate extract definitions
• Custom ESS job chains

However, Oracle HCM Extract provides a standard capability that is often underutilized:

Report Category

This standard parameter allows implementation teams to control extract delivery behavior by associating different delivery configurations with different report categories.

With the right design, this provides a clean way to separate file generation from vendor transmission, without unnecessary customization.

---

The Common Business Problem

In many payroll and HCM outbound integrations, sending the file immediately after extract generation is not always desirable.

Examples include:

Payroll Vendor Files

A payroll deduction remittance file may require payroll or finance validation before transmission.

Benefits Enrollment Files

Benefit carrier enrollment files may need operational verification before delivery.

Garnishment Files

Incorrect transmission may create compliance or payment issues.

Tax Reporting Files

Organizations may require internal review before sending statutory reporting files externally.

In all these scenarios, the desired operational process becomes:

1. Generate file
2. Review output
3. Approve for release
4. Deliver to vendor

The challenge is enabling this process without introducing unnecessary architectural complexity.

---

Common, But Often Overengineered, Approaches

To solve this requirement, teams often consider:

• Creating separate draft and production extracts
• Middleware orchestration logic
• Manual download and upload processes
• Custom ESS scheduling chains
• External SFTP automation scripts

While these approaches can work, they often add complexity that may not be necessary.

---

The Standard Oracle Solution: Report Category

Oracle HCM Extract includes a standard parameter called:

Report Category

This parameter can be used to group and control extract delivery behavior.

Instead of treating delivery as a fixed part of extract execution, you can design multiple operational modes using report categories.

This becomes especially useful when outbound vendor files require business validation before release.

---

Practical Design Pattern: Draft vs Final

In this implementation approach, the same HCM Extract is configured with two report categories:

• Draft
• Final

Each category supports a different operational outcome. You can create any number of report categories and name them as per your needs.

---

Option 1: Draft

The Draft report category generates the file but keeps it internally accessible within Oracle/UCM without transmitting it externally.

Flow:

Run Extract (Draft)
→ File Generated
→ Payroll / HR Reviews Output
→ Business Approval

In this example, the Draft report category has one delivery option configured under it.

---

Option 2: Final

Once the draft output is validated, the same extract is rerun using the Final report category.

In this mode, the configured delivery options, such as SFTP, are executed.

Flow:

Run Extract (Final)
→ File Generated
→ Automatically Delivered via SFTP

This provides a clean operational promotion model from review to release.

---

Important Design Consideration

Since the extract is rerun in Final mode, organizations should ensure the underlying source data remains unchanged between Draft validation and Final transmission.

For payroll integrations, this typically means ensuring:

• Payroll results are finalized
• No retro changes occur between validation and transmission
• No operational changes impact extract data between runs

This avoids validating one dataset and transmitting another.

---

Real-World Payroll Example

Consider a 401(k)-deduction remittance file.

Business requirement:

• Generate deduction file after payroll
• Payroll team validates totals
• Confirm deduction balances match payroll register
• Only then transmit to Fidelity (vendor)

Without delivery control:

• File may be transmitted immediately
• Errors become vendor-facing operational incidents
• Corrections require rework and vendor coordination

With the Draft/Final report category approach:

Draft

• File generated
• Payroll validates totals
• Internal signoff obtained

Final

• Same extract reruns
• Approved file transmitted via SFTP

This creates a much cleaner operational model.

---

Why This Matters

This is not just a technical extract parameter.

This approach improves:

Operational Control

Prevents premature vendor transmission.

Error Prevention

Catches extract issues before they become external incidents.

Compliance Support

Useful for regulated outbound integrations.

Simplified Design

Avoids unnecessary middleware or duplicate solutions.

Supportability

Gives operations teams a predictable and manageable process.

---

Where This Pattern Works Well

This approach works especially well for:

• Payroll deduction remittance files
• Retirement contribution vendor files
• Benefit carrier interfaces
• Garnishment remittance files
• Tax reporting interfaces
• Banking/payment outbound files
• Third-party payroll vendor integrations

---

Practical Recommendation

For outbound vendor integrations, ask a simple question:

Should this file be transmitted immediately, or should the business validate first?

If validation is required, consider using Report Category strategically before introducing custom orchestration.

---

When This May Not Be Enough

While this pattern works well for many use cases, more complex scenarios may still require additional design considerations.

Examples include:

• Conditional routing to different vendors
• Multiple simultaneous delivery destinations
• Dynamic file naming rules
• Complex orchestration dependencies
• Approval workflows requiring system-enforced gating

In these cases, middleware or additional automation may still be appropriate.

---

Final Thoughts

Oracle often provides standard capabilities that solve practical implementation problems without customization.

Report Category in HCM Extract is one of those underused features.

If your operational requirement is:

Generate → Validate → Then Send

Do not immediately assume middleware or custom orchestration is required.

A simple Draft vs Final Report Category design may provide exactly the operational control your business needs—with far less complexity.

Oracle Payroll Integration with UKG: Calculation Card vs Element Entry — Understanding the Correct HDL Object

Introduction

When integrating UKG, or any external time system, with Oracle Cloud HCM Payroll, a common design question is:

Should time be loaded as Element Entries, or should we use PayrollTimeCard / PayrollAbsenceRecord HDL objects?

This blog clarifies the relationship between PayrollTimeCard.dat, PayrollAbsenceRecord.dat, ElementEntry.dat, and Calculation Cards, and explains the recommended design approach for Oracle Payroll integrations.

---

The Core Design Decision

There are two primary integration patterns for third-party time and absence data:

1. PayrollTimeCard.dat / PayrollAbsenceRecord.dat — time/absence-driven model
2. ElementEntry.dat — payroll-result-driven model

Calculation Cards should not be treated as a separate third option. They are the payroll representation layer where time and absence data may appear after being loaded through the correct business objects.

---

Key Clarification: Calculation Cards Are the Target Representation

The most important clarification is:

PayrollTimeCard.dat and PayrollAbsenceRecord.dat both populate Calculation Cards, but you should not use CalculationCard.dat directly to load time or absence data.

In other words, Oracle may create or update Calculation Cards as part of the payroll time or absence load process, but the integration should use the purpose-built HDL objects.

What This Means in Practice

• PayrollTimeCard.dat creates or updates Calculation Cards with time entries.
• PayrollAbsenceRecord.dat creates or updates Calculation Entries for absences.
• CalculationCard.dat should not be used for time or absence integration.

---

How Oracle Designed This

Oracle separates the object you load from where the data appears in payroll.

HDL Object	Purpose	Where Data Appears
PayrollTimeCard.dat	Time-card data	Calculation Cards / Calculation Entries
PayrollAbsenceRecord.dat	Absence data	Calculation Entries
ElementEntry.dat	Payroll-ready inputs	Element Entries
CalculationCard.dat	Generic calculation card object	Not recommended for time/absence loading

---

Pattern 1: PayrollTimeCard.dat — Recommended for Time

When to Use

Use PayrollTimeCard.dat when UKG is the system of record for approved time, but Oracle Payroll still needs to process the time data.

This approach is useful when Oracle Payroll needs to:

• Calculate overtime
• Apply premiums
• Handle costing
• Apply jurisdiction-specific payroll logic
• Preserve work-date level detail

What Happens

1. UKG sends approved time-card data.
2. PayrollTimeCard.dat is loaded.
3. Oracle validates the time-card elements.
4. Oracle creates or updates Calculation Cards.
5. Payroll processes the time entries.

---

Pattern 2: PayrollAbsenceRecord.dat — Recommended for Absences

When to Use

Use AbsenceEntry.dat when UKG or another external system sends approved absence data and you want Oracle Payroll to process absence-related payroll logic.

What Happens

• Absence records are loaded using PayrollAbsenceRecord.dat.
• Oracle creates the related calculation entries.
• Payroll processes the absence-related elements.

---

Pattern 3: ElementEntry.dat — Payroll-Ready Inputs

When to Use

Use ElementEntry.dat when UKG has already calculated the payroll values and Oracle Payroll only needs to consume the final results.

This may include:

• Regular pay
• Overtime
• Premiums
• Adjustments
• Payroll-ready hours or amounts

This pattern can be simpler, but it places more responsibility on the integration for validation, correction handling, duplicate prevention, and reconciliation.

---

Why Not Use CalculationCard.dat?

Although PayrollTimeCard.dat and PayrollAbsenceRecord.dat populate Calculation Cards, you should not use CalculationCard.dat directly for time or absence loads.

Using CalculationCard.dat for time or absence can create issues because:

• It bypasses purpose-built validation logic.
• It does not align with Oracle’s recommended payroll data model.
• It can make reconciliation and maintenance more difficult.

---

The Real Relationship

The correct way to think about this is:

PayrollTimeCard.dat and PayrollAbsenceRecord.dat are calculation-card-based integrations, but they are implemented through specialized business objects, not through CalculationCard.dat.

---

Benefits of PayrollTimeCard.dat and PayrollAbsenceRecord.dat

1. Data Model Alignment

• Matches Oracle Payroll architecture
• Preserves time and absence granularity

2. Built-In Validation

• Supports element eligibility validation
• Provides structured error handling

3. Better Reconciliation

• Aligns source system data with payroll processing
• Supports audit at a detailed level

---

Challenges to Plan For

1. Source Key Strategy

A strong source key strategy is required for updates, corrections, and reconciliation.

2. Correction Model

Corrections should generally be made in the source system and re-imported, rather than manually adjusted in payroll.

3. Visibility

• Data appears in Calculation Cards.
• It does not appear in Oracle Time and Labor time cards.

4. Setup Requirements

The design requires proper configuration of:

• Payroll elements
• Element eligibility
• Related generated elements where applicable

---

Practical Recommendation

Use PayrollTimeCard.dat when:

• You want time-driven payroll processing.
• You need detailed audit and reconciliation.
• You want Oracle Payroll to process time-card-style data.

Use PayrollAbsenceRecord.dat when:

• You are integrating approved absence data.
• You want Oracle Payroll to process absence-related payroll logic.

Use ElementEntry.dat when:

• You receive payroll-ready values from UKG.
• UKG has already calculated the final payable hours or amounts.

Avoid:

• Using CalculationCard.dat directly for time or absence data.

---

Conclusion

The confusion around Calculation Cards usually comes from treating them as an integration option rather than understanding what they represent.

Calculation Cards are the internal payroll representation of time and absence data, but the correct load mechanism is through the appropriate HDL business object.

Final Takeaway

• PayrollTimeCard.dat and PayrollAbsenceRecord.dat do populate Calculation Cards.
• You should not use CalculationCard.dat directly for time or absence loads.
• ElementEntry.dat remains valid for payroll-ready inputs.

Using the correct HDL object ensures that the integration is aligned with Oracle’s payroll architecture, easier to reconcile, and more scalable for long-term maintenance.

Oracle Cloud 25B: Enabling Approvals for Employee External Bank Account Creation and Modification

Introduction

A long-standing control gap in Oracle HCM and Payroll has been the lack of approval workflows for employee bank account changes. Organizations have consistently raised concerns about allowing employees to create or modify external bank accounts without validation or oversight.

With Oracle Cloud 25B, Oracle has introduced the ability to enforce approvals specifically for Employee External Bank Account creation and modification, adding a critical governance layer to payroll processing.

Business Context

Employee external bank accounts directly impact salary disbursement. Any incorrect or unauthorized change can lead to:

• Payments being routed to incorrect accounts
• Payroll failures and rework
• Increased risk of fraud
• Compliance and audit challenges

This enhancement introduces a structured approval mechanism to mitigate these risks within the application itself.

What’s Delivered in 25B

The solution is built using three core components:

1. Feature Opt-In for Payments
2. Controlled Lookup Enablement
3. Spreadsheet-Based Approval Rules

This functionality applies specifically to:

• Creation of external bank accounts
• Modification of external bank accounts

Step 1: Enable Feature Opt-In

Navigate to:

Setup and Maintenance > Financials > Payments > Edit Features

Enable:

Employee Bank Account Ownership Verification Workflow

This step activates the underlying approval framework.

Step 2: Enable Controlled Lookup

Navigate to:

Setup and Maintenance > Manage Standard Lookups

Search for:

ORA_ERP_CONTROLLED_CONFIG

Enable the following lookup:

• Lookup Code: IBY_37070344
• Meaning: Enable Bank Account Approval
• Status: Enabled

This lookup acts as the trigger for approval processing.

Step 3: Configure Approval Rules

Navigate to:

Manage User-Defined Rules for Employee Bank Account Approvals

Download:

ExternalBankAccountApprovalRulesTemplate.xlsm

Important

Ensure the following privilege is assigned:

IBY_MANAGE_BANK_ACCOUNT_APPROVALS_PRIV

Without this privilege, users will not be able to configure approval rules using the task Manage User-Defined Rules for Employee Bank Account Approvals.

Step 4: Define Approval Logic

Approval rules are defined using the Excel template.

In this implementation example, a two-level approval was configured:

1. Account Owner approval using username
2. Approval by users with the role KP_PAYROLL_ADMIN_VIEW_ALL_DATA

If multiple users have this role, any one of them can approve the notification.

After defining the rules in Excel:

1. Click Generate Rule File
2. A ZIP file will be generated
3. Upload the ZIP file back into Manage User-Defined Rules for Employee Bank Account Approvals

End-to-End Flow

1. Employee creates or updates an external bank account
2. System evaluates feature opt-in and lookup configuration
3. Approval rules are applied
4. Request is routed to approver or approvers
5. Upon approval, the bank account is created or updated

Basic Testing of Configuration

After completing the setup, perform a simple validation to confirm the configuration is working.

Test Steps

1. Login as an employee
2. Navigate to Me > Pay > Payment Methods
3. Add a new external bank account or update an existing one
4. Submit the transaction

Expected Result

• The change should not be applied immediately
• An approval request should be triggered
• The request should appear in the approver’s worklist or notifications

Approval Validation

1. Login as the approver
2. Open the approval notification
3. Approve the request

Result: The bank account should be successfully created or updated.

What This Confirms

• Feature opt-in is enabled correctly
• Lookup configuration is active
• Approval rules are functioning
• Workflow routing is working as expected

Key Observations

Scope of Approval

This feature applies only to:

• External bank account creation
• External bank account modification

It does not apply to other payment method configurations such as allocation or percentage splits.

Configuration Model

This feature is not configured like standard HCM approval transactions.

It does not use:

• Transaction Design Studio
• Standard BPM rule configuration

Instead, it relies on:

• Feature opt-in
• Controlled lookup
• Spreadsheet-based rule definition

Implementation Considerations

Payroll Timing

Bank account changes are applied only after approval. Approval timelines must align with payroll processing cutoffs to avoid delays.

Limitations and Considerations

While this feature addresses a critical control gap, there are important limitations to consider.

Limited Rule Authoring Model

Approval rules are defined using a spreadsheet template rather than the standard BPM rule UI.

This results in:

• Static, template-driven rules
• Limited flexibility compared to dynamic BPM configurations
• No support for advanced conditional expressions

No Support for AOR-Based Routing

Unlike other HCM approvals, this feature does not support routing based on Areas of Responsibility (AOR).

This means:

• Approval cannot dynamically route based on HR or payroll responsibility
• Routing must be predefined in the template

Limited Support for Complex Approval Scenarios

Compared to other HCM transactions, the following are not supported:

• Dynamic multi-stage approvals
• Parallel approval flows
• Rule chaining or advanced escalation logic

Approval flows are generally linear.

Dependency on Template Maintenance

Since rules are managed through a spreadsheet:

• Any change requires re-download and re-upload
• Version control must be managed externally
• There is a higher risk of manual errors

Limited Debugging Capability

Troubleshooting approval issues is less intuitive due to:

• Lack of visual rule builder
• Limited runtime diagnostics
• Errors often identified only during upload or execution

Practical Recommendations

• Start with simple approval rules, such as manager-based or payroll-admin-based routing
• Avoid overly complex logic
• Maintain proper documentation of rule logic
• Establish governance for template updates
• Validate the approval flow before enabling in production

Compliance and Audit

This feature strengthens:

• Audit traceability
• Internal controls
• Fraud prevention

User Communication

Employees should be informed that:

• Bank account changes require approval
• Changes are not immediate
• Approval must be completed before the change becomes effective

Conclusion

Oracle Cloud 25B introduces an essential control for managing employee external bank account changes.

By combining feature enablement, controlled configuration, and approval rules, organizations can significantly improve governance over payroll-critical data.

This is a practical enhancement that should be enabled and validated as part of any payroll implementation.

Oracle Cloud Payroll - US Retiree Payroll Configuration

US RETIREE PAYROLL IN ORACLE CLOUD HCM — MUST-DO CONFIGURATION

This article is designed to help Oracle Cloud HCM practitioners implement US retiree payroll in a clean, auditable way. It focuses on practical configuration choices, common setup gaps, and testable outcomes—so teams can enable learning, reduce rework, and deliver reliable payroll operations.

This checklist is based on hands-on implementation patterns and guidance from Oracle documentation/support material, including:

• Oracle Support Document ID 2461709.1 — “Oracle Fusion Human Capital Management for RETIREES US: Implementation and Use (v1.9)”

• Oracle Cloud Human Capital Management for the United States: How do I perform tax filing through a third-party? KB160976

• Audience: Payroll implementers, HCM functional consultants, payroll admins supporting US retiree pay

• Scope: US retirees paid via Oracle Cloud Payroll (commonly pension/annuity payments; often reported via 1099-R depending on your program design)

————————————————————————————————————

Retiree payroll has a few “small” setup decisions that create big downstream impact: tax card creation, TRU/PSU structure, registrations, reporting card associations, and address quality. If you get right early, year-end, reconciliation, and ongoing maintenance become predictable.

————————————————————————————————————

SECTION A — FOUNDATION (NON-NEGOTIABLE)

If you are already payroll customer running employee's payroll then this would be already configured.

A1) Set the United States Selected Extension correctly

• Confirm your US “Selected Extension” setting aligns with how you plan to process retirees (HR-only vs payroll-enabled configuration).

A2) Address Validation + geographies maintenance (strongly recommended)

• Enable Address Validation (if your governance permits).
• Establish an operational cadence to refresh geographies (as applicable).

————————————————————————————————————

SECTION B — ORG STRUCTURE (BUILD RETIREE BOUNDARIES EARLY)

B1) Separate retiree PSUs from employee PSUs (recommended baseline)

• Create retiree Payroll Statutory Units (PSUs) separately from employee PSUs where your business/legal reporting model supports it.

B2) Create retiree TRUs separately; lock down distribution code governance

• Create retiree TRUs separately from employee TRUs.

• If your program requires different 1099-R distribution codes, segment TRUs accordingly.

• Governance rule: do not change TRU’s 1099-R distribution code after creation—create a new TRU if the code changes.

        Manage LRU HCM Information => Enter the distribution code

————————————————————————————————————

SECTION C — TAX REGISTRATIONS (REQUIRED FOR STABLE PAYROLL PROCESSES)

This configuration is same as your regular employee(Non-Retiree) payroll configuration.

C1) US Federal registration at LRU level (FEIN)

• Create the US Federal Tax registration at the LRU level.
• Enter the Employer FEIN.

C2) State registrations (as applicable)

• Populate state registrations for jurisdictions where you withhold/report, based on your compliance model and filing responsibilities.

————————————————————————————————————

SECTION D — TRU CALCULATION RULES (PUT WITHHOLDING LOGIC IN THE RIGHT PLACE)

This configuration is same as your regular employee(Non-Retiree) payroll configuration.

D1) Create TRU calculation rules card

Create “Calculation Rules for Tax Reporting and Payroll Statutory Unit” at the TRU level.

D2) Flat-rate override governance (if your retiree program uses it)

Recommended override priority (high → low)
1. Retiree person tax card overrides
2. TRU-level overrides
3. Tax engine defaults

Note –

Retiree payments that are subject to 1099-R rules are not subject to SUI, SDI, FLI, Social Security, or Medicare taxes. Therefore, the payroll process does not calculate them.

————————————————————————————————————

SECTION E — CONSOLIDATION GROUP AND PAYROLL GROUP

E1) It would be better to create separate consolidation group and payroll definition for retiree payroll processing

————————————————————————————————————

SECTION F — RETIREE TAX CARDS (ENSURE THEY AUTO-CREATE AND STAY CORRECT)

F1) Confirm the retiree tax card model

• Validate the retiree tax card behavior for your program (commonly “Tax Withholding for Pensions and Annuities”).

F2) Validate auto-creation is working (don’t assume)

F3) State-tax edge case validation

When you onboard or convert employee to retiree; you will see below calculation created and TRU association created auto

————————————————————————————————————

SECTION G — REPORTING INFORMATION CARD (OFTEN MISSED, HIGH IMPACT)

G1) Confirm TRU components are associated to the correct assignment

• Validate that Reporting Information Card components created per TRU are correctly associated to the retiree assignment number—especially when multiple TRUs exist.

————————————————————————————————————

SECTION H — RETIREE ASSIGNMENT (MINIMUM REQUIRED FIELDS)

This data point is same as your regular employee(non-retiree) payroll data point.

H1) Retiree must have a payroll-eligible assignment

• Payroll relationships are assigned
• Ensure retiree assignment is Active and Payroll Eligible

————————————————————————————————————

SECTION I — HOME ADDRESS, LOCATION AND WFH FLAG FOR RETIREES (WHAT IT MEANS IN ORACLE)

Key point (clear definition)

Retirees aren’t “working,” but Oracle still requires a Work Location on the retiree assignment. For WFH/Remote retirees, treat Work Location as a required data field for consistency and reporting—not as a local tax driver.

I1) All Retirees must have valid US Home Address for payroll processing. Retirees can have overseas mailing address for communication.

I2) Create a dedicated retiree remote location and assign it to all retirees and check 'Work From Home' flag for them.

————————————————————————————————————

SECTION J — PAYMENTS (DIRECT DEPOSIT MUST BE OPERATIONALLY SUPPORTED)

This data point is same as your regular employee(Non-Retiree) payroll data point.

J1) Run prerequisite process for new retirees

• Run “Maintain Party and Location Current Record” before entering personal payment methods (for newly onboarded retirees).

J2) Enter payment methods

• Use “Manage Personal Payment Methods” to add direct deposit details.

————————————————————————————————————

SECTION K — KNOWN CONSTRAINTS (DESIGN AROUND THEM EARLY)

• Local taxes for retirees may not be supported in retiree processing models; plan your retiree withholding accordingly.
• Involuntary deductions may not be supported for retiree processing; define an alternative approach if required.
• Confirm territory/jurisdiction scope early if you have retirees outside standard US states.

————————————————————————————————————

Finally Let's add earning elements and run QuickPay to see the results

————————————————————————————————————

Disclaimer: 

The checklist provided here focuses on foundational setup patterns and common “must-do” configurations for US retiree processing in Oracle Cloud HCM. Actual implementations can vary by retiree plan design, bargaining agreements, legal/tax requirements, and reporting needs. Most projects also require additional configuration, including elements and balance definitions, fast formulas, eligibility, costing rules, payroll calendars, retro and correction processes, and integrations with third-party or downstream systems (e.g., tax services, payment files, benefits providers, and financial/GL systems) to deliver end-to-end processing and statutory reporting.

Payroll Batch Loader Error Query

select ml.*
from pay_bl_message_lines_vl ml
,    pay_batch_lines bl
,    pay_batch_headers bh
where bh.batch_id = bl.batch_id
and   bl.batch_line_id = ml.source_id
and   bh.batch_name = 'BATCH NAME'
and   bl.batch_line_status = 'E';


Full Query for all PBL errors with batch name, task name, task action name, assignment number and error message


SELECT pbh.batch_name,
       pbh.legislative_data_group_id,pbt.display_task_name,pbta.display_task_action_name,
pivot_line_value_data.action_parameter_name1,pivot_line_value_data.action_parameter_value1,pivot_line_value_data.action_parameter_name2,pivot_line_value_data.action_parameter_value2,
       pbmlv.message_text
FROM
(SELECT batch_line_id,
     MAX(decode(rn,1,display_action_parameter_name))
action_parameter_name1,MAX(decode(rn,1,action_parameter_value))
action_parameter_value1,
     MAX(decode(rn,2,display_action_parameter_name))
action_parameter_name2,MAX(decode(rn,2,action_parameter_value))
action_parameter_value2,
     MAX(decode(rn,3,display_action_parameter_name))
action_parameter_name3,MAX(decode(rn,3,action_parameter_value))
action_parameter_value3,
    MAX(decode(rn,4,display_action_parameter_name))
action_parameter_name4,MAX(decode(rn,4,action_parameter_value))
action_parameter_value4
 FROM ( SELECT batch_line_id,
               action_parameter_name,
       action_parameter_value,
       display_action_parameter_name,
               row_number() over (partition by batch_line_id
                          order by batch_line_id,
  action_parameter_name ) rn
          FROM (SELECT pbavl.element_name action_parameter_name,
               pbavl.parameter_name display_action_parameter_name,
       pblv.action_parameter_value,
       pblv.batch_line_id
FROM pay_task_parameters_vl pbavl,  pay_batch_line_values pblv
WHERE pbavl.base_task_parameter_id = pblv.action_parameter_id
AND pbavl.display_flag <> 'N' ) 
          )
GROUP BY batch_line_id) pivot_line_value_data,
                        pay_batch_lines pbl ,
                  pay_batch_headers pbh,
                        pay_bl_message_lines_vl pbmlv,
PAY_BL_TASK_ACTIONS_VL pbta,PAY_BL_TASKS_VL pbt
WHERE pivot_line_value_data.batch_line_id = pbl.batch_line_id
AND pbl.batch_id = pbh.batch_id
AND pbl.batch_line_id = pbmlv.source_id
AND pbl.batch_line_status = 'E'
AND pbh.batch_name like '%Pay%%%'
AND pbt.task_id=pbta.task_id
and pbl.task_action_id=pbta.task_action_id

Fusion HCM New Hire Process - USA

Important Points -

(1) Address

All employees attached to a payroll must have a home address throughout their period of employment.Also, if you enter the ZIP Code first, the city, state, and county fields are automatically populated.

(2) Marital Status, Ethnicity, and Veteran fields in the Legislative Information section

Note: The Ethnicity and Veteran fields are required for EEO and VETS reporting.

(3)  On the Employment Information page, provide the necessary work relationship, payroll relationship, assignment, job, manager, payroll, and salary details.

Note: Use the Payroll Details section to associate a TRU and payroll with the employee. If you opt not to, this employee would not automatically receive an Employee Withholding Certificate, and you would have to create it manually. See Manual Tax Card Creation for more instructions.
.
Once a TRU is attached to an employee, the W-4 Federal Tax Card is generated. The association to the TRU is also generated. Additionally, the US taxation element is automatically added to the employee’s element entry once the association to the TRU is done. This tax card is not created for HR-only customers.

= = = = = =

Verifying Employee New Hire Status in Work Relationship Details

When hiring or rehiring employees, the New Hire Status field indicates whether they are to be included or excluded from new hire reporting. Find this field in the Work Relationship Details of the Employment Information page.

Field Name Description :
New Hire Status

- Identifies the employee’s employment status as pertains to the New Hire report:

Different Values

(1) Include in the New Hire report :Employee is to be included in the next run of the New Hire Report.
(2) Already reported: Employee has already been included in a previous run of the New Hire Report.
      The New Hire Report process automatically sets all included employees to this status upon                 completion in final mode.
(3) Excluded from the New Hire report : Employee is not included in the report.


= = = =

Adding a Second Assignment

To add an additional assignment to an employee’s employment information: 1. Follow steps 1 through 3 under Maintaining Employment Information above.

2. Select Edit > Update.

3. Enter an Effective Start Date (or accept the default).

4. Select Add Assignment.

5. Click OK.

6. Enter employment information.

7. Click Next.

8. Enter compensation details.

9. Click Next.

10. Add or delete roles as needed.

11. Click Next.

12. Review the information and click Submit.

13. Click Yes.

You can view and access the new assignment from the Employment Tree. The last assignment added is the one first displayed in the Manage Employment UI when it is initially accessed. The other assignments may be accessed using this tree hierarchy.

====

There are several factors that make up the payroll processing.

Taxation Within Fusion Payroll

Vertex provides all the statutory compliance for the Oracle Fusion Global Payroll engine, but it is important for you to understand how the payroll process handles US taxation.

Managing the Employee Withholding Certificate

The Employee Withholding Certificate is the default tax card. For most employees, it is created automatically during the New Hire process. The Employee Withholding Certificate provides information used in taxation. Items such as filing status, number of allowances, and exemptions from taxes are specified on the card. If no values are entered, during tax calculations, a default value of Single for filing status and zero allowances will be used.

Setting Up Automatic Tax Card Creation

To ensure that new workers get an Employee Withholding Certificate:

1. Set the PAYROLL_LICENSE process configuration parameter to either PAYROLL or PAYROLL_INTERFACE, as appropriate to your implementation.

2. Confirm that element eligibility has been created for the US Taxation element. This element is automatically added to employee’s element entry when the association to the Tax Reporting Unit is completed.

Manual Tax Card Creation

There are cases where an employee would not have their tax card automatically created, such as if they were loaded through the File Based Loader utility.

For these employees, to create an Employee Withholding Certificate:

1. Navigate to the Payroll Calculations work area.

2. Start the Manage Calculation Cards task.

3. Search for and select the person record.

4. Click Create.

5. Enter an appropriate Effective-As-of-Date, and select Employee Withholding Certificate for Name.

6. Enter employee information as appropriate at the Federal level.

7. Click Save.

8. Select the Regional link under the Component Groups tree.

9. Enter employee information as appropriate for the Regional level.

10. Click Save.

11. Select the Associations link under the Component Groups tree.

12. Under Associations, click Create.

13. Select the Tax Reporting Unit, and click OK.

14. Click Save. This creates the US Taxation Component and is displayed in the Calculation Component column after saving.

15. Under Association Details, click Create.

16. Select the Employment Terms or Assignment Number and the Calculation Component created in prior steps, and click OK.

17. Click Save. 

18. Upon tax card association creation, the following fields are autopopulated with default values on the federal-level employee withholding certificate and should be verified:

 State for Unemployment Calculation

 State for Disability Calculation

 Primary Work Address

Changing the TRU for an Assignment:

To change the TRU for a preexisting assignment on the Employee Withholding Certificate:

1. Navigate to the Payroll Calculations work area.
2. Select Manage Calculation Cards.
3. Search for and select the person record.
4. Click Employee Withholding Certificate.
5. Click Associations under the Component Groups tree.
6. Select the Tax Reporting Unit under Associations for which the assignment currently exists.
If the association for the TRU for the new assignment does not already exist, create it now.
7. Select the assignment number to change under Association Details.
8. Click Edit>Update.
9. Select the Calculation Component for the new TRU.
10. Click Save and Close.
This end dates the record for the assignment associated with the previous TRU and creates a new record for the new TRU.

Manage Tax Withholding in My Portrait

Employees can update their own withholding information in Portrait using the Manage Tax Withholding action: 

1. Select Manage Tax Withholding action in the left panel under Actions.

    This displays the Employee Withholding Certificate page.

2. Click Edit. This is available for both the federal and state level.

When the federal employee withholding certificate is accessed, the system displays the federal W-4 editable PDF form. For those states that do follow federal, the state name is stamped on the editable federal PDF form. For those states that do not follow federal, the specific state’s editable PDF form will be displayed. The employee can perform their updates on these forms for both federal and state withholding. When the form is submitted, the data is saved to the system. See Appendix C for information on accessing the PA Residency Certificate in My Portrait.

Tax Calculation:

Oracle Fusion Global Payroll automatically calculates your taxes when you perform a payroll run. The following describes the rules it uses when doing so.

Payroll Processing

When you perform a payroll run, the payroll process:

1. Determines the resident and work tax addresses based on the following hierarchy:

Address Type                                                 ---- Priority

Location address                                            ----   4
Location override address                              ----   3
Assignment-level location override               ----   3
Work at home flag = Yes                               ----   1 (overrides assignment, location override, and                                                                                           location)

Higher priorities override the lower ones.
The process derives the resident tax address from the home address, and the work tax address is derived from the work location or, if the work-at-home flag is enabled, it uses the home address.
2. Determines the related withholding status and any additional information from the tax calculation card.
3. Passes this information to Vertex for calculation.