Split expense - Expense cannot be split despite having amount on amount field

[lanitochka17]

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.44-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: #83695
Email or phone of affected tester (no customers): applausetester+jsodijsdnodsjs2i@applause.expensifail.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:

• Log in with Expensifail account.

1. Go to staging.new.expensify.com
2. Open 1:1 DM with any user.
3. Click + > Split expense > Scan.
4. Create a split scan expense.
5. Click on the split preview.
6. Click Show more.
7. On amount field, enter amount.
8. Enter merchant.
9. Click Split expense.

Expected Result:

Expense will be split because amount is present.

Actual Result:

Expense cannot be split despite having amount on amount field.
It shows "Transaction is missing fields" error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7113153_1774461329612.8.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ChavdaSachin

[melvin-bot]

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

[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: #83695 - "Manual expense flow UI refactor r1" by @ChavdaSachin (High confidence)
Related Issues: None

Recommendation: REVERT

PR #83695 introduces a new validation that incorrectly blocks split scan expenses from being submitted, even when the amount field is populated. The validation needs to exclude scan requests, but currently applies to all expense types.

Labels: No label changes made (keeping DeployBlockerCash as this is a frontend bug)

📋 Detailed Analysis

Evidence

PR #83695 added new validation logic in MoneyRequestConfirmationList.tsx (lines 1036-1042 in the current codebase):

const amountForValidation = iouAmount;
const isAmountMissingForManualFlow = amountForValidation === null || amountForValidation === undefined;

if (iouType !== CONST.IOU.TYPE.PAY && isNewManualExpenseFlowEnabled && isAmountMissingForManualFlow) {
    setFormError('common.error.invalidAmount');
    return;
}

This validation was intended for the new manual expense flow to ensure users enter an amount before submitting. However, the validation is incorrectly applied to all expense types when isNewManualExpenseFlowEnabled is true, including:

• Split scan expenses (the bug scenario)
• Regular scan expenses
• Any other non-PAY expense type

Verification

The bug reproduces exactly as described:

1. User creates a split scan expense
2. SmartScan populates the amount from the receipt
3. User can edit the amount in the amount field (amount is present)
4. When clicking "Split expense", validation on line 1039 triggers
5. Error: "Transaction is missing fields" appears despite amount being present

Files modified by PR #83695 that are relevant to this bug:

• src/components/MoneyRequestConfirmationList.tsx - Contains the faulty validation
• src/components/MoneyRequestConfirmationListFooter.tsx - Contains the new manual expense flow UI

Root Cause

The validation logic is missing a check for isScanRequest. The code should exclude scan requests from the amount validation, since scan requests get their amount from SmartScan (not from manual user entry). The validation was designed for manual expense flows where users must manually enter an amount.

The fix would be to add !isScanRequest to the validation condition:

if (iouType !== CONST.IOU.TYPE.PAY && isNewManualExpenseFlowEnabled && !isScanRequest && isAmountMissingForManualFlow)

However, since this is a deploy blocker affecting core expense functionality (split expenses), the safest approach is to revert the PR and allow the author to implement a proper fix that handles scan requests correctly.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When editing a split scan expense (on SplitBillDetailsPage), the user enters an amount and merchant, but clicking "Split expense" shows "Transaction is missing fields" error despite the fields being filled in.

What is the root cause of that problem?

PR #83695 introduced an inline amount editor (NumberWithSymbolForm) in MoneyRequestConfirmationListFooter.tsx as part of the new manual expense flow (gated by the NEW_MANUAL_EXPENSE_FLOW beta). The inline editor's handleAmountChange callback calls setMoneyRequestAmount() (src/components/MoneyRequestConfirmationListFooter.tsx:584), which writes to ONYXKEYS.COLLECTION.TRANSACTION_DRAFT (src/libs/actions/IOU/index.ts:1491).

However, in the split bill editing flow (SplitBillDetailsPage), the transaction is read from ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT (src/pages/iou/SplitBillDetailsPage.tsx:63) and passed to MoneyRequestConfirmationList (line 182). The inline amount editor writes to the wrong Onyx key (TRANSACTION_DRAFT instead of SPLIT_TRANSACTION_DRAFT), so the draft split transaction still has amount = 0.

When the user clicks "Split expense", the confirm function checks areRequiredFieldsEmpty(transaction, transactionReport) at MoneyRequestConfirmationList.tsx:1120. Since transaction is the draft from SPLIT_TRANSACTION_DRAFT (which still has amount = 0), areRequiredFieldsEmpty returns true (because getAmount(transaction) === 0 at TransactionUtils/index.ts:652), triggering the "Transaction is missing fields" error.

Before PR #83695, the amount field was a MenuItemWithTopDescription that navigated to IOURequestStepAmount, which correctly used setDraftSplitTransaction() to write to SPLIT_TRANSACTION_DRAFT when editing a split bill. The new inline editor bypasses this and writes to the wrong key.

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

In MoneyRequestConfirmationListFooter.tsx, the handleAmountChange function needs to handle the split bill editing case. When isEditingSplitBill is true, it should call setDraftSplitTransaction() (from @userActions/IOU/Split) instead of setMoneyRequestAmount(). This ensures the amount is written to SPLIT_TRANSACTION_DRAFT, matching where the validation reads from.

Specifically:

1. Pass the isEditingSplitBill prop (already available on MoneyRequestConfirmationList) down to MoneyRequestConfirmationListFooter
2. In handleAmountChange, when isEditingSplitBill is true, call setDraftSplitTransaction(transactionID, null, {amount: parsedAmount, currency}) instead of setMoneyRequestAmount
3. Apply the same fix to updateCurrency for consistency

What alternative solutions did you explore? (Optional)

An alternative would be to disable the inline amount editor when isEditingSplitBill is true (falling back to the MenuItemWithTopDescription that navigates to IOURequestStepAmount). This is simpler but would create an inconsistent UX where some flows get the new inline editor and others don't.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.