[$250] Travel - Error when enabling Travel Invoicing

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.77-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90239
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions

• Logged in to expensifail account that hasn't added any bank account
• User has enabled travel in a workspace

Steps:

1. Navigate to travel in the workspace
2. toggle on "Travel Invoicing"
3. Add bank account on RHP opened by choosing login to your bank account
4. Proceed the Bank Account using regions bank credentials
5. Once adding Bank Account completed, click outside RHP
6. Toggle on "Travel Invoicing" again
7. Choose the bank account
8. Wait for several secs

Expected Result:

User able to toggle on the Travel Invoicing

Actual Result:

Error when enabling Travel Invoicing

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

bandicam.2026-05-19.14-24-38-880.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056702160446133250
• Upwork Job ID: 2056702160446133250
• Last Price Increase: 2026-05-19

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user toggles "Travel Invoicing" ON and selects a bank account, the settlement account page calls configureTravelInvoicingForPolicy which sends the ConfigureTravelInvoicingForPolicy write command to the backend with {policyID, settlementBankAccountID}. The backend returns an error, and the failure data sets a generic error message (common.genericErrorMessage) on cardSettings.errors.

There are two issues here:

1. Backend error (primary): The ConfigureTravelInvoicingForPolicy command is failing server-side. The client only displays "An unexpected error occurred" because the failure handler uses a generic translation key. The specific backend error needs investigation via server logs.

2. UX gap (secondary): When the API call fails, the error is set on cardSettings.errors which is only displayed under the toggle on the parent page. The user is still on the settlement account page where configureTravelInvoicingForPolicy was called without a Navigation.goBack(), so when the loading state clears with isLoading=false and isSuccess=false, the page silently falls back to the account selector with no visible error.

What changes do you think we should make in order to solve the problem?

1. Investigate the backend error: Check server logs for the ConfigureTravelInvoicingForPolicy command to identify why it's failing. This appears to be a backend/internal issue. A separate internal investigation is needed.

2. Improve error visibility on the settlement account page: When configureTravelInvoicingForPolicy fails, the settlement account page should either:

   • Navigate back and show the error on the toggle (consistent with the current error placement), or
   • Display the error directly on the settlement account page so the user sees feedback where they are

Investigation details

Code flow traced:

1. Toggle ON → handleToggle(true) → continueToggleFlow()
2. No settlement account → navigates to settlement account page
3. User selects bank account → handleSelectAccount(value)
4. Since !isTravelInvoicingEnabled → calls configureTravelInvoicingForPolicy(policyID, workspaceAccountID, value)
5. Optimistic data sets isLoading: true → page shows loading verification state
6. Backend returns error → failure data sets isLoading: false, isSuccess: false, errors: genericErrorMessage
7. Page falls back to account selector with no visible error; error only appears on toggle on parent page

Alternative explanations considered:

• Wrong Onyx key / workspaceAccountID being 0: Unlikely since the user reaches the travel page successfully, meaning the policy is loaded
• Race condition with OpenPolicyTravelPage: Possible but wouldn't cause a consistent repro across platforms
• PR Add NetSuite Travel invoice reconciliation setting #90239 regression: That PR modified TravelInvoicing.ts for NetSuite reconciliation settings but didn't change configureTravelInvoicingForPolicy

Related issues: Expensify/App#91023 — NetSuite travel invoicing export crash (different flow but same feature area)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 11:56:20 UTC.

Proposal

What is the root cause of that problem?

The Travel Invoicing settlement-account picker — both the toggle path and the row tap — is fed by getEligibleBankAccountsForCard (src/libs/CardUtils.ts:437-445):

return Object.values(bankAccountsList).filter(
    (bankAccount) =>
        bankAccount?.accountData?.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS && bankAccount?.accountData?.allowDebit && !isBankAccountPartiallySetup(bankAccount?.accountData?.state),
);

isBankAccountPartiallySetup (src/libs/BankAccountUtils.ts:15-17) is a denylist that only excludes SETUP/VERIFYING/PENDING. The declared BANK_ACCOUNT.STATE set (src/CONST/index.ts:674-682) is VERIFYING / VALIDATING / SETUP / PENDING / OPEN / DELETED / LOCKED, so VALIDATING (the transient post-Plaid state) and LOCKED slip through the filter — only BUSINESS + allowDebit are enforced beyond the denylist.

