Invoice - Invoice with 0 amount can be created in invoice room

[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.
• Enable Invoices in workspace settings.
• User has sent an invoice to another user.

1. Go to staging.new.expensify.com
2. Go to invoice room.
3. Click + > Send invoice.
4. Enter amount > Next.
5. On confirm page, change the amount to 0.
6. Click Send invoice.
7. Open the invoice.

Expected Result:

Invoice with 0 amount cannot be sent.

Actual Result:

Invoice with 0 amount can be sent when created from invoice room.
The created invoice with 0 amount shows these errors:

Unexpected error sending this invoice. Please try again later.Invoices must be greater than zeroUnexpected error creating this chat. Please try again later.
Unexpected error creating this chat. Please try again later.

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: None

Recommendation: REVERT

PR #87920 introduced a regression in the zero-amount validation guard for invoices sent from an invoice room. The check is scoped only to P2P transactions and does not cover the invoice type, allowing a $0 invoice to be submitted — which then fails on the backend with "Invoices must be greater than zero".

Assigned: @ChavdaSachin (PR author), @ShridharGoel @puneetlath (approving reviewers)
Labels: DeployBlockerCash kept (Frontend bug — App PR caused the regression). DeployBlocker not present, no change needed.

📋 Detailed Analysis

Evidence

• The issue is staging-only (new feature, does not exist in production) and only reproducible with the newManualExpenseFlow beta enabled.
• The melvin-bot automatically flagged PR Feat: Manual expense flow UI refactor - r3 #87920 as the likely cause.
• PR Feat: Manual expense flow UI refactor - r3 #87920 was merged 2026-05-13 and appears in the current StagingDeployCash checklist (unchecked).
• The bug manifests on the confirm page when the user edits the amount to 0 and submits — the API then rejects it with "Invoices must be greater than zero".

Verification

• Affected file: src/components/MoneyRequestConfirmationList/hooks/useConfirmationValidation.ts
• PR Feat: Manual expense flow UI refactor - r3 #87920 directly modifies this file (confirmed via gh pr view 87920 --json files).
• The PR rewrote the zero-amount validation logic in useConfirmationValidation.ts.

Root Cause

Before this PR, zero-amount validation was more broadly applied. The PR replaced it with:

const isP2P = !!(
  firstParticipant?.accountID && !firstParticipant?.isPolicyExpenseChat
);
if (
  iouType !== CONST.IOU.TYPE.PAY &&
  !isScanRequestUtil(transaction) &&
  !isTimeRequest &&
  !isDistanceRequest &&
  iouAmount === 0 &&
  isP2P
) {
  return { errorKey: "common.error.invalidAmount" };
}

When sending an invoice from an invoice room, getMoneyRequestParticipantsFromReport builds the participant as {reportID: chatReport?.reportID, selected: true} — with no accountID and no isPolicyExpenseChat field. This makes isP2P evaluate to false, so the iouAmount === 0 guard never fires for invoice participants. The second guard (isNewManualExpenseFlowEnabled && !transaction?.isAmountSet) also does not catch this case: once the user types 0 into the amount field, isAmountSet is set to true, so that check passes. The $0 invoice is then sent to the API which correctly rejects it, but the rejection surfaces as confusing error messages ("Unexpected error sending this invoice" / "Invoices must be greater than zero") rather than a clean client-side validation error blocking the submission.

The fix needs to extend the zero-amount guard to also cover iouType === CONST.IOU.TYPE.INVOICE, or revert this PR and re-land with the fix included.