A traveler must update EFT bank account details in the payment system of the specific organization that owes the money — typically the travel management system, expense platform, or vendor payment portal named in the reimbursement policy — not with the airline, hotel, or booking site. For U.S. federal travelers, that means the agency's travel system of record (for example, a Defense Travel System or E-Gov Travel Service instance) tied to the employee profile; for corporate travelers, the expense management platform or ERP vendor master. The update must occur before the payment batch runs, and any change to an existing account should be treated as a re-verification event, because fraud controls frequently freeze first-time or altered banking data.
How the payment chain decides where your bank data lives
Reimbursement is not one transaction. It is a chain: an entitlement is created (an approved voucher, expense report, or claim), validated against policy, scheduled into a payment run, and then executed by a disbursing or treasury function that transmits an ACH (Automated Clearing House) credit to the bank account on file. The account details live at the node that executes the ACH, not at the node where you booked travel.
That distinction explains most traveler confusion. A booking site stores a card for purchasing; an expense platform stores a payee record for reimbursing. When the two are separate systems, changing the card on the booking site does nothing to the reimbursement destination. The payee record — sometimes called vendor master data, payee profile, or employee banking profile — is the authoritative source, and it is usually owned by finance, not by the traveler's supervisor.
One level deeper: ACH routing depends on two fields, the routing transit number and the account number, plus an account type flag (checking or savings). The routing number's check digit is validated at entry in most systems, but account numbers are not checksum-protected in the same way. That asymmetry is why a single transposed digit can pass validation and still misdirect funds. The system cannot know the account is wrong; it only knows the format is plausible. Verification, therefore, is a process control, not a data-entry check.
A second mechanism matters for timing. Payment runs are batched. A voucher approved on Monday may not transmit until a scheduled disbursement cycle later that week or month. The account on file at transmission time is the one that receives funds. Updating after the batch is built but before transmission can still work in some systems and fail in others, which is why the reliable rule is to update before approval, not after.
Quantified context: how often banking data is wrong or frozen
Exact error rates are not publicly standardized, so treat any single percentage with caution. What can be said with confidence is structural: banking-detail changes are a recognized fraud vector, which is why payment organizations impose verification holds. In practice, a first-time account entry or a change to an existing account commonly triggers a review window measured in hours to several business days, and some organizations add a call-back verification step before releasing the first payment to a new account.
The financial stakes are concrete. A misdirected ACH credit does not vanish instantly; it lands in someone's account and must be recovered through the receiving bank, a process that can take days to weeks and depends on the recipient's cooperation. For a typical domestic trip reimbursement in the hundreds to low thousands of dollars, recovery is feasible but slow. For larger amounts, the recovery effort scales with the sum.
Timing also has a measurable cost. If a traveler updates banking data after voucher approval, the payment may miss the current cycle and wait for the next one. The gap between cycles varies by organization — weekly, biweekly, or monthly disbursement is common — so a late update can add one full cycle of delay even when nothing is wrong with the account.
Edge cases that break the simple answer
Joint and shared accounts create ambiguity. If the account on file is a joint account and the primary holder changes, the name-match controls some payment systems apply may reject the credit even though the account number is valid. The fix is to confirm the payee name exactly as the bank holds it, which may differ from how it appears on the traveler's ID.
Closed or migrated accounts are the most common silent failure. Banks merge, rename, and renumber accounts. A routing number that was valid last year can become invalid after a merger, and the payment fails at the receiving bank after leaving the payer. This is why travelers who change banks should update proactively rather than waiting for a failed payment notice.
International travelers face a different node. When reimbursement must cross borders, the payment may route through a separate foreign-exchange or international payment provider with its own banking-detail requirements, including intermediary bank information and SWIFT codes. Updating the domestic profile may not update the international payout instruction. The traveler must confirm which payment rail will be used before assuming one update covers both.
Contractor and split-payment arrangements add another layer. When a trip is reimbursed partly by one organization and partly by another — common in sponsored research or multi-party projects — each payer holds its own payee record. Updating one does not propagate to the other. The traveler must identify every payer in the reimbursement chain.
Misconceptions that cause failed payments
The most persistent misconception is that the booking profile and the payment profile are the same record. They usually are not, and they are often owned by different departments with different verification rules.
A second is that a saved account stays valid indefinitely. Bank details are stale-prone: accounts close, institutions merge, and fraud controls periodically require re-verification. Treat saved banking data as perishable.
A third is that updating after approval is harmless. It is harmless only if the payment batch has not been built. Once transmitted, the destination is fixed for that payment, and correction requires a recall or a reissue.
A fourth is that the traveler can always self-service the change. Many organizations restrict banking-detail changes to finance staff or require dual approval, precisely because self-service change is the fraud pattern attackers exploit. The traveler may be able to initiate the change but not complete it alone.
Comparison: where banking details typically live
| Location | What it controls | Who usually owns it | Typical verification on change |
|---|---|---|---|
| Travel management system profile | Voucher routing and payee link for agency or corporate travel | Finance or travel program office | Identity check plus possible call-back |
| Expense management platform payee record | Reimbursement ACH destination for expense reports | Finance or shared services | Format validation, sometimes hold period |
| ERP vendor master | Payment execution for the legal entity | Accounts payable or treasury | Dual approval, bank-letter verification |
| Booking site stored card | Purchase authorization only | Traveler or travel arranger | Card network controls, not ACH |
| International payment provider | Cross-border payout instructions | Treasury or AP | Intermediary bank details required |
The table makes the operative point: only the rows tied to payment execution determine where reimbursement lands. The booking-site row never does.
Timeline: what happens between update and funds arriving
| Stage | Typical duration | What can go wrong |
|---|---|---|
| Traveler submits banking change | Minutes | Typo in account number passes format check |
| System or finance review | Hours to several business days | Change held pending verification |
| Voucher or expense report approved | Same day to several days | Approval delayed by missing receipts |
| Payment batch built | Scheduled cycle | Change made after batch build is missed |
| ACH transmission | 1–3 business days to settle | Closed account or name mismatch causes return |
| Return and reissue if failed | Days to weeks | Recovery depends on receiving bank |
Reconciling the thresholds: the review window (hours to days) and the settlement window (one to three business days) are different clocks. The binding constraint is usually the payment batch schedule, which can be weekly or monthly. The practical rule that reconciles all three is to submit the banking change before the expense report or voucher is approved, and to allow at least one full business day before the expected disbursement date.
Practical actions with concrete thresholds
Confirm the payer entity before traveling. Identify every organization that will reimburse any part of the trip, and note which platform each uses. Update banking details at the payment system of record, not the booking site. Look for labels such as payee profile, vendor master, or reimbursement account. Submit changes before voucher approval. If approval has already occurred, contact finance and ask whether the payment batch has been built; if it has, request a hold. Verify the routing number and account number against a bank statement, not a card. Read the digits aloud to a second person to catch transposition. Confirm the payee name exactly as the bank holds it, including middle initials or suffixes that affect name matching. Red flag: any email, text, or call instructing you to change banking details urgently. Verify through the official portal or a known phone number, never through contact details supplied in the message. Red flag: a request to split a reimbursement across two accounts. Legitimate payers rarely need this, and it is a common fraud pattern. Red flag: a banking change that requires you to bypass the standard portal "just this once." No legitimate finance function asks for that.
For high-value reimbursements, a proactive confirmation step is worth the effort: after submitting the change, ask finance to confirm the payee record is active before the batch runs. This costs one message and prevents a multi-week recovery cycle.
Limitations and what this guidance cannot cover
Payment systems differ by organization, and no single article can enumerate every platform's verification rules. The mechanisms described here — payee record at the disbursing node, batch timing, format-versus-verification asymmetry, stale account risk — are stable across systems, but specific hold periods, approval chains, and portal names are organization-specific and must be confirmed with the payer's finance or travel office.
Recovery outcomes for misdirected payments also cannot be promised. Recovery depends on the receiving bank, the recipient's cooperation, and the elapsed time, and success rates are not publicly standardized. Treat prevention as the only reliable control.
This article is general educational information about reimbursement payment mechanics, not a legal opinion, tax or financial recommendation, or a guarantee of payment outcomes. Banking and reimbursement rules vary by organization and jurisdiction, and misdirected payments can involve legal and tax consequences. Consult your organization's finance or travel office, and a qualified local professional where needed, before relying on this information for a specific reimbursement or banking change.