Oracle Fusion HCM

Tuesday, 8 September 2026

Oracle Fusion HCM: US Tax Withholding Information Using HCM Data Loader (HDL)

 

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.

ComponentPurpose
Tax WithholdingIdentifies the employee's tax card
Federal TaxesFederal tax calculation information
State TaxesState resident/work tax information
Pennsylvania PSDPennsylvania PSD information
County TaxesCounty tax information
City TaxesCity tax information
US TaxationTax 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

#ValidationStatus
1Employee exists
2Assignment is valid
3Legal Employer validated
4Tax Reporting Unit validated
5Existing Tax Withholding card checked
6Federal tax information mapped
7State tax information mapped
8County tax information identified
9City tax information identified
10Pennsylvania PSD identified if applicable
11Effective dates validated
12HDL file validated
13HDL load completed
14Tax card validated
15Payroll 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.


Wednesday, 8 July 2026

Oracle Fusion Global Bank & Bank Branch Mapping by Country (65+ Countries) | Complete Reference Guide

 

Introduction

One of the most common challenges during Oracle Fusion HCM implementations is configuring employee bank accounts, supplier bank accounts, and payroll direct deposits across multiple countries.

Although Oracle Fusion stores bank information using a common data model, the field labels, mandatory fields, validation rules, and formats vary by country.

For example:

  • India uses IFSC Code
  • United Kingdom uses Sort Code
  • United States uses Routing Transit Number
  • Australia uses BSB
  • Germany uses BLZ
  • Canada uses Institution Number + Transit Number

This guide explains the complete global mapping of Oracle Fusion Bank and Bank Branch fields across more than 65 delivered countries.

Note

This article focuses on Oracle Fusion UI behavior and country mapping only.

HDL loading for Employee Bank Accounts is covered in a separate guide.


Oracle Fusion Global Bank Data Model

Internally Oracle stores bank information using the same attributes worldwide.

The screen labels change according to the selected country.

Screen LabelOracle AttributeDescription
BankBANK_NAMEFinancial Institution
Bank CodeBANK_CODENational Bank Identifier
Bank BranchBRANCH_NAMEBranch Name
Branch NumberBRANCH_NUMBERRouting Identifier
Account NumberACCOUNT_NUMBERCustomer Account
IBANIBANInternational Bank Account
BICBICSWIFT Code
Check DigitCHECK_DIGITValidation Digit
Secondary Account ReferenceSEC_ACCT_REFCountry Specific Extra Identifier

What Changes by Country?

Oracle changes several things automatically depending on country.

FeatureChanges?
UI label for Branch Number (e.g. "Sort Code" vs "Routing Number")✅ Yes
Whether Bank Code is required✅ Yes
Whether Branch Number is required✅ Yes
Format validation (length, check digit, numeric only)✅ Yes
Whether IBAN is mandatory on employee accounts✅ Yes
Underlying attribute names (BANK_CODE, BRANCH_NUMBER)❌ No — always the same

How Oracle Applies Country Rules

Oracle uses the delivered configuration table:

CE_CTRY_SPECIFIC_UI_RULES

This table determines

  • Required fields
  • Hidden fields
  • UI labels
  • Country validations
  • IBAN rules
  • Routing validations

Default Behavior

If Oracle doesn't deliver country-specific rules, these defaults are used.

AttributeDisplayed?Required?
Account NumberYesYes
Bank NameYesNo
Bank CodeYesNo
Branch NameYesNo
Branch NumberYesNo
BICYesNo
IBANYesNo
Account SuffixNoNo

Countries with Delivered Custom Rules

Oracle ships predefined rules for 65 countries (listed in the full table below). All other countries use the default behaviour above.

Validation vs Display Rules

Two separate layers apply:

  1. UI Rules — Which fields are shown and marked required on the employee bank account screen.

  2. Cash Management Validation — Format checks on Bank Code, Branch Number, Account Number, Check Digit, and IBAN (length, numeric, check algorithms).

You can disable format validation using profile option CE_DISABLE_BANK_VAL. UI required/display rules are not affected by this profile.



Global Identifier Patterns by Region

This is the quickest way to understand what value belongs in Bank Code vs Branch Number globally.

North America

CountryCodeBank CodeBranch NumberNotes
CanadaCAInstitution Number (3 digits, e.g. 004)Routing Transit Number (institution + 5-digit transit, e.g. 00400012)Both required on employee UI
United StatesUSNot usedRouting Transit Number (9-digit ABA)Mod-10 check digit on routing number
MexicoMXNot used on standard UINot used on standard UICLABE (18 digits) captured in Secondary Account Reference

Europe

