Expense - Invalid amount error does not show up when amount is 0 when paying user

[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.74-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87920
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.

1. Go to staging.new.expensify.com
2. Open DM with any user.
3. Click + > Pay.
4. Enter amount > Next.
5. On confirm page, change the amount to 0.
6. Click Mark as paid.

Expected Result:

Invalid amount error will show up because amount is 0.

Actual Result:

Invalid amount error does not show up when amount is 0 when paying user.

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

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #87920

[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
Causing PR: #87920 - "Feat: Manual expense flow UI refactor - r3" by @ChavdaSachin (High confidence)
Related Issues: #82586

Recommendation: REVERT

PR #87920 introduced a regression in the amount validation for the PAY flow (the "Mark as paid" path). The zero-amount guard in useConfirmationValidation.ts explicitly excludes iouType === CONST.IOU.TYPE.PAY, so when a user changes the amount to 0 on the confirm page and clicks "Mark as paid", no invalid-amount error is raised.

Assigned: @ChavdaSachin (PR author), @ShridharGoel and @puneetlath (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR caused this). No label changes made.

Detailed Analysis

Evidence

• The melvin-bot already identified PR Feat: Manual expense flow UI refactor - r3 #87920 as the causing PR (it was auto-assigned to the PR author).
• The issue is only reproducible on staging (version 9.3.74-0) and not production — this is a new feature (newManualExpenseFlow beta), confirming the bug was introduced by this PR.
• PR Feat: Manual expense flow UI refactor - r3 #87920 is the manual expense flow UI refactor that added inline amount editing directly on the confirmation page.

Verification

• Affected file: src/components/MoneyRequestConfirmationList/hooks/useConfirmationValidation.ts
• PR Feat: Manual expense flow UI refactor - r3 #87920 directly modifies this file.
• The PR rewrote the amount validation logic at lines 162-168 of the current file.

Root Cause

In useConfirmationValidation.ts, the zero-amount guard added by the PR reads:

// P2P manual submit: $0 is invalid unless scan/time/distance
if (iouType !== CONST.IOU.TYPE.PAY && !isScanRequestUtil(transaction) && !isTimeRequest && !isDistanceRequest && iouAmount === 0 && isP2P) {
    return {errorKey: 'common.error.invalidAmount'};
}

The iouType !== CONST.IOU.TYPE.PAY condition explicitly skips zero-amount validation for the Pay/Send Money flow. When the user opens a DM, clicks + > Pay, sets an amount, navigates to the confirm page, changes the amount to 0, and clicks "Mark as paid", the iouType is PAY so the guard above is bypassed entirely. The second guard (!transaction?.isAmountSet) also does not catch this because the user explicitly set the amount (to 0), so isAmountSet is true. As a result, no validation error is shown and the payment proceeds with an invalid $0 amount.