[Due for payment 2026-03-30] [Auth Next Steps] [$250] Expense - "Waiting for you to pay expense" displays on workspace disabled payments

[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.27-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-7047/folder/13176705/41236830/1218708216
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a collect workspace setting Submissions: Weekly, enable Approvals and Payments, add bank account Plaid Saving Ending in 1111
• Invite an employee to workspace

1. Open https://staging.new.expensify.com
2. Admin go to workspace setting disable Payments
3. Employee create and submit a manual expense to workspace
4. Admin navigate to the employee report
5. Admin click on report and approve
6. Admin observe the hour glass message
7. Employee click on expense report and observe the hour glass message

Expected Result:

Verify the hour glass message mention that it's "Finished" - no further action is needed

Actual Result:

On admin side, the hour glass message mention that "Waiting for you to pay expenses". On employee, the hour glass message mention that "Waiting for you to add a 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

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @s77rt

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022027671505312651100
• Upwork Job ID: 2027671505312651100
• Last Price Increase: 2026-02-28

[melvin-bot]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @marcaaron (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug (logic flaw in App codebase)
Causing PR: No specific PR - this is an existing logic bug in /src/libs/NextStepUtils.ts
Root Cause: The nextStep logic for APPROVED status does not properly handle the case when workspace payments are disabled

Recommendation: ROLL FORWARD

The issue is in the buildOptimisticNextStep() function in NextStepUtils.ts (lines 236-248). When a report reaches APPROVED status, the code checks hasValidAccount to determine whether to show "Waiting to pay" or "Waiting for bank account" messages. However, it does not check whether payments are actually enabled on the workspace.

The current logic (line 102):

const hasValidAccount = !!policy?.achAccount?.accountNumber || policy?.reimbursementChoice !== CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES;

When reimbursementChoice is REIMBURSEMENT_NO (payments disabled), hasValidAccount evaluates to true, which causes line 244 to show WAITING_TO_PAY instead of NO_FURTHER_ACTION.

Fix needed: In the APPROVED case (line 236), add a check for whether payments are disabled. If policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO, return nextStepNoActionRequired immediately.

This is a straightforward logic fix that should be rolled forward rather than attempting to revert non-existent causing PR.

Labels: No label changes - keeping DeployBlockerCash as this is a frontend App issue requiring a fix in the App codebase.

Detailed Analysis

Evidence

Looking at the code in /src/libs/NextStepUtils.ts, the APPROVED status handler (lines 236-248) does not check if payments are disabled before showing payment-related messages. The bug manifests differently for different users:

• Admin (who is a payer): sees "Waiting for you to pay expenses"
• Employee (not a payer): sees "Waiting for you to add a bank account"

Both messages are incorrect when payments are disabled - it should show "Finished - no further action required".

Verification

The affected code is in /src/libs/NextStepUtils.ts lines 236-248. This file handles the optimistic nextStep generation for all report statuses. No recent PR modified this specific logic for the APPROVED status case.

Root Cause

The hasValidAccount calculation on line 102 was designed to be true when either:

1. A bank account exists, OR
2. Reimbursement choice is NOT "Yes" (direct reimbursement)

However, this creates a bug: when payments are disabled (REIMBURSEMENT_NO), hasValidAccount is true, causing the APPROVED case to show "Waiting to pay" instead of "No further action required". The logic should first check if payments are enabled at all before determining what payment message to show.

[MelvinBot]

Proposal

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

When an admin disables Payments on a collect workspace (with Approvals enabled), then an employee submits an expense and the admin approves it, the hourglass message incorrectly shows:

• Admin side: "Waiting for you to pay expenses"
• Employee side: "Waiting for you to add a bank account"

The expected behavior is that the message should indicate "Finished" / "No further action required" since there is no payment step when Payments are disabled.

What is the root cause of that problem?

The root cause has two layers:

1. Backend overwrites correct frontend optimistic data: The frontend's buildOptimisticNextStep and buildNextStepNew in NextStepUtils.ts correctly return "No further action required" for the APPROVED status when payments are disabled, because isPayer() (ReportUtils.ts:2790) returns false when reimbursementChoice === REIMBURSEMENT_NO on paid group policies. However, the approveMoneyRequest success handler (IOU/index.ts:10709-10720) does not set the NEXT_STEP collection value on success — it only clears pendingFields. This means the server response overwrites the correct optimistic "No further action required" with incorrect "Waiting for you to pay expenses" messages, because the backend's BuildNextStep logic doesn't account for payments being disabled.

2. Frontend lacks explicit arePaymentsEnabled check in NextStepUtils: While isPayer() serves as an indirect proxy that works for the APPROVED case, NextStepUtils.ts never imports or checks arePaymentsEnabled() (PolicyUtils.ts:855). This is a fragile design — the pay buttons are correctly hidden throughout the codebase via arePaymentsEnabled checks in ReportPrimaryActionUtils, ReportSecondaryActionUtils, and ReportPreviewActionUtils, but the hourglass message system relies solely on isPayer() to implicitly handle the payments-disabled case. Additionally, the SUBMITTED + Submit-and-Close (OPTIONAL) case at NextStepUtils.ts:202-204 always shows "Waiting to pay" without any payments-enabled check.

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

Add explicit arePaymentsEnabled(policy) checks in NextStepUtils.ts for both buildOptimisticNextStep and buildNextStepNew:

1. APPROVED case (NextStepUtils.ts:236-248 and NextStepUtils.ts:762-798): When !arePaymentsEnabled(policy), return nextStepNoActionRequired / noActionRequired immediately, before reaching the isPayer() check. This serves as a defensive frontend fix that prevents the backend from overwriting with incorrect data.

2. SUBMITTED + OPTIONAL case (NextStepUtils.ts:202-204 and the deprecated equivalent): When !arePaymentsEnabled(policy), return nextStepNoActionRequired instead of nextStepFixOrPayExpense.

3. Backend fix: The server-side BuildNextStep logic should also be updated to check reimbursementChoice and return "No further action required" when payments are disabled on the workspace. This ensures both the optimistic and final server-driven values are correct.

4. Add test coverage in NextStepUtilsTest.ts for the APPROVED state with reimbursementChoice = REIMBURSEMENT_NO — there is currently no test for this scenario.

What alternative solutions did you explore? (Optional)

• Success handler override: Considered adding the correct nextStep value to successData in approveMoneyRequest to prevent server overwrite. This would work but is less clean — the fix belongs in the nextStep computation logic itself.
• Relying solely on isPayer(): The current approach already works for the optimistic update, but it's fragile and doesn't prevent the backend from overwriting with incorrect data.

Detailed Investigation

Root Cause Analysis

Data flow during expense approval:

1. Admin clicks Approve → approveMoneyRequest() called (IOU/index.ts:10564)
2. predictedNextStatus = APPROVED when no next approver (IOU/index.ts:10596)
3. Both buildNextStepNew and buildOptimisticNextStep called with predictedNextStatus=APPROVED
4. Both check isPayer(currentUser, report, undefined) in APPROVED case
5. isPayer() checks reimbursementChoice on policy → returns false for REIMBURSEMENT_NO (ReportUtils.ts:2790)
6. Both return "No further action required" optimistically ✅
7. Optimistic data stored in both report.nextStep (new format) and ONYXKEYS.COLLECTION.NEXT_STEP (deprecated format)
8. successData does NOT update NEXT_STEP collection — only clears pendingFields (IOU/index.ts:10709-10720)
9. Server response via onyxData overwrites the optimistic value with incorrect "pay expenses" message ❌

Why the employee sees "add a bank account": The employee's Onyx store is never updated optimistically — only via server-pushed Pusher events. The backend generates per-user personalized messages, sending "Waiting for you to pay expenses" to the admin and "Waiting for you to add a bank account" to the employee.

Evidence Chain

• arePaymentsEnabled is used in 10+ locations for pay button visibility but NOT in NextStepUtils
• isPayer() at ReportUtils.ts:2771-2790 correctly returns false for REIMBURSEMENT_NO on paid group policies
• Frontend optimistic logic is correct for APPROVED case (verified in both buildOptimisticNextStep and buildNextStepNew)
• successData in approveMoneyRequest does not include NEXT_STEP update, letting the server dictate final value
• Employee's message "add a bank account" doesn't match any frontend message format, confirming it originates from the backend

Relevant Code

• App/src/libs/NextStepUtils.ts:236-248 - New format APPROVED case (needs arePaymentsEnabled check)
• App/src/libs/NextStepUtils.ts:762-798 - Deprecated format APPROVED case (needs arePaymentsEnabled check)
• App/src/libs/NextStepUtils.ts:202-204 - SUBMITTED+OPTIONAL case (missing payments check)
• App/src/libs/ReportUtils.ts:2739-2793 - isPayer() function that serves as indirect proxy
• App/src/libs/PolicyUtils.ts:855-857 - arePaymentsEnabled() utility not used in NextStepUtils
• App/src/libs/actions/IOU/index.ts:10564-10720 - approveMoneyRequest with optimistic/success data
• App/src/components/MoneyReportHeader.tsx:222,532,1897 - UI rendering of nextStep
• App/tests/unit/NextStepUtilsTest.ts:891-966 - Missing test for APPROVED with REIMBURSEMENT_NO

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.