In the repro path, the user lands on the bank picker right after Plaid/Regions linking with the RHP dismissed mid-VBBA. The fresh row's allowDebit was flipped on by ConnectBankAccountWithPlaid (src/libs/actions/BankAccounts.ts:415-444) but state is not yet OPEN — it's the transient post-Plaid state the denylist doesn't cover. The bank therefore renders in WorkspaceTravelInvoicingSettlementAccountPage (src/pages/workspace/travel/WorkspaceTravelInvoicingSettlementAccountPage.tsx:63-78).

handleSelectAccount (src/pages/workspace/travel/WorkspaceTravelInvoicingSettlementAccountPage.tsx:80-94) has no state guard — it fires configureTravelInvoicingForPolicy(policyID, workspaceAccountID, value) straight at the not-yet-OPEN row. After "wait for several secs", the backend rejects the not-yet-valid settlementBankAccountID and the failureData branch in configureTravelInvoicingForPolicy (src/libs/actions/TravelInvoicing.ts:432-446) writes cardSettings.errors = getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'). That root-level errors is what WorkspaceTravelInvoicingSection reads as toggleErrors (src/pages/workspace/travel/WorkspaceTravelInvoicingSection.tsx:124) and surfaces under the toggle as "Error when enabling Travel Invoicing".

Note the existing helper hasInProgressUSDVBBA (src/libs/ReimbursementAccountUtils.ts:41-43) already uses the inverse strict semantic — "in-progress" = state !== OPEN && state !== LOCKED. The eligible-bank filter is the only place still leaning on the brittle denylist, which is why the picker and the toggle-flow guard isSetupUnfinished disagree on the same row.

What changes do you think we should make in order to solve the problem?

Replace the denylist with the strict state === OPEN check in getEligibleBankAccountsForCard, matching the semantic hasInProgressUSDVBBA already enforces. This collapses the picker/guard divergence and rejects every non-OPEN row at the source — VALIDATING, LOCKED, DELETED, and the unhandled-state edges all drop out for free.

--- a/src/libs/CardUtils.ts
+++ b/src/libs/CardUtils.ts
 function getEligibleBankAccountsForCard(bankAccountsList: OnyxEntry<BankAccountList>) {
     if (!bankAccountsList || isEmptyObject(bankAccountsList)) {
         return [];
     }
     return Object.values(bankAccountsList).filter(
         (bankAccount) =>
-            bankAccount?.accountData?.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS && bankAccount?.accountData?.allowDebit && !isBankAccountPartiallySetup(bankAccount?.accountData?.state),
+            bankAccount?.accountData?.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
+            bankAccount?.accountData?.allowDebit &&
+            bankAccount?.accountData?.state === CONST.BANK_ACCOUNT.STATE.OPEN,
     );
 }

The isBankAccountPartiallySetup import at src/libs/CardUtils.ts:48 is no longer referenced inside this helper and can be removed if no other usage in the file remains. getReconciliationBankAccount (src/libs/CardUtils.ts:470-486) still legitimately uses the denylist for its own picker, which is fine — that's the reconciliation source-account list, not the settlement target.

Secondary hardening in handleSelectAccount so a stale row that bypasses the filter (e.g., race between the row write and the picker render) still cannot poison the configure call:

