[$250] Expense - Add bank account button shown even if we already have connected bank account

[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: 9.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: #89804
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 pro /Chrome
App Component: Chat Report View

Action Performed:

Precondition: Have WS connected to Bank Account

1. Navigate to staging.new.expensify.com
2. Create expense
3. Submit expense > approve > pay

Expected Result:

The expense is paid with the bank account

Actual Result:

There is a thread message asked to add bank account

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056696226716058350
• Upwork Job ID: 2056696226716058350
• Last Price Increase: 2026-06-02

Issue Owner

Current Issue Owner: @stitesExpensify

[melvin-bot]

📣 @nguyencaoky1121-dev! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[enok1111]

HI! I'll start working on this right away, please if could assign it to me. I'll be sharing more details soon. Thanks!

Contributor details
Your Expensify account email: bitup.games@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0112988f95e0f81910?mp_source=share

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[MelvinBot]

Proposal

Problem

When paying an approved expense report on a workspace with a connected bank account, the server sets isWaitingOnBankAccount=true and creates a REIMBURSEMENT_QUEUED report action. The client then renders a "started payment, but is waiting for [name] to add a bank account" message with an "Add bank account" button — even though the workspace already has a connected bank account.

Solution

This issue has two layers — a server-side root cause and a client-side rendering concern:

Server-side (root cause): The PayMoneyRequest API command sets isWaitingOnBankAccount=true on the report. The client sends the payment request without a bankAccountID for expense reports (because methodID is not passed from SettlementButton for non-invoice expense reports), so the server must resolve the bank account from the policy. The server appears to be incorrectly determining that the submitter needs to add a bank account, even when the workspace has a valid connected bank account for disbursement.

Client-side (rendering): ReimbursementQueuedContent renders the "Add bank account" button when getIndicatedMissingPaymentMethod returns 'bankAccount'. This function checks whether the submitter has a defaultCredit bank account via hasCreditBankAccount. This check is about the submitter's personal bank account for receiving reimbursements, not the workspace bank account used for sending payment.

The fix depends on the intended product behavior:

1. If the submitter should be able to receive reimbursements to the workspace bank account directly → the server should not set isWaitingOnBankAccount=true when a workspace bank account is available. This requires a backend change (consistent with the Internal label).
2. If the submitter genuinely needs a personal bank account to receive ACH deposits → the UX messaging should be clearer about why a bank account is needed (to receive payment, not to send it), since the current message is confusing when the workspace already has a connected bank account.

Investigation details

Payment flow trace:

1. User clicks Pay → SettlementButton.selectPaymentType calls onPress({paymentType, payAsBusiness: false}) without methodID
2. payMoneyRequest sends bankAccountID: undefined for VBBA type since methodID is undefined
3. Client optimistically sets isWaitingOnBankAccount: false
4. Server processes PayMoneyRequest, determines submitter needs a bank account, sets isWaitingOnBankAccount=true in response
5. ReimbursementQueuedContent renders "waiting for [name] to add a bank account"
6. getIndicatedMissingPaymentMethod shows "Add bank account" button because hasCreditBankAccount returns false (submitter lacks a defaultCredit personal bank account)

Key distinction: The workspace bank account (checked via getOpenConnectedToPolicyBusinessBankAccounts at the KYCWall) is for sending payments. The hasCreditBankAccount check is for the submitter's personal bank account for receiving ACH deposits. These are separate bank accounts.

Possibly related issues:

• Expensify/App#90524 — "Mark as paid button leads to Add bank page"
• Expensify/App#88984 — "App returns to Add bank account after employee completed add bank from expense"
• Expensify/App#78241 — "Invoice shows waiting for user to add a bank account despite payer already having a verified bank account"

---

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.

[KJ21-ENG]

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

Replaces my earlier proposal. I re-read the post-fire thread/code and corrected the root cause: the broken payment request is not just missing a policy-backed option, it is losing the VBBA bankAccountID/methodID before PayMoneyRequest.

Proposal

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

When paying an approved workspace expense from the report view, the app can create a reimbursement-queued thread message asking someone to add a bank account even though the workspace already has a connected reimbursement bank account.

The expected behavior is to pay the expense with the existing workspace bank account.

What is the root cause of that problem?

The App has two client-side gaps in the VBBA payment path.

First, SettlementButton builds concrete business bank account options only from ONYXKEYS.BANK_ACCOUNT_LIST. It formats bankAccountList, calls getBusinessBankAccountOptions(formattedPaymentMethods), and for expense reports falls back to paymentMethods[CONST.PAYMENT_METHODS.BUSINESS_BANK_ACCOUNT] when that list is empty.

That fallback is only the generic business-bank payment method. It has no methodID, even though the workspace reimbursement account is already available on policy.achAccount. The same component already uses policy.achAccount for pay intent/last-four display, but not for constructing the actual VBBA option.

Second, the report-preview pay path drops the bank account ID even when it is selected. PayActionButton.confirmPayment receives methodID, but the non-invoice branch calls payMoneyRequest(...) without passing it. payMoneyRequest already knows how to serialize methodID into bankAccountID for CONST.IOU.PAYMENT_TYPE.VBBA; it just receives undefined from this path. The header pay path in PayPrimaryAction already forwards methodID for VBBA, so the report-preview path is inconsistent.

When the server receives a VBBA pay request without bankAccountID, it can return a reimbursement-queued action. ReimbursementQueuedContent then renders the waiting/add-bank-account message via getIndicatedMissingPaymentMethod, which is the symptom reported here.

The bulk-pay path has the same option-construction gap because useBulkPayOptions also derives business bank options only from BANK_ACCOUNT_LIST; it only sends bankAccountID when the selected option supplies additionalData.bankAccountID.

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

Make the workspace reimbursement account a concrete VBBA payment option and preserve its ID all the way to the API call.

Concretely:

1. Add a shared helper, likely in PaymentUtils, that builds a business-bank payment option from policy.achAccount when:
   • the report is an expense report,
   • policy.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES,
   • policy.achAccount.bankAccountID exists,
   • policy.achAccount.state is OPEN or LOCKED, and
   • the account state is not partially set up.
2. Merge that policy-backed option with getBusinessBankAccountOptions(formattedPaymentMethods), de-duped by methodID.
3. Use the merged list in SettlementButton for both the displayed business bank options and the default/split-button path. Only show the generic add/connect business-bank fallback when there is no valid BANK_ACCOUNT_LIST option and no valid policy.achAccount option.
4. When a valid business bank account option is selected, including the default split-button press, call onPress with:
   • paymentType: CONST.IOU.PAYMENT_TYPE.VBBA,
   • payAsBusiness: true,
   • methodID: account.methodID,
   • paymentMethod: CONST.PAYMENT_METHODS.BUSINESS_BANK_ACCOUNT.
5. In PayActionButton.confirmPayment, pass methodID: type === CONST.IOU.PAYMENT_TYPE.VBBA ? methodID : undefined into payMoneyRequest, matching the existing PayPrimaryAction behavior.
6. Apply the same policy-backed option helper in useBulkPayOptions so search bulk pay can also populate additionalData.bankAccountID from policy.achAccount.

I would not change ReimbursementQueuedContent as the primary fix. That component is reflecting the server response and should still show the add-bank-account CTA when a payee really is missing a receiving bank account. The client-side fix is to avoid sending a VBBA payment without the workspace bank account ID.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add focused tests around option construction and payment dispatch:

1. Expense report with policy.achAccount open and empty BANK_ACCOUNT_LIST should expose/pay with a concrete VBBA option using policy.achAccount.bankAccountID, not the generic add/connect fallback.
2. Expense report with the same bank account in both policy.achAccount and BANK_ACCOUNT_LIST should show one de-duped business bank option.
3. Pressing the default split pay button for an expense report with a valid policy-backed VBBA should call the pay callback with paymentType: VBBA and methodID: policy.achAccount.bankAccountID.
4. PayActionButton should forward the VBBA methodID to payMoneyRequest, and payMoneyRequest should send it as bankAccountID.
5. Bulk pay should include additionalData.bankAccountID when the selected expense report policy has a valid achAccount.
6. Expense report with no valid policy.achAccount and no valid BANK_ACCOUNT_LIST business account should continue to show the add/connect bank account fallback.

What alternative solutions did you explore? (Optional)

MelvinBot correctly noticed that the queued message comes after a VBBA pay request without bankAccountID, but treating this as backend-only is too broad. App already has the policy reimbursement account, payMoneyRequest already accepts methodID and serializes it to bankAccountID, and PayPrimaryAction already forwards the ID. The missing piece is making the policy account selectable when BANK_ACCOUNT_LIST is incomplete and preserving methodID through the report-preview pay path.

My earlier proposal only covered the policy.achAccount/BANK_ACCOUNT_LIST source-of-truth mismatch. That is still necessary, but it is insufficient unless methodID is also propagated to PayMoneyRequest.

[melvin-bot]

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

[melvin-bot]

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