[Due for payment 2026-08-07] Expense - Unreported split is not reverted after submitting it to IOU report and deleting it

[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): sdjsodnjiodsjsoinj1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual expense.
4. Open the expense.
5. Click More > Split > Save.
6. Open any split.
7. Click on the header.
8. Click Submit it to someone.
9. Enter email and select user.
10. On confirm page, click Create expense.
11. Delete the expense from Step 10.
12. Go to self DM.
13. Open the remaining split
14. Click Amount.

Expected Result:

The remaining split will be reverted. Regular amount editor page will open.

Actual Result:

The remaining split is not reverted. Amount field opens split page after the other split in IOU report is deleted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164587_1779909560600.15.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7164587

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/562059fdb179d0d78b62e20428fbb554b83e074143a4547b4749eacb36802b2b

[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

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

When a user splits an unreported expense in their self DM, submits one split to an IOU report ("Submit it to someone"), and then deletes that submitted split, the remaining split is not reverted back to a regular expense. It stays as a split with the "Split" label on the amount field.

What is the root cause of that problem?

The root cause is in isExpenseSplit(). When a split child transaction is on a report, this function checks if the report type is 'expense':

if (isAddedToReport) {
    const report = getReportOrDraftReport(transaction.reportID);
    if (report && report.type !== CONST.REPORT.TYPE.EXPENSE) {
        return false;
    }
}

When a split child is submitted to an individual person, it creates an IOU report (type 'iou'). Since 'iou' !== 'expense', isExpenseSplit() returns false. This causes useDeleteTransactions to classify the transaction as a non-split transaction and route it to deleteMoneyRequest (which has no split-revert awareness) instead of through updateSplitTransactions → REVERT_SPLIT_TRANSACTION.

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

Modify the report type check in isExpenseSplit() to also accept IOU reports. Change:

if (report && report.type !== CONST.REPORT.TYPE.EXPENSE) {

to:

if (report && report.type !== CONST.REPORT.TYPE.EXPENSE && report.type !== CONST.REPORT.TYPE.IOU) {

This ensures that when a split child lives on an IOU report, it's still recognized as an expense split, so the delete flow correctly enters the split revert path via updateSplitTransactions → REVERT_SPLIT_TRANSACTION.

Investigation details

Data flow of the bug:

1. User splits expense in self DM → creates original + 2 child transactions (each with comment.originalTransactionID and comment.source='split')
2. User submits one split child to a person → child's reportID changes to the IOU report (type 'iou')
3. User deletes the submitted split → useDeleteTransactions calls isExpenseSplit() → returns false because report type is 'iou'
4. Transaction classified as non-split → deleteMoneyRequest() called directly → no revert
5. Remaining split child in self DM is orphaned

The revert logic itself is correct — in SplitTransactionUpdate.ts:202-204, isReverseSplitOperation correctly detects when only 1 split child remains and triggers REVERT_SPLIT_TRANSACTION. The issue is purely that the transaction never reaches this code path due to the isExpenseSplit gate.

Related issues:

• [$250] Web - Expense - Amount field still displays “Split” after reverting a previously approved #91749 — Amount field still displays "Split" after reverting a previously approved split (likely same root cause family)
• [$250] Workspace chat - Unable to split a reverted split transaction after deleting the unreported split transaction #91105 — Unable to split a reverted split transaction after deleting the unreported split transaction

---

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.