[Due for payment 2026-04-14] Reports - Merged expense appears when filtering by "Deleted" with the kept amount.

[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.51.1
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: #85818
Email or phone of affected tester (no customers): ibellicotest+2250@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 at least one workspace.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create two different manual expenses in two different reports.
4. Open the last created expense.
5. Click on "More" > "Merge"
6. Select the first created expense.
7. Keep all the details from the first created expense and confirm.
8. Navigate to "Reports" > "Expenses"
9. Click on "Status" filter > "Deleted" > "Save"
10. Note that the merged expense appears displayed with the kept amount instead of being shown with the discarded amount.

Expected Result:

After merging expenses, the expense with the details that were discarded, should appear with the discarded amount after filtering by "Deleted" on "Reports".

Actual Result:

After merging expenses and filtering by "Deleted" status on "Reports", the expense that was discarded is displayed on results with the amount that was kept instead of showing the discarded amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #85818 - "Deleted transactions on search" by @jnowakow (High confidence)
Related Issues: None identified

Recommendation: REVERT

PR #85818 introduced the deleted transactions feature which allows filtering by "Deleted" status in search. However, the implementation has an issue where merged expenses that were discarded show the kept amount instead of the discarded amount when displayed in the deleted transactions list.

Labels: This is a Frontend bug. The issue is in the App repository code that handles displaying deleted transaction data in search results. Keeping DeployBlockerCash label as-is, since this is an App PR causing the issue.

📋 Detailed Analysis

Evidence

PR #85818 added support for deleted transactions on search by:

• Introducing TRASH_REPORT_ID constant to mark deleted transactions
• Adding "Deleted" status filter option in search
• Modifying transaction display logic to handle deleted state
• Updating changeTransactionsReport function in Transaction.ts

The bug manifests when:

1. Two expenses are merged in different reports
2. One expense is kept (target) with specific details and amount
3. The other expense is discarded (source) and marked as deleted
4. When filtering by "Deleted" status in search, the discarded expense appears with the KEPT amount instead of showing its original DISCARDED amount

Verification

The PR modifies several key files related to transaction display and status:

• src/libs/actions/Transaction.ts - Transaction movement and status updates
• src/libs/TransactionUtils/index.ts - Added isDeletedTransaction() helper
• src/libs/SearchUIUtils.ts - Added deleted status filtering logic
• src/components/Search/SearchList/ListItem/StatusCell.tsx - Display logic for deleted status
• src/libs/ReportUtils.ts - Status translation and styling for deleted transactions

The changes in Transaction.ts particularly in the changeTransactionsReport function show that when handling deleted transactions, the full transaction object is spread into the optimistic data, which may contain incorrect or stale amount information from the merge operation.

Root Cause

When expenses are merged:

1. The target transaction is updated with the chosen details (including the kept amount)
2. The source transaction is marked as deleted (reportID set to TRASH_REPORT_ID)
3. The deleted transaction data in search results is not properly preserving the original discarded amount
4. Instead, it appears to be showing data that was updated during the merge process, displaying the kept amount rather than the discarded amount

This is a data handling issue in the frontend where the deleted transaction original amount is not being preserved correctly for display in the search results.

[MelvinBot]

Proposal

What is the root cause of that problem?

When two expenses are merged via the duplicate resolution flow, the discarded (losing) transaction's amount is being overwritten with the kept (winning) transaction's amount on the backend before the discarded transaction is soft-deleted (moved to trash with reportID = '-1').

Here's the evidence chain:

1. Client-side merge flow (src/libs/actions/IOU/Duplicate.ts:110-114): The discarded transactions are optimistically SET to null in Onyx — their amounts are never modified client-side.

2. API parameters (src/libs/API/parameters/MergeDuplicatesParams.ts): The MergeDuplicates command sends a single amount field (the chosen/kept amount) along with transactionID (kept) and transactionIDList (discarded). There is no separate field to preserve the discarded transactions' original amounts.

3. Amount selection is not user-controllable (src/types/onyx/ReviewDuplicates.ts:6-42): The ReviewDuplicates type has no amount field — during duplicate review, the user can choose merchant, category, tag, etc., but amount always comes from the kept transaction via buildNewTransactionAfterReviewingDuplicates (src/libs/TransactionUtils/index.ts:2572-2582).

4. Display logic has no special handling for deleted transactions: getAmount() (src/libs/TransactionUtils/index.ts:958-984) reads modifiedAmount (if set) or amount from the transaction object. For deleted transactions (reportID = '-1'), the associated report is undefined, so isFromExpenseReport is always false. The amount shown depends entirely on what the backend stores.

5. Data source for Deleted search filter: When the user filters by "Deleted" status (src/libs/SearchUIUtils.ts:356), the search API returns transactions with reportID === '-1'. Since the client nulled out the discarded transactions during the merge, all data comes from the backend. If the backend wrote the kept amount onto the discarded transaction, that wrong amount is displayed.

In summary: The backend's MergeDuplicates command handler likely applies the chosen amount parameter to the discarded transaction(s) in addition to (or instead of only) the kept transaction, before setting their reportID to -1. When the Deleted filter retrieves these trashed transactions, they display the kept amount instead of their original amount.

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

The fix needs to happen on the backend (Auth server), in the handler for the MergeDuplicates write command:

• When processing the merge, the backend should preserve the original amount and modifiedAmount on the discarded transactions before moving them to trash (reportID = '-1'). Only the kept transaction (transactionID) should have its fields updated with the chosen values from the merge params.
• The discarded transactions (transactionIDList) should retain their pre-merge field values — they should only have their reportID changed to -1 to mark them as deleted.

If for some reason the backend needs to update the discarded transactions' amounts (e.g., for accounting reconciliation), then the frontend should be updated to store and display the original amount for deleted merged transactions. This could be done by:

1. Having the backend store the original amount in a separate field (e.g., originalAmount) on the discarded transaction, OR
2. Having the client preserve the discarded transactions' original amounts before the merge and use those for display when the Deleted filter is active.

What alternative solutions did you explore? (Optional)

• Frontend-only fix: We considered whether the client could cache the discarded transaction's original amount before the merge and display that in the Deleted filter. However, this wouldn't work because: (a) the client sets discarded transactions to null optimistically, (b) the Deleted search data comes from the backend API, and (c) there's no reliable way to associate a trashed transaction with a specific merge event purely from client data.
• Sign-handling issue: We investigated whether the isFromExpenseReport=false behavior for deleted transactions (since reportID = '-1' has no associated report) could cause sign confusion in amount display. While this changes the code path in getAmount() from -amount to Math.abs(amount), it produces the same positive display value for typical cases and doesn't explain why the kept amount appears instead of the original.

---

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.

[jnowakow]

I think it's not the bug 🤔 When we are merging transaction the surviving transaction is updated with selected details and the other transaction is removed. So in this example transaction 7.5k was picked as the transaction that should stay. 8k amount was selected so the 7.5k was changed to 8k (the transaction got updated) and the other transaction got deleted. I agree that it's a bit confusing but from technical point of view it is not a bug.
cc @luacmartins

[jnowakow]

Two recordings for reference:

one.mov

two.mov