[Due for payment 2026-03-30] Reports - After creating expense and selecting expense, footer shows $0.00

[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.39-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: #84910
Email or phone of affected tester (no customers): sjdoisjoisdjonsnjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Create a workspace.
3. Go to Reports > Expenses.
4. Open FAB > Create expense > Manual.
5. Create a manual expense.
6. Select the expense from Step 5 on Reports > Expenses via checkbox.

Expected Result:

Footer will show the expense amount.

Actual Result:

Footer shows $0.00.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7105274_1773751809725.1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

[melvin-bot]

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

[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

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

When a user selects an expense via checkbox on the Reports > Expenses search page, the footer shows $0.00 instead of the actual expense amount.

What is the root cause of that problem?

The footer total in src/pages/Search/SearchPage.tsx:121 is calculated using groupAmount:

selectedTransactionItems.reduce((acc, transaction) => acc - (transaction.groupAmount ?? 0), 0)

groupAmount is an optional backend-provided field on transactions (defined at src/types/onyx/Transaction.ts:487) that represents the amount converted to the group/policy currency. It is only returned by the backend when shouldCalculateTotals=true is sent with the search request.

The default "Expenses" search key (CONST.SEARCH.SEARCH_KEYS.EXPENSES) is not included in the eligible search keys in src/hooks/useSearchShouldCalculateTotals.ts:19-33 — only keys like submit, approve, pay, export, etc. are eligible. So for the default Expenses search, shouldCalculateTotals=false, the backend does not populate groupAmount, and groupAmount ?? 0 evaluates to 0 for every selected transaction, resulting in a $0.00 total.

Meanwhile, the always-available amount field on SelectedTransactionInfo (set at src/components/Search/index.tsx:140) is never used by the footer calculation.

Additionally, PR #84910 changed the post-expense-creation navigation from Navigation.dismissModal() (which returns to the user's original search view) to Navigation.revealRouteBeforeDismissingModal(SEARCH_ROOT.getRoute({query})) (which navigates to a new generic search). This may cause the user to land on a search context where this issue is more reliably triggered.

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

In src/pages/Search/SearchPage.tsx:121, the footer total calculation should fall back to the amount field when groupAmount is not available:

// Before:
acc - (transaction.groupAmount ?? 0)

// After:
acc - (transaction.groupAmount ?? transaction.amount ?? 0)

Note: groupAmount is the currency-converted amount (signed negative for expenses), while amount is the raw transaction amount. The sign handling may need to match — verify that subtracting amount yields the correct positive total, and consider using Math.abs(transaction.amount) or negating it depending on the sign convention.

What alternative solutions did you explore? (Optional)

1. Add EXPENSES to eligibleSearchKeys in useSearchShouldCalculateTotals.ts — this would cause the backend to always compute groupAmount for default expense searches, but increases backend load for a common search type and may not be desirable.

2. Revert the navigation change in PR [Metrics] Optimize submit-to-Search navigation performance #84910 to use dismissModal() on wide layout — this would avoid navigating to a fresh search context, but doesn't fix the underlying issue that the footer can't display correct totals when groupAmount is missing.

---

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.