Overview of US Tax Withholding Information in Oracle Fusion HCM
In Oracle Fusion HCM, Tax Withholding calculation cards store information used for employee federal, state, and local tax calculations in the United States.
These calculation cards can contain tax-related component information as well as calculation overrides.
The Oracle HCM Data Loader (HDL) Tax Withholding business object simplifies the underlying calculation-card structure. Instead of directly managing the complete calculation-card hierarchy, you can use the Tax Withholding business object and its related components for Federal, State, County, City, Pennsylvania PSD, and US Taxation information.
This article explains the US Tax Withholding hierarchy, major components, prerequisites, and important considerations when maintaining Tax Withholding information using HDL.
1. What is a Tax Withholding Calculation Card?
Tax Withholding calculation cards store component information used for employee:
- Federal tax calculations
- State tax calculations
- Local tax calculations
- County tax calculations
- City tax calculations
- Pennsylvania PSD information
- Tax calculation overrides
An important point is that calculation card components aren't required in every case to calculate taxes.
If a card component hasn't been created, or the component has been created without values or with missing values, Oracle can use the applicable default values for tax calculation.
This means that the presence or absence of a component can affect how employee tax information is maintained.
2. Tax Withholding HDL Hierarchy
The Tax Withholding business object hides much of the complexity of the underlying calculation-card structure.
The hierarchy can be viewed conceptually as:
Tax Withholding │ ├── Federal Taxes │ ├── State Taxes │ ├── Pennsylvania PSD │ ├── County Taxes │ ├── City Taxes │ └── US Taxation
Oracle provides separate components for different tax levels so that each component contains attributes relevant to that particular tax type.
For the official Oracle hierarchy image, refer to the Oracle documentation:
Oracle Tax Withholding Hierarchy
3. Tax Withholding Component
The Tax Withholding component identifies the person for whom the tax withholding calculation card is being maintained.
When creating or maintaining an existing Tax Withholding card, this component should be supplied.
Think of this as the top-level component that identifies the employee's Tax Withholding card.
Tax Withholding │ └── Employee / Person
The remaining components are associated with this Tax Withholding structure.
4. Federal Taxes Component
The Federal Taxes component captures information that can affect the employee's federal tax calculations.
Each Tax Withholding calculation card should have one Federal Taxes component.
Conceptually:
Employee │ └── Tax Withholding │ └── Federal Taxes
Federal tax information can therefore be maintained separately from state and local tax information.
5. State Taxes Component
The State Taxes components contain information that can affect state tax calculations.
A State Tax component may be used for each US state where the employee has applicable:
- Resident tax
- Work tax
For example, an employee may have state tax information associated with a resident state and/or work state.
Conceptually:
Tax Withholding │ ├── Federal Taxes │ ├── State Tax - State A │ └── State Tax - State B
The exact state-specific information depends on the employee's circumstances and the tax setup.
6. Pennsylvania PSD Component
The Pennsylvania PSD component is used for information specific to Pennsylvania Political Subdivision (PSD) requirements.
When an employee provides a Pennsylvania residency certificate, a Pennsylvania PSD component can be created for the employee.
Conceptually:
Tax Withholding │ └── Pennsylvania PSD
This component is specifically associated with Pennsylvania PSD information rather than general state tax information.
7. County Taxes Component
The County Taxes component is used to capture information related to resident or work County Tax calculations.
A County Tax component may be used for each US county that has a resident tax or work tax and requires an override.
One important point is that there is only one County Taxes component in the Tax Withholding object hierarchy.
The state and county for the information being updated are specified through the appropriate attributes on that component.
Conceptually:
Tax Withholding │ └── County Taxes │ ├── State └── County
8. City Taxes Component
The City Taxes component captures information that affects city tax calculations.
A City Tax component may be used for each US city that has a resident or work tax and requires an override.
The Tax Withholding hierarchy contains one City Taxes component, and the relevant:
- State
- County
- City
are specified through the component's attributes.
Conceptually:
Tax Withholding │ └── City Taxes │ ├── State ├── County └── City
9. US Taxation Component
The US Taxation component is associated with the employee's tax reporting unit.
You should create a US Taxation card component for each Tax Reporting Unit (TRU) associated with the employee.
Conceptually:
Tax Withholding │ └── US Taxation │ └── Tax Reporting Unit
This is particularly important when employees have circumstances involving more than one Tax Reporting Unit.
10. How Tax Withholding Cards Are Generated
The way the Tax Withholding card is created can depend on the product licensing and how the employee was created.
When employees are created with the product license set to:
- Payroll
- Payroll Interface
Tax Withholding calculation cards are automatically generated for US new hires when the employee has an association with their Tax Reporting Unit and is assigned to only one TRU.
A Federal component is also auto-generated for new hires.
After that, tax information can be maintained through different methods.
For example:
Employee Created │ ▼ Tax Withholding Card Generated │ ▼ Federal Component Generated │ ├── Employee Self-Service │ ├── Manual Update │ └── HDL Load
11. How Can Tax Withholding Information Be Updated?
After the Tax Withholding card has been created, organizations can maintain the employee's tax information through several approaches.
Option 1 – Employee Self-Service
Employees can update their tax components through self-service when the appropriate functionality is enabled.
Option 2 – Manual Maintenance
HR or Payroll administrators can manually update the information based on forms received from employees.
Option 3 – HCM Data Loader
The information can be loaded using HDL based on the tax forms received from employees.
This is particularly useful during:
- Data migration
- Mass employee updates
- Payroll implementation
- Tax data conversion
- Bulk correction activities
12. Important Prerequisites
Before loading or maintaining US Tax Withholding information, validate the following.
1. Employee Exists
The employee should already exist in Oracle HCM.
2. Worker Information Is Correct
Validate:
- Person
- Assignment
- Legal Employer
- Tax Reporting Unit
as applicable to the employee.
3. Tax Reporting Unit
Verify the employee's Tax Reporting Unit before creating or maintaining the US Taxation component.
4. Tax Forms
Ensure the tax information being loaded is based on the appropriate employee-provided tax forms or approved source information.
5. Effective Dates
Always validate effective dates before loading tax information.
Incorrect effective dating can result in unexpected tax information.
13. Tax Withholding HDL Implementation Flow
A simplified implementation flow is:
Employee Created ↓ Validate Tax Reporting Unit ↓ Check Existing Tax Withholding Card ↓ Determine Required Components ↓ Federal Taxes ↓ State Taxes ↓ County / City Taxes ↓ Pennsylvania PSD if Applicable ↓ US Taxation ↓ Load / Maintain Using HDL ↓ Validate Tax Card ↓ Validate Payroll Tax Calculation
14. Which Components Should Be Created?
The required components depend on the employee's tax situation.
| Component | Purpose |
|---|---|
| Tax Withholding | Identifies the employee's tax card |
| Federal Taxes | Federal tax calculation information |
| State Taxes | State resident/work tax information |
| Pennsylvania PSD | Pennsylvania PSD information |
| County Taxes | County tax information |
| City Taxes | City tax information |
| US Taxation | Tax Reporting Unit information |
Not every employee requires every component.
15. Important Difference Between Federal, State and Local Components
It is important not to treat all US tax information as a single flat record.
Oracle separates tax information into different components.
For example:
Tax Withholding │ ┌─────────────────┼─────────────────┐ │ │ │ Federal State Local │ │ │ │ ┌──────┴──────┐ ┌───┴────┐ │ │ │ │ │ Federal State A State B County City
Pennsylvania PSD and US Taxation are additional components in the hierarchy.
This component-based structure makes it possible to maintain the relevant information separately.
16. Common Implementation Scenarios
Scenario 1 – New US Employee
A new employee is hired into a US payroll environment.
The system may automatically generate:
- Tax Withholding card
- Federal Taxes component
The employee can then update tax information through self-service, or the administrator can maintain it manually or through HDL.
Scenario 2 – Bulk Tax Data Migration
During a payroll implementation, employee tax information may be migrated from a legacy system.
The implementation team can use HDL based on the employee's tax information.
The recommended approach is:
Legacy Tax Data ↓ Data Mapping ↓ Data Validation ↓ Tax Withholding HDL ↓ Import and Load ↓ Validation ↓ Payroll Testing
Scenario 3 – Employee Has State Tax Information
An employee may require state tax information in addition to federal tax information.
The appropriate State Taxes component can be maintained for the applicable state.
Scenario 4 – Local Tax Override
If the employee requires a county or city tax override, the appropriate County Taxes or City Taxes component can be maintained.
Scenario 5 – Pennsylvania PSD
When applicable Pennsylvania residency information is received, the Pennsylvania PSD component can be created for the employee.
17. Important HDL Migration Considerations
When using HDL for Tax Withholding migration, avoid treating the entire calculation card as one flat object.
Instead, understand the hierarchy first.
Recommended approach
1. Identify employee ↓ 2. Identify Tax Withholding card ↓ 3. Identify applicable tax jurisdiction ↓ 4. Identify required component ↓ 5. Map source values ↓ 6. Prepare HDL ↓ 7. Load data ↓ 8. Validate results
This makes troubleshooting easier because you can identify which component is responsible for a particular issue.
18. Recommended Tax Withholding Migration Checklist
| # | Validation | Status |
|---|---|---|
| 1 | Employee exists | ☐ |
| 2 | Assignment is valid | ☐ |
| 3 | Legal Employer validated | ☐ |
| 4 | Tax Reporting Unit validated | ☐ |
| 5 | Existing Tax Withholding card checked | ☐ |
| 6 | Federal tax information mapped | ☐ |
| 7 | State tax information mapped | ☐ |
| 8 | County tax information identified | ☐ |
| 9 | City tax information identified | ☐ |
| 10 | Pennsylvania PSD identified if applicable | ☐ |
| 11 | Effective dates validated | ☐ |
| 12 | HDL file validated | ☐ |
| 13 | HDL load completed | ☐ |
| 14 | Tax card validated | ☐ |
| 15 | Payroll tax calculation validated | ☐ |
💬 Feedback Section
Was this Oracle Fusion HCM Tax Withholding guide helpful?
If this article helped you understand US Tax Withholding, Tax Withholding HDL, Federal Taxes, State Taxes, County Taxes, City Taxes, Pennsylvania PSD, or US Taxation, please leave a comment below.
You can also share:
- Your Tax Withholding HDL scenario
- The component you are trying to load
- Your HDL error message
- Your migration requirement
- Any US Payroll topic you would like me to cover
Please remove employee names, SSNs, tax IDs, bank details, and other confidential information before sharing HDL samples.
If you want more Oracle Fusion HCM technical content covering HDL, Payroll, HCM Extracts, BI Publisher, OTBI, SQL and real-time migration scenarios, follow this blog.
No comments:
Post a Comment