[Due for payment 2026-07-29] Please enter a valid merchant violation remains when change to IOU

[applause-bot]

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.4.41-0
Reproducible in staging?: Yes
Reproducible in production?: No
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/65568255/folder/13177049/41237809/1585991522?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+buzz1803@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Other

Action Performed:

Precondition: User have a workspace

1. Go to FAB> Create expense> Enter amount> Create expense
2. Verify "Please enter a valid merchant" violation is displayed
3. Change the receiver to user email address> Click Create expense

Expected Result:

"Please enter a valid merchant" should not persist when user does not submit expense to workspace chat

Actual Result:

"Please enter a valid merchant" persist when user creates IOU expense

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213182_1784613560644.Recording__1224.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7213182

Issue Owner

Current Issue Owner: @ikevin127

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9530d2233b97866efb89951b8498261dafb50654248b15b8b9a9248183d7766d

[melvin-bot]

Triggered auto assignment to @jasperhuangg (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.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96228 - "feat: remove isNewManualExpenseFlowEnabled beta flag" by @thelullabyy (High confidence)
Related Issues: #93854 (the tracking issue the PR was made for)

Recommendation: REVERT

This PR removed the isNewManualExpenseFlowEnabled beta flag, making the refactored "new manual expense flow" the default on staging. That flow contains the merchant-error clearing logic that fails to re-clear iou.error.invalidMerchant when the recipient switches from a workspace (merchant required) to an individual/IOU (merchant not required). The flow is still beta-gated in production, which is exactly why this reproduces on staging only. Reverting restores the beta gate and unblocks the deploy; the underlying flow can then be fixed and re-shipped.

Assigned: @thelullabyy (PR author), @joekaufmanexpensify, @ikevin127, @puneetlath (approving reviewers) from highest-confidence causing PR only
Labels: No changes. DeployBlockerCash kept (App deploy is blocked by an App PR); no DeployBlocker present.

📋 Detailed Analysis

Evidence

• Bug is reproducible on staging but NOT production (per the report). The new manual expense flow is still beta-gated in production and only became the default on staging because of this PR, so the bug surface only exists on staging — a textbook signature of this exact PR.
• PR feat: remove isNewManualExpenseFlowEnabled beta flag #96228 was merged 2026-07-20, is on the current StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-07-21 #96534), and precedes the bug report (2026-07-21).
• The PR touches precisely the affected code paths: the merchant-required computation, the confirmation validation, and participant switching.

Verification

Affected files, all modified by #96228:

• src/components/MoneyRequestConfirmationList/hooks/useFormErrorManagement.ts — owns isMerchantRequired, isMerchantFieldValid, and the effect that is supposed to clear the iou.error.invalidMerchant form error.
• src/components/MoneyRequestConfirmationList/hooks/useConfirmationValidation.ts — sets iou.error.invalidMerchant when isMerchantRequired && !isMerchantFieldValid.
• src/components/MoneyRequestConfirmationList.tsx, src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx, src/pages/iou/request/step/IOURequestStepParticipants.tsx — confirmation list + merchant field + participant switching.
• src/CONST/index.ts — removes the beta flag constant.

gh pr view 96228 --json files confirms all of the above are in the diff.

Root Cause

In useFormErrorManagement.ts:

• isMerchantRequired = isPolicyExpenseChat && (!isScanRequest || !!isEditingSplitBill) && shouldShowMerchant (line 161). Switching the recipient to an individual makes isPolicyExpenseChat false, so merchant is no longer required.
• isMerchantFieldValid returns !isMerchantRequired when the merchant value is empty (line 172), so after the switch it should become true.
• The effect at lines 211–214 is meant to clear the error: if (currentFormError === 'iou.error.invalidMerchant' && isMerchantFieldValid) setFormError('').

The error persists because that clearing effect does not reliably re-run/re-clear when only the participant changes (the merchant string itself never changes; the requirement changes). There is a dedicated effect in MoneyRequestConfirmationList.tsx (lines 399–404) that clears iou.error.noParticipantSelected on participant change, but there is no equivalent path to clear iou.error.invalidMerchant when the participant change flips the merchant-required state. So the stale merchant error set during the workspace attempt remains after switching to an IOU.

A targeted fix would clear/re-evaluate the merchant form error whenever isMerchantRequired changes (e.g. add isMerchantRequired to the clearing logic or clear iou.error.invalidMerchant in the participant-change effect). REVERT is recommended for the deploy because the flow is beta-gated in production and reverting cleanly restores that gate without risk.