Payroll outbound integration to bank fails due to invalid routing number format in payment file

ERP Workday
, , , , , , , ,
1

Our payroll outbound integration to our banking partner started failing this week after running successfully for six months. The integration sends ACH payment files for direct deposit processing. We’re getting validation errors from the bank stating that routing numbers are in an invalid format.

Here’s the error message we’re receiving:


Error Code: ROUTE_FORMAT_INVALID
Message: Routing number must be 9 digits, found: 021000021-001
Field: BankRoutingNumber
Record: Employee ID 847392

When I check the employee’s banking information in Workday, the routing number displays correctly as “021000021” without any suffix. However, the outbound XML file appears to be appending “-001” to some routing numbers. This is affecting about 15% of our employee population (approximately 450 employees out of 3,000). I’ve verified the bank routing number validation rules in our payment file format, but I can’t figure out where this suffix is coming from or why it’s only affecting certain employees. Has anyone dealt with routing number formatting issues in payroll outbound integrations?

2

Good catch on checking for patterns. I analyzed the affected employees and they all have accounts at three specific regional banks. When I looked at the Bank object configuration for these banks in Workday, I noticed they have multiple branch locations configured. Could the branch identifier be getting pulled into the routing number field somehow?

3

I’ve seen this before with custom calculated fields in integration mappings. If you have any custom XSLT transformations or calculated fields in your outbound integration that manipulate the routing number field, that could be the source. Also check if you’re pulling routing number from multiple sources - sometimes there’s a primary routing number field and a secondary one that includes branch codes. The integration might be inadvertently combining them.

4

Here’s the complete solution to fix your payroll outbound integration routing number issue.

Bank Routing Number Validation: The problem is caused by your integration mapping pulling branch identifier data along with the routing number. Here’s how to fix it:

First, identify the exact field mapping in your integration:

  • Open Integration Studio and locate your payroll outbound integration
  • Navigate to the Assembly section where you map employee banking data
  • Find the BankRoutingNumber field mapping in your XML structure
  • Check the XPath expression - it’s likely referencing something like:
wd:Employee_Banking_Info/wd:Bank_Branch/wd:Routing_Identifier

The correct mapping should reference only the routing number:

wd:Employee_Banking_Info/wd:Bank/wd:Routing_Number

Outbound Payment File Formatting: To ensure proper formatting of your ACH payment file:

  • Update your XPath to reference the direct routing number attribute: `wd:Routing_Number
  • Add a validation rule in your integration to enforce exactly 9 digits
  • Remove any references to Branch objects or Branch_Identifier fields
  • If you need branch information for internal tracking, map it to a separate field that’s not sent to the bank

Payroll Integration Error Handling: Implement these safeguards to prevent similar issues:

Add a validation step in your integration:

  • In Integration Studio, add a Validation rule before the outbound assembly
  • Configure the rule to check routing number format: must be exactly 9 numeric digits
  • Set the validation to fail the integration if any routing numbers don’t match the pattern
  • This will catch formatting issues before files are sent to your bank

Set up error notifications:

  • Configure your integration to send email alerts when validation failures occur
  • Include the specific employee IDs and routing numbers that failed validation
  • This allows your payroll team to correct data issues proactively

Testing Steps: Before deploying your fix to production:

  1. Create a test version of your integration in your sandbox tenant
  2. Run the integration for the 450 affected employees only
  3. Export the output XML file and validate the routing number format
  4. Verify each routing number is exactly 9 digits with no suffixes
  5. Test with your bank’s file validation tool if they provide one
  6. Once confirmed working, deploy to production during your next maintenance window

Root Cause Prevention: For the three regional banks causing issues:

  • Review their Bank object configuration in Workday
  • If branch locations are configured, ensure the Routing_Number field contains only the 9-digit ABA number
  • Move any branch identifiers to a separate Branch_Code or Branch_Location field
  • Document this configuration standard for future bank setups

Immediate Remediation: For this week’s payroll run:

  • Manually correct the routing numbers in the output file if you have time constraints
  • Or run a separate integration for the 450 affected employees using a corrected mapping
  • Notify your banking partner about the corrected file resubmission

This issue typically takes 2-3 hours to fix including testing. The validation rules will prevent it from recurring.

5

The “-001” suffix you’re seeing is likely coming from a branch or sub-account identifier that’s somehow being concatenated with the routing number. Check if those 450 affected employees have anything in common - same bank, same hire date batch, or same payroll company. This could help narrow down where the extra data is coming from.

6

I want to emphasize the importance of testing this fix thoroughly before deploying to production, especially since you’re dealing with actual payroll payments. Set up a test integration with a subset of affected employees and validate the output file format matches your bank’s specifications exactly.