[Due for payment 2026-07-13] [$250] Expense - Expense with negative amount can be submitted to user from self DM

[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.17-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: #94134
Email or phone of affected tester (no customers): sdjnoisdjdosijsonssjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create an expense with negative amount.
4. Click Submit it to someone.
5. Enter email and select user.
6. Click Create expense.

Expected Result:

In Step 5, user will not show up in participant list when amount is negative.

Actual Result:

In Step 5, user shows up in participant list when amount is negative.
In Step 6, expense with negative amount can be submitted to user which leads to error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188089_1782171704542.18.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7188089

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071912663866744248
• Upwork Job ID: 2071912663866744248
• Last Price Increase: 2026-06-30
• Automatic offers:
• thelullabyy | Reviewer | 111872341

[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/25c70b2572cf40abc6896b1bb259ee18718060ef64b4cc2977767a469da5d5cd

[melvin-bot]

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

[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]

Proposal

What is the root cause of that problem?

The negative-amount → P2P guard is only wired into the amount-entry path, never into the confirmation validation. So when a participant is selected after a negative amount is already entered (the "Submit it to someone" flow from a self DM), nothing re-checks the sign before "Create expense".

Walking the repro:

1. From a self DM, a negative-amount expense is created as a track expense.
2. "Submit it to someone" opens the inline participant picker, and selecting a user runs handleParticipantsAdded — it flips iouType to CREATE and writes the participant, but does no negative-amount check. The picker itself does no amount filtering, so the P2P user shows up in the list (the reported "Step 5" symptom).
3. "Create expense" runs useConfirmationValidation. It has a P2P guard, but only for zero amounts (line 169: iouAmount === 0 && isP2P). The money-amount check on line 183 passes allowNegative = true, so a negative amount passes validation and is submitted to the P2P user → backend error.

The only existing negative-P2P guard lives in AmountSubmission.ts:474-482, which runs only when returning from confirmation through the amount step — a path this flow never hits.

This surfaced as a deploy blocker after PR #94134 removed the isNewManualExpenseFlowEnabled beta and deleted the old standalone amount page, making everyone rely on the embedded confirmation flow whose validation has the gap above.

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

Extend the existing P2P guard in useConfirmationValidation.ts:169 to reject negative amounts too, not just zero — i.e. change the P2P condition from iouAmount === 0 to iouAmount <= 0 (scan/time/distance are already excluded by that same guard). This blocks "Create expense" for a negative amount sent to a P2P participant regardless of how the participant was selected, returning the existing common.error.invalidAmount.

Optionally, also guard handleParticipantsAdded so a P2P participant can't be assigned to a negative-amount transaction in the first place (mirroring the resetToDefaultWorkspace behavior in AmountSubmission.ts), so the user is stopped at selection rather than at submit.

What alternative solutions did you explore? (Optional)

Reverting PR #94134 would un-block the deploy, but the underlying gap (validation never checks negative + P2P) predates it conceptually, so a targeted validation fix is preferable.

Confidence & verification notes

Confidence: Medium-High. The data flow is fully traced through code: validation explicitly passes allowNegative = true for the P2P submit branch and the inline picker handler has no negative guard. Not yet verified at runtime: the exact backend error string returned on negative-P2P submit (a browser repro would confirm the downstream failure, but isn't needed to locate the missing guard).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94261) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.