Spend - Incorrect "Total Spend" amount displayed after splitting unreported expense.

[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.3.84-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: #84382
Email or phone of affected tester (no customers): ibellicotest+2723@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

Prerequisite: Account has Self DM.

1. Open the staging.new.expensify.com website.
2. Navigate to Self DM.
3. Create a manual expense.
4. Navigate to "Spend" > "Expenses"
5. Select the just created expense.
6. Click on dropdown menu > "Split" > Save splits amount.
7. Select one of the splits.
8. Note that "Total Spend" on footer shows an amount bigger than the one on the split.

Expected Result:

After splitting an unreported expense and selecting a split on "Expenses" section, "Total Spend" should display the same amount as the selected split.

Actual Result:

After splitting an unreported expense and selecting a split on "Expenses" section on "Spend", "Total Spend" displays an amount bigger than the one on the split.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164935_1779935210498.Total_Spend.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7164935

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[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/a5bbb0554eca617813ecbc75fd5990fc3950eca06afdef7018923ae814dbe4c2

[melvin-bot]

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

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

When an unreported expense is split, the parent transaction's reportID is set to '-2' (SPLIT_REPORT_ID). However, the client-side UNREPORTED status filter in SearchUIUtils.ts:386 only excludes TRASH_REPORT_ID ('-1'), not SPLIT_REPORT_ID ('-2'):

[CONST.SEARCH.STATUS.EXPENSE.UNREPORTED]: (expenseReport, transactionReportID) =>
    !expenseReport && transactionReportID !== CONST.REPORT.TRASH_REPORT_ID,

This allows the parent transaction (which still carries the full original amount) to pass the filter and appear alongside its child split transactions in the "Unreported" search results. When items are selected, the footer's "Total Spend" aggregates both the parent's full amount and the child's split amount, producing an inflated total.

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

Add SPLIT_REPORT_ID to the exclusion check in the UNREPORTED filter at SearchUIUtils.ts:386 so parent split transactions are filtered out of unreported expense results:

transactionReportID !== CONST.REPORT.TRASH_REPORT_ID && transactionReportID !== CONST.REPORT.SPLIT_REPORT_ID

This ensures parent transactions that have been split are no longer visible in unreported search results, preventing the double-counting in "Total Spend".

Supporting evidence

• Parent gets reportID = SPLIT_REPORT_ID at SplitTransactionUpdate.ts:1452-1458
• The optimistic update removes the parent from the search snapshot (SplitTransactionUpdate.ts:1569-1575), but after the server refreshes search results, the parent can reappear because the server-side query doesn't exclude SPLIT_REPORT_ID either
• The UNREPORTED filter at line 386 lets it through since !undefined && '-2' !== '-1' evaluates to true
• The total calculation at SearchPage.tsx sums all selected transaction amounts, double-counting when both parent and child are present

---

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.