Expense - User can bulk edit splits to amount larger than original amount

[mitarachim]

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.21-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: #76264
Email or phone of affected tester (no customers): sjdoisjndiosjosoidjso@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:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the expense report.
5. Click More > Split > Save.
6. Select both expenses via checkbox.
7. Click dropdown button > Edit multiple.
8. Click Amount.
9. Enter amount which is larger than the original amount > Save > Save.

Expected Result:

App should not allow to proceed when the bulk edit amount is larger than the original amount.

Actual Result:

User can save the amount when the bulk edit amount is larger than the original amount.
Error shows up on both splits after saving the bulk edit.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7080980_1771379871907.13.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @laurenreidexpensify

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[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: #76264 - "Feat: bulk edit multiple" by @waterim (High confidence)
Related Issues: None

Recommendation: REVERT

The PR introduced the bulk edit feature for multiple expenses but did not implement validation to prevent split expenses from being edited to amounts larger than their parent transaction. This allows users to save invalid data that causes errors on both splits after saving.

Labels: This issue is currently labeled with both DeployBlockerCash and DeployBlocker. Since this is a frontend bug in App code (PR #76264 is in the App repository), I am keeping DeployBlockerCash and will remove DeployBlocker.

📋 Detailed Analysis

Evidence

• The issue states this is reproducible in staging but N/A for production because this is a new feature
• The melvin-bot comment explicitly identified PR Feat: bulk edit multiple #76264 as the causing PR
• The issue description clearly outlines reproduction steps involving split expenses
• Version 9.3.21-0 matches the current staging deploy checklist

Verification

The causing PR #76264 added the bulk edit feature including:

• src/pages/Search/SearchEditMultiple/SearchEditMultipleAmountPage.tsx - The amount editing page
• src/libs/actions/IOU/index.ts - Added updateMultipleMoneyRequests() function

After reviewing the code in these files:

• SearchEditMultipleAmountPage.tsx has no validation to check if selected transactions are split expenses
• SearchEditMultipleAmountPage.tsx has no validation to prevent amounts larger than the parent transaction
• updateMultipleMoneyRequests() in src/libs/actions/IOU/index.ts applies the amount change without validating split expense constraints

Root Cause

When a user creates a split expense, each split transaction references the original parent transaction via comment.originalTransactionID. Split transactions should not be allowed to have amounts greater than the parent transaction amount.

The bulk edit feature added by PR #76264 allows editing the amount field for split expenses without:

1. Checking if the selected transactions are split expenses (have originalTransactionID)
2. Validating that the new amount does not exceed the parent transaction amount
3. Recalculating or validating the sum of all split amounts against the parent

This causes the observed behavior where users can save invalid amounts, resulting in errors appearing on both splits after saving.