CountryCodeBank CodeBranch NumberIBAN Required?
GermanyDEBLZ (5 digits)Optional (must match BLZ if entered)Yes
FranceFRBank Code (5 digits)Branch Code (5 digits)Yes
NetherlandsNLNot usedNot usedYes
BelgiumBENot usedNot usedYes
IrelandIENot usedNot usedYes
ItalyITNot usedNot usedYes
SpainESBank Code (4 digits)Branch Code (4 digits)Yes
PortugalPTBank Code (4 digits)Branch Code (4 digits)Yes — both required on UI
AustriaATBank Code (5 digits)Branch Code (5 digits)Yes
FinlandFINot usedNot usedYes
GreeceGRNot usedNot usedYes (+ BIC required on UI)
SwedenSEOptionalOptionalNo — if both entered, must match
NorwayNONot usedBranch Number (displayed)No
DenmarkDKRegistreringsnummer (4 digits)Not usedNo
SwitzerlandCHClearing Number (3–5 digits)Not usedNo
PolandPLNot usedNot usedYes
Czech RepublicCZNot usedNot usedYes (+ BIC required)
RomaniaRONot usedNot usedYes (+ BIC required)
HungaryHUNot usedNot usedNo — Bank Name required
TurkeyTRNot usedNot usedIBAN used for payments

United Kingdom and Crown Dependencies

CountryCodeBank CodeBranch NumberNotes
United KingdomGBNot usedSort Code (6 digits)Sort Code required; Roll Number in Secondary Account Reference for building societies
GuernseyGGOptionalSort Code (6 digits)Sort Code required
JerseyJEOptionalSort Code (6 digits)Sort Code required
Isle of ManIMOptionalSort Code (6 digits)Sort Code required

Asia Pacific

CountryCodeBank CodeBranch NumberNotes
IndiaINOptionalIFSC Code (11 chars: AAAA0BBBBBB)Bank Name + Branch Name required; IFSC in Branch Number field
AustraliaAU2–3 digit bank codeBSB (6 digits combined with bank code)BSB required; account 5–10 characters
New ZealandNZBank IDBranch NumberBoth required
JapanJPBank Code (4 digits)Branch Code (3 digits)Bank + Branch Name and Number all required
ChinaCNOptionalNot usedBank Name + Branch Name required
Hong KongHKBank CodeBranch NumberBoth required
SingaporeSGBank CodeBranch NumberBoth required
MalaysiaMYBank CodeBranch NumberBank + Branch Name required
PhilippinesPHBank CodeBranch NumberBank + Branch Name required
Republic of KoreaKRBank CodeBranch NumberBoth required
VietnamVNOptionalNot usedBank Name required only
PakistanPKOptionalNot usedBank Name required

Middle East

CountryCodeBank CodeBranch NumberIBAN Required?
United Arab EmiratesAEOptionalBranch NumberYes
Saudi ArabiaSAOptionalNot usedYes
BahrainBHNot usedNot usedYes
KuwaitKWNot usedNot usedYes
QatarQANot usedNot usedYes
OmanOMNot usedBranch Number (displayed)No
EgyptEGNot usedNot usedYes (+ BIC required)
South AfricaZANot usedBranch NumberNo — Branch Number required
MoroccoMANot usedNot usedNo — Bank Name required
SudanSDNot usedNot usedNo — Bank Name required

Latin America

CountryCodeBank CodeBranch NumberNotes
BrazilBRBank Code (3 digits)Branch (4 digits) + check digitBoth required; Company Code in Secondary Account Reference
ArgentinaARBank IDBranch NumberBoth required; CBU in Secondary Account Reference
ChileCLNot usedNot usedBank Name + Account Type required
ColombiaCONot usedNot usedBank Name + Branch Name required


High Impact Country Mapping

Canada (CA)

FieldUI LabelRequiredFormat / Rule
Bank CodeInstitution NumberYes3-digit institution number (e.g. 004 = TD)
Branch NumberRouting Transit NumberYesInstitution + 5-digit transit (e.g. 00400012)
Account NumberAccount NumberYesRequired
IBANIBANNoOptional
BICBIC CodeNoOptional for domestic EFT



United States (US)

FieldUI LabelRequiredFormat / Rule
Bank CodeBank CodeNoNot typically used
Branch NumberRouting Transit NumberYes9 numeric digits; Mod-10 check digit validation
Account NumberAccount NumberYesRequired
Account TypeAccount TypeYesChecking or Savings

Routing Number Check: The 9th digit is a check digit calculated from the first 8 digits using a Modulus 10 algorithm with weighting factors 3-7-1-3-7-1-3-7.


United Kingdom (GB)

FieldUI LabelRequiredFormat / Rule
Bank CodeBank CodeNoNot typically used
Branch NumberSort CodeYes6 numeric digits (e.g. 200415)
Account NumberAccount NumberYesRequired
Secondary Account ReferenceBuilding Society Roll NumberNoUsed for building society accounts
IBANIBANNoOptional




India (IN)

