Split in group - Fields lead to "Not here", Split button is presented in a scan split

[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.3-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176944/test-cases/41237730
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 15.7.3 Chrome, iPhone 15 iOS 26.1
App Component: Money Requests

Action Performed:

1. Sign in to ND
2. Create a group chat with two other existing accounts, send a message in the chat
3. Split a scan expense in the group chat, uploading a valid receipt
4. When the scan is finished, open the split details
5. Click on the fields like amount, merchant, etc
6. Click "Split" button

Expected Result:

Split button is not displayed in the split details, fields are not editable

Actual Result:

Fields in the slit can be opened and lead to "Not here" RHP. Split button is shown, pressing it leads to unexpected error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @AndrewGable (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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: #79197 - "[BETA] Allow zero-amount expenses - ROUND 5" by @Gonals (High confidence)
Related Issues: None

Recommendation: REVERT

PR #79197 should be reverted as it introduces a bug that makes split expense fields incorrectly editable after scanning completes.

Labels: Keeping DeployBlockerCash (Frontend/App bug that requires an App PR fix)

Detailed Analysis

Evidence

PR #79197 was merged on 2026-01-15 13:30:11Z to add support for zero-amount expenses. However, it modified the logic in src/pages/iou/SplitBillDetailsPage.tsx on line 75:

Before:

const isEditingSplitBill = session?.accountID === actorAccountID && areRequiredFieldsEmpty(transaction) && !isDistanceRequest;

After:

const isEditingSplitBill = session?.accountID === actorAccountID && (areRequiredFieldsEmpty(transaction) || transaction?.amount === 0) && !isDistanceRequest;

This change makes split expenses with zero amount editable. However, the condition transaction?.amount === 0 is also temporarily true when a receipt is still being scanned (before SmartScan completes). When SmartScan finishes and populates the amount, the fields should become read-only, but the code now incorrectly allows editing.

Verification

• PR [BETA] Allow zero-amount expenses - ROUND 5 #79197 modified src/pages/iou/SplitBillDetailsPage.tsx (confirmed via diff)
• The change directly affects the isEditingSplitBill logic which controls whether fields are editable
• The bug symptoms match exactly: fields become editable after scan completes, leading to "Not here" RHP when clicked
• Bug is staging-only (not production), consistent with PR [BETA] Allow zero-amount expenses - ROUND 5 #79197 being merged but not yet in production

Root Cause

The condition transaction?.amount === 0 was added to allow editing zero-amount expenses (the feature PR #79197 implements). However, scanned expenses also have amount === 0 during scanning. After SmartScan completes and populates merchant/amount, the split should become read-only, but the new logic incorrectly treats it as editable because it checks both areRequiredFieldsEmpty() OR amount === 0.

The correct logic should only check areRequiredFieldsEmpty() for split bills, or add additional checks to exclude completed scans from being editable.

[AndrewGable]

cc @Gonals - But I think we can keep this because it sounds like it's behind a beta