--- a/src/pages/workspace/travel/WorkspaceTravelInvoicingSettlementAccountPage.tsx
+++ b/src/pages/workspace/travel/WorkspaceTravelInvoicingSettlementAccountPage.tsx
     const handleSelectAccount = (value: number) => {
         if (value === paymentBankAccountID) {
             Navigation.goBack();
             return;
         }
+
+        const selected = bankAccountsList?.[String(value)];
+        if (selected?.accountData?.state !== CONST.BANK_ACCOUNT.STATE.OPEN) {
+            return;
+        }

What alternative solutions did you explore? (Optional)

• Tighten isBankAccountPartiallySetup to include VALIDATING. Rejected: still a denylist — every newly added BANK_ACCOUNT.STATE value has to be remembered in two places, and LOCKED/DELETED rows would still slip through.
• Block in configureTravelInvoicingForPolicy by short-circuiting when the chosen bank isn't OPEN. Rejected: the user already sees a non-OPEN row in the picker — failing silently at the action layer trades one bad UX for another. Hide the row at the source instead.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 11:49:58 UTC.

Replaces my earlier proposal. The earlier version over-focused on Travel Invoicing configure Onyx state. Re-reading the issue steps and current code shows the primary bug is the settlement-account eligibility mismatch that allows a freshly added, not-yet-OPEN VBBA to be selected.

Proposal

Please re-state the problem that we are trying to solve in this issue.

After adding a business bank account from the Travel Invoicing enable flow, the user can immediately select that account as the Travel Invoicing settlement account, but enabling Travel Invoicing ends in an error instead of completing.

What is the root cause of that problem?

The Travel Invoicing enable flow reuses the Expensify Card settlement-account eligibility helper, getEligibleBankAccountsForCard(), for both the toggle gate and the settlement-account selector.

That helper only checks that the account is a business account, allows debit, and is not isBankAccountPartiallySetup(state). But isBankAccountPartiallySetup() only excludes SETUP, VERIFYING, and PENDING. It does not require the bank account to be OPEN, so an account that is still not usable as a funding/settlement source, such as a freshly Plaid-created account in VALIDATING, can pass the filter.

The Travel toggle has a stricter unfinished-bank-account concept via hasInProgressUSDVBBA(), which treats a VBBA with any state other than OPEN or LOCKED as still in progress. The problem is that the selector and the toggle eligibility list do not consistently enforce the same ready-for-settlement rule from bankAccountList. After the bank flow returns, the newly added account can be present in bankAccountList before it is actually OPEN, and the settlement selector still renders it as selectable.

When Travel Invoicing is disabled and the user selects that not-yet-open account, WorkspaceTravelInvoicingSettlementAccountPage.handleSelectAccount() calls configureTravelInvoicingForPolicy(policyID, workspaceAccountID, value). That sends the not-ready settlementBankAccountID to ConfigureTravelInvoicingForPolicy, the backend rejects the configure request, and the current configureTravelInvoicingForPolicy() failure data stores the error on the root card-settings errors, which surfaces as the generic Travel Invoicing toggle error.

What changes do you think we should make in order to solve the problem?

Only allow fully usable settlement accounts to reach the Travel Invoicing configure command.

• Tighten the settlement-account eligibility logic so the account must be a business debit account with accountData.state === CONST.BANK_ACCOUNT.STATE.OPEN. The smallest implementation is to update getEligibleBankAccountsForCard() to require OPEN. If we want to avoid changing any non-settlement call sites, introduce a new helper for settlement-account eligibility and use it in the Expensify Card and Travel Invoicing settlement selectors/toggle gates.
• Keep WorkspaceTravelInvoicingSection.continueToggleFlow() and WorkspaceTravelInvoicingSettlementAccountPage on that same eligibility rule. If the only available bank account is still validating, the flow should keep the user in/return the user to bank-account setup instead of showing that account as selectable.
• Add a defensive selected-account guard before calling configureTravelInvoicingForPolicy() in both Travel call sites. If a stale selector option or stale Onyx state points to an account whose state is not OPEN, do not call ConfigureTravelInvoicingForPolicy; route back to the bank-account setup/verification flow or show the existing settlement-account error state.
• As cleanup, update the failure handling for the account-selection configure path so failed settlement-account selection clears pendingFields.paymentBankAccountID and surfaces the error under errorFields.paymentBankAccountID instead of only root errors. This keeps account validation failures attached to the settlement account row and avoids making the Travel Invoicing toggle look like the failing control.
• Add tests around getEligibleBankAccountsForCard() (or the new settlement helper) covering OPEN, VALIDATING, VERIFYING, PENDING, SETUP, and LOCKED, plus a Travel Invoicing unit test that a non-OPEN selected account does not call configureTravelInvoicingForPolicy().

Scope boundaries:

• Files likely touched: src/libs/CardUtils.ts, src/libs/BankAccountUtils.ts only if a helper split is chosen, src/pages/workspace/travel/WorkspaceTravelInvoicingSettlementAccountPage.tsx, src/pages/workspace/travel/WorkspaceTravelInvoicingSection.tsx, and focused tests.
• Platforms: all platforms, because this is shared TypeScript action/page logic.
• Backend/API contracts: no backend behavior change is required. The client should stop sending invalid settlement bank accounts to ConfigureTravelInvoicingForPolicy.
• Out of scope: bank-account setup itself, Plaid flow internals, accounting export/reconciliation settings, Travel booking, and unrelated reimbursement flows.

What alternative solutions did you explore? (Optional)

I first considered fixing only configureTravelInvoicingForPolicy() by making its optimistic/failure Onyx state write the selected Travel Invoicing account more carefully. That cleanup is still useful, but it does not prevent the bad API call. The backend would still receive a settlement account that is not ready to be used.

I also considered adding only VALIDATING to isBankAccountPartiallySetup(), but that helper is used outside settlement-account selection. A positive OPEN requirement at the settlement-account eligibility boundary is clearer and safer because OPEN is the state where the account is actually usable as a funding source.

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ZhenjaHorbach (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022056702160446133250

[mukhrr]

Proposal

What is the root cause of that problem?

The error in the screenshot — "JSON Type Error, expected: 'object' actual: 'string' key: 'error_code' method: 'hasMember'" — is the raw backend response from CONFIGURE_TRAVEL_INVOICING_FOR_POLICY being surfaced into the Travel Invoicing toggle's Onyx errors. It fires because the App submits a bank account that is not yet a fully verified (OPEN) VBBA as the settlement account.

When the user adds a bank account through "log into your bank" (Plaid) and immediately returns, the freshly created VBBA is still being verified — it is not in the OPEN state yet. The settlement account selector builds its list with getEligibleBankAccountsForCard, whose only state filter is !isBankAccountPartiallySetup(...):

• src/libs/CardUtils.ts#L437-L446
• src/libs/BankAccountUtils.ts#L15-L17

isBankAccountPartiallySetup only excludes SETUP, VERIFYING, and PENDING. It does not require the account to be OPEN, so an account in another not-yet-ready state (e.g. VALIDATING) passes the filter and is shown as a selectable settlement account. The user selects it and handleSelectAccount calls configureTravelInvoicingForPolicy with a bankAccountID the backend cannot use as a settlement account, which fails and returns the malformed error.

There's also an internal inconsistency: the toggle gate uses hasInProgressUSDVBBA (anything not OPEN/LOCKED is "in progress"), while the settlement list uses the looser !isBankAccountPartiallySetup — so the two disagree about whether the just-added account is ready: WorkspaceTravelInvoicingSection.tsx#L173-L182.

What changes do you think we should make in order to solve the problem?

Only treat fully verified (OPEN) business bank accounts as eligible for the card/settlement account. This aligns the eligibility list with the hasInProgressUSDVBBA toggle gate and prevents the App from ever submitting a not-yet-open account to CONFIGURE_TRAVEL_INVOICING_FOR_POLICY.

In getEligibleBankAccountsForCard (src/libs/CardUtils.ts):

-    return Object.values(bankAccountsList).filter(
-        (bankAccount) =>
-            bankAccount?.accountData?.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS && bankAccount?.accountData?.allowDebit && !isBankAccountPartiallySetup(bankAccount?.accountData?.state),
-    );
+    return Object.values(bankAccountsList).filter(
+        (bankAccount) =>
+            bankAccount?.accountData?.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
+            bankAccount?.accountData?.allowDebit &&
+            bankAccount?.accountData?.state === CONST.BANK_ACCOUNT.STATE.OPEN,
+    );

With this, a freshly-added but not-yet-verified bank account no longer appears in the settlement selector, so the toggle flow keeps routing the user back through bank-account setup until the VBBA is actually OPEN — matching the existing hasInProgressUSDVBBA gate and eliminating the failing API call.

As a defensive follow-up, configureTravelInvoicingForPolicy's failureData should win over the raw backend string so users never see an internal "JSON Type Error…" message — but that's secondary to not submitting an invalid account in the first place.

What alternative solutions did you explore? (Optional)

• Guard inside handleSelectAccount / continueToggleFlow to block selection when the chosen account's state !== OPEN and show an inline message. Rejected as the primary fix because it duplicates the "is this account ready" logic that already lives in the eligibility helper and hasInProgressUSDVBBA; fixing the shared filter is DRY and also corrects the same class of bug for Expensify Card, which equally requires an OPEN settlement account.
• Add only VALIDATING to isBankAccountPartiallySetup. Rejected because that helper is consumed by many unrelated payment/payer flows; whitelisting OPEN directly in getEligibleBankAccountsForCard is the minimal, targeted change and is the only state where the account is genuinely usable as a funding source.

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).