[Due for payment 2026-04-17] [Due for payment 2026-04-16] Split scan - Amount on split details page is 0.00 despite entering a valid 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.54-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: #86958
Email or phone of affected tester (no customers): jsodinjosjdiosjndonjiso@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. Open 1:1 DM with any user.
3. Create a split scan expense with invalid receipt.
4. Click on the split preview while scanning.
5. Click Show more.
6. Click Amount.
7. Enter amount and click Save.

Expected Result:

Amount on split details page will be updated.

Actual Result:

Amount on split details page is 0.00 despite entering a valid amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7124259_1775607798180.4.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[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: #86958 - "perf: decompose MoneyRequestConfirmationList" by @OlimpiaZurek (High confidence)
Related Issues: None

Recommendation: REVERT

PR #86958 introduced a regression in how the split bill amount is read when editing a split scan expense. The fix requires reverting this App PR.

Assigned: @OlimpiaZurek (PR author), @cristipaval, @ShridharGoel, @Julesssss (approving reviewers)
Labels: DeployBlockerCash kept (frontend bug). DeployBlocker removed (no backend involvement).

Detailed Analysis

Evidence

PR #86958 ("perf: decompose MoneyRequestConfirmationList") refactored MoneyRequestConfirmationList by removing redundant props that were explicitly passed from parent components. Specifically, it removed the iouAmount prop from SplitBillDetailsPage.tsx.

Before PR #86958, SplitBillDetailsPage passed iouAmount={splitAmount ?? 0} where splitAmount came from getTransactionDetails() applied to the draft/original transaction.

After PR #86958, MoneyRequestConfirmationList derives the amount internally as: const iouAmount = transaction?.amount ?? 0;

Verification

The affected file is src/pages/iou/SplitBillDetailsPage.tsx, which is directly modified by PR #86958 (confirmed via gh pr diff). The component MoneyRequestConfirmationList is also modified.

Root Cause

The regression is caused by how the amount is stored vs. how it is now read.

When a user edits the amount on a split scan expense, setDraftSplitTransaction is called with {amount: newAmount}. Inside getUpdatedTransaction (TransactionUtils line 697), the amount change is stored as modifiedAmount on the draft transaction, NOT as amount. This is by design: the original amount reflects what the backend knows, while modifiedAmount reflects pending client-side changes.

The old code path via getTransactionDetails() called getAmount() which correctly checks hasValidModifiedAmount(transaction) and returns Math.abs(transaction.modifiedAmount) when a modified amount exists (TransactionUtils line 956-960).

The new code transaction?.amount ?? 0 bypasses this logic entirely and reads the raw transaction.amount field. Since the original scan returned an invalid receipt (amount = 0), transaction.amount is 0 even after the user enters a new value. The user-entered amount is stored only in modifiedAmount, which the new code never reads.

Result: The split details page always shows 0.00 after the user enters and saves an amount, because the display now reads the raw transaction.amount (0) instead of modifiedAmount (the user-entered value).

This bug is staging-only (not reproducible on production), consistent with this PR being a recent staging-only change.