I’m trying to determine whether others have seen ProConnect silently “normalize” a valid bank routing number to a different one based on the taxpayer’s state of residence. 

Have you had e-pay failures that might tie back to this behavior?

The Scenario

• Client: Full-year Colorado resident.

• Bank: JPMorgan Chase.

• Data Entry: I entered routing 322271627 (CA/NV region) directly from the client's voided check, scheduled payment on April 15, 2026.  Return was later e-filed and accepted on 4/3/2026.    

• Issue Raised: Client called on 4/21/2026, complained that the taxpayment scheduled on 4/15/2026 still didn't withdrawn from his checking account today.   

• The Swap: Upon review, I've concluded that ProConnect had changed the field to 102001017—a valid Chase routing number, but specifically the one tied to Colorado ACH transactions - since the Taxpayer who opened their checking account in California years ago is now a Colorado full time resident.  

• Precluding Data Entry Issue on my end: Although I also bank with Chase, but I do not remember my routing number by heart.  There is no way that I would look at a Voided check image while entering an accurate routing number of Colorado that I do not remember by heart.  I clearly remember keying in both the routing and account information and inspected for typo before sending it for client signature.  

My Research

It seems that in the past, users had issues with Intuit software on critical diagnostic message over an accurate routing number and deem it "invalid".  https://accountants.intuit.com/community/proconnect-tax-discussions/discussion/how-do-i-get-proconne...

It appears that for the 2026 tax season, ProConnect may be applying a "state-based normalization" logic and created this ghost. It sees a Colorado return + Chase account and "corrects" the routing number to the Colorado regional code, even though the client’s account was opened in a different region.

The Problem

The IRS is now reporting issues with this direct debit. Because the software made this change silently—with no diagnostic or override prompt—the client is blaming the failure to pay as a data-entry error on my part, understandably.

Has anyone else experienced this? 1. Have you seen ProConnect override a valid routing number with a different regional number from the same bank? 2. For those who are experiencing e-Pay delay client calls, would you please check if the routing number override software activity also happened to your tax return?  

I’m trying to gauge if this is a systemic "feature" that we need to be manually double-checking on every routing number location now and see if they consistent with the taxpayer's residence state now?  

While some banks like Chase have moved toward "One Routing Number" for all electronic transfers, many legacy accounts still require the specific regional routing number printed on the check to process correctly. If Intuit is forcing a "correct" number based on the taxpayer's address, it’s likely breaking the link for accounts opened in different states.