FieldUI LabelRequiredFormat / Rule
Bank NameBankYesRequired
Branch NameBank BranchYesRequired
Bank CodeBank CodeNoOptional
Branch NumberIFSC CodeNo (displayed)11 characters: 4 alpha + 0 + 6 alphanumeric (e.g. HDFC0001234)
Account NumberAccount NumberYesRequired
Account TypeAccount TypeYesRequired



Australia (AU)

FieldUI LabelRequiredFormat / Rule
Bank CodeBank CodeNo2 or 3 numeric digits if entered
Branch NumberBank State Branch (BSB)YesBank Code + Branch Number combined = 6 numeric digits
Account NumberAccount NumberYes5–10 characters; numeric for AUD

BSB Example: Bank Code 062 + Branch 000 = BSB 062000

Germany (DE)

FieldUI LabelRequiredFormat / Rule
Bank CodeBank Code (BLZ)No5 numeric digits
Branch NumberBranch NumberNo5 numeric digits; must match Bank Code if both entered
IBANIBANYes22 characters; DE + 20 digits
BICBIC CodeNoOptional

Brazil (BR)

FieldUI LabelRequiredFormat / Rule
Bank NameBankYesRequired
Bank CodeBank CodeYes3 numeric digits
Branch NumberBranch NumberYes4 numeric digits + check digit
Secondary Account ReferenceCompany CodeNoCompany code for corporate accounts

Complete Country Mapping

Need the complete mapping document? Please leave a comment below, and I'll be happy to share it with you

Quick Lookup: Branch Number Label by Country

UI LabelCountries
Routing Transit NumberCanada, United States
Sort CodeUnited Kingdom, Guernsey, Jersey, Isle of Man
Bank State Branch (BSB)Australia
IFSC CodeIndia
RegistreringsnummerDenmark (on Bank Code, not Branch)
Bank IDArgentina, New Zealand
Clearing NumberSwitzerland (on Bank Code)
Branch Number (generic)Brazil, Japan, Singapore, Hong Kong, Korea, South Africa, and others



Important Oracle Profile Options

CE_USE_EXISTING_BANK_BRANCH

Default

No

Allows users to create new banks and branches during entry.

Yes

Users must select from existing banks and branches.


CE_DISABLE_BANK_VAL

Default

No

Oracle validates:

  • IBAN
  • Routing Number
  • IFSC
  • Branch Code
  • Account Number

Yes

Skips country-specific validation (recommended only for controlled data migrations).


Best Practices 

✔ Load bank master data before employee bank accounts.

✔ Enable existing bank selection in production.

✔ Validate IFSC, BSB, Routing Number, and Sort Code before migration.

✔ Use IBAN where supported.

✔ Keep Oracle profile options consistent across environments.

✔ Perform reconciliation after migration.


Common Implementation Mistakes

  • Entering IFSC in the Bank Code field instead of Branch Number (India).
  • Using an ABA Routing Number as the Account Number (US).
  • Omitting the Sort Code for UK accounts.
  • Missing Institution Number in Canada.
  • Incorrect IBAN length for European countries.
  • Disabling validations without reviewing migrated data.

Related Articles

You may also like:


Frequently Asked Questions (FAQ)

Q1. Does Oracle use the same bank fields for all countries?

Yes. The underlying attributes remain the same, but labels and validations vary by country.

Q2. Where is the IFSC Code stored in Oracle Fusion?

For India, the IFSC Code is entered in the Branch Number field.

Q3. What is the Branch Number in the United Kingdom?

It represents the Sort Code.

Q4. What is the Branch Number in Australia?

It represents the Bank State Branch (BSB).

Q5. Does Oracle validate IBAN?

Yes, unless the CE_DISABLE_BANK_VAL profile option is enabled.

Q6. Which table controls country-specific UI behaviour?

CE_CTRY_SPECIFIC_UI_RULES.

Q7. Can bank validation be disabled?

Yes, using the CE_DISABLE_BANK_VAL profile option.

Q8. Is IBAN mandatory for every country?

No. It is required only for countries where Oracle enforces IBAN validation.


Summary of Blog

Oracle Fusion Global Bank & Bank Branch Mapping by Country (65+ Countries) | Complete Reference Guide



Feedback Section

Was this guide helpful?

If this article helped you understand Oracle Fusion Global Bank and Branch Mapping, please:

  • Share it with your colleagues and implementation team.
  • Leave a comment with any country-specific scenarios or questions.
  • Subscribe to the blog for more Oracle Fusion HCM, Payroll, HDL, HCM Extracts, BI Publisher, OTBI, and technical implementation guides.
  • If you need end-to-end Oracle Fusion HCM technical training with real-time scenarios, HDL, Reports, and HCM Extracts, feel free to get in touch through the training form on this blog.


Featured post

Oracle Fusion HCM: US Tax Withholding Information Using HCM Data Loader (HDL)

  Overview of US Tax Withholding Information in Oracle Fusion HCM In Oracle Fusion HCM, Tax Withholding calculation cards store informatio...