[$250] Web - Expense - Amount field still displays “Split” after reverting a previously approved

[lanitochka17]

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: undefined
Reproducible in staging?: Yes
Reproducible in production?: undefined
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

Preconditions: Logged in to any account

Steps:

1. Go to workspace chat
2. Create an expense.
3. Open the expense report.
4. Click More > Split > Save.
5. Open any split.
6. Click Report.
7. Click Create report.
8. On the current split, click Submit and Approve.
9. Open the split which is moved to a new report from Step 7.
10. Click Amount.
11. Click on the highlighted split > click Remove split > Save.
12. Open the approved report from Step 8.
13. Click More > Unapprove.
14. Click More > splits.
15. Add a new split and save it.
16. Open the new split from Step 16.
17. Click Amount.
18. Click on the highlighted split (the current split).
19. Click Remove split > Save.

Expected Result:

"Amount" field no longer shows "Split" indicator

Actual Result:

amount has split indicator

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7140868_1777453241429.amount_split.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059348318856477553
• Upwork Job ID: 2059348318856477553
• Last Price Increase: 2026-05-26

Issue Owner

Current Issue Owner: @tylerkaraszewski

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Split" indicator on the Amount field is controlled by shouldShowSplitIndicator which is true when isExpenseSplit && (hasMultipleSplits || isReportOpen).

After the approve → unapprove → add split → remove split flow, the reverse split operation (which would clean up split markers) fails to trigger. This is because hasEditableSplitExpensesLeft requires statusNum < SUBMITTED, but after unapproval the split expense's statusNum (populated from the report's statusNum) may still be >= SUBMITTED, blocking the reverse split at line 166-167.

Without the reverse split, the remaining child transaction keeps its comment.source === 'split' and comment.originalTransactionID markers, so isExpenseSplit stays true. Combined with isReportOpen being true after unapproval, the split indicator persists even though only one transaction remains.

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

The hasEditableSplitExpensesLeft check in SplitTransactionUpdate.ts:164 should account for the unapproved state. After unapproval, the report is open and editable, so the reverse split should be allowed. The condition should be relaxed to also consider the report's current open state — if the report has been unapproved (is open), the split expenses should be treated as editable regardless of the statusNum carried on the split expense items.

Alternatively, the statusNum populated in SplitExpenseItems.ts:100 should correctly reflect the report's post-unapproval state so it doesn't carry a stale >= SUBMITTED value.

What alternative solutions did you explore? (Optional)

An alternative would be to change the shouldShowSplitIndicator logic in MoneyRequestView.tsx:356 to require hasMultipleSplits when the report is open and there's only one child. However, this would be a symptom-level fix — the real issue is that the reverse split operation should trigger and properly clean up the split markers.

Related issue

• [$250] Workspace chat - Unable to split a reverted split transaction after deleting the unreported split transaction #91105 — Similar split reversion issues after deleting split transactions

---

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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-26 19:04:42 UTC.

Proposal

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

After the user splits an expense, approves the report containing one of the splits, unapproves that report, and then reverts back to a single split via "Remove split > Save", the Amount field on the resulting transaction continues to show the "Split" indicator. The expected behavior is for the indicator to disappear because the expense is no longer a split.

What is the root cause of that problem?

The write path that drives "Remove split > Save" calls updateSplitTransactions in src/libs/actions/IOU/SplitTransactionUpdate.ts. That function decides between two completely different write strategies based on isReverseSplitOperation. When true, it calls REVERT_SPLIT_TRANSACTION, deletes every child, and reverts the original transaction back to a regular non-split expense. When false, it calls UPDATE_SPLIT_TRANSACTION, keeps the surviving child wired as a split child (comment.source = 'split'), and the "Split" indicator persists.

isReverseSplitOperation is gated by hasEditableSplitExpensesLeft at line 164:

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 163 to 167 in abfab70

	const isCreationOfSplits = originalChildTransactions.length === 0;
	const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
	// Don't revert split if there are orphaned children (reportID '0') - they're still part of the split
	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

hasEditableSplitExpensesLeft checks (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED, meaning only OPEN (0) qualifies. After step 13 ("Unapprove"), the report transitions from APPROVED (3) to SUBMITTED (1) — not back to OPEN. So the surviving split has statusNum === 1, the check (1 < 1) is false, hasEditableSplitExpensesLeft is false, and isReverseSplitOperation falls to false. The system takes the UPDATE_SPLIT_TRANSACTION branch, which never clears comment.source/comment.originalTransactionID, so isExpenseSplit stays true and the indicator persists.

The same overly-strict threshold exists in three places:

• SplitTransactionUpdate.ts line 164 (inside updateSplitTransactions)
• SplitTransactionUpdate.ts line 1367 (inside updateSplitTransactionsFromSplitExpensesFlow)
• useDeleteTransactions.ts line 201 (gates whether bulk-delete-of-splits triggers the revert path)

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1367 to 1369 in abfab70

	const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

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

Change the hasEditableSplitExpensesLeft predicate in all three locations from < CONST.REPORT.STATUS_NUM.SUBMITTED to < CONST.REPORT.STATUS_NUM.CLOSED. This makes both OPEN (0) and SUBMITTED (1) qualify as editable, while CLOSED (2), APPROVED (3), and REIMBURSED (4) remain non-editable. This aligns with the parallel guard in isSplitAction which uses report.statusNum >= CONST.REPORT.STATUS_NUM.CLOSED to disallow splits — both checks now agree on which states are workable.

With the fix, the post-unapprove SUBMITTED split correctly qualifies, isReverseSplitOperation triggers, REVERT_SPLIT_TRANSACTION is called, the original transaction is reverted (clearing comment.source and comment.originalTransactionID), and the "Split" indicator disappears.

What alternative solutions did you explore? (Optional)

Forcing comment.source and comment.originalTransactionID to null in the non-reverse optimistic data (lines 1077-1084) was considered. Rejected because it would mask the underlying bug — the wrong API command (UPDATE_SPLIT_TRANSACTION) would still be issued, server-side state would diverge from the client, and the unapprove-then-revert scenario would remain misclassified for snapshot cleanup, hold migration, and the isLastTransactionInReport navigation logic that all branch on isReverseSplitOperation.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-26 19:21:29 UTC.

Proposal

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

After a split expense goes through the approved/unapproved flow, removing the last added split from the split editor can leave the remaining expense's Amount row showing Split. At that point the user has reduced the active split list back to a single expense, so the Amount row should no longer describe it as a split.

What is the root cause of that problem?

The Amount row is only reflecting the transaction state it receives. MoneyRequestView derives isExpenseSplit from comment.originalTransactionID / comment.source === 'split', then appends the Split label when isExpenseSplit && (hasMultipleSplits || isReportOpen) is true:

App/src/libs/TransactionUtils/index.ts

Lines 2716 to 2735 in 9573a6c

	function isExpenseSplit(transaction: OnyxEntry<Transaction>, originalTransaction?: OnyxEntry<Transaction>): boolean {
	const isAddedToReport = !!transaction?.reportID && transaction.reportID !== CONST.REPORT.SPLIT_REPORT_ID && transaction.reportID !== CONST.REPORT.UNREPORTED_REPORT_ID;
	if (isAddedToReport) {
	const report = getReportOrDraftReport(transaction.reportID);
	if (report && report.type !== CONST.REPORT.TYPE.EXPENSE) {
	return false;
	}
	}
	if (!originalTransaction) {
	return !!transaction?.comment?.originalTransactionID && transaction?.comment?.source === 'split';
	}
	const {originalTransactionID, source, splits} = transaction?.comment ?? {};
	if ((splits && splits.length > 0) || !originalTransactionID || source !== CONST.IOU.TYPE.SPLIT) {
	return false;
	}
	return !originalTransaction?.comment?.splits;
	}

App/src/libs/TransactionUtils/index.ts

Lines 2745 to 2758 in 9573a6c

	const getOriginalTransactionWithSplitInfo = (transaction: OnyxEntry<Transaction>, originalTransaction: OnyxEntry<Transaction>) => {
	const {originalTransactionID, source, splits} = transaction?.comment ?? {};
	if (splits && splits.length > 0) {
	return {isBillSplit: true, isExpenseSplit: false, originalTransaction: originalTransaction ?? transaction};
	}
	if (!originalTransactionID || source !== CONST.IOU.TYPE.SPLIT) {
	return {isBillSplit: false, isExpenseSplit: false, originalTransaction: transaction};
	}
	// To determine if it’s a split bill or a split expense, we check for the presence of `comment.splits` on the original transaction.
	// Since both splits use `comment.originalTransaction`, but split expenses won’t have `comment.splits`.
	return {isBillSplit: !!originalTransaction?.comment?.splits, isExpenseSplit: isExpenseSplit(transaction, originalTransaction), originalTransaction: originalTransaction ?? transaction};

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 351 to 356 in 9573a6c

	const [originalTransaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${getNonEmptyStringOnyxID(transaction?.comment?.originalTransactionID)}`);
	const {isExpenseSplit} = getOriginalTransactionWithSplitInfo(transaction, originalTransaction);
	const [transactionReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${transaction?.reportID}`);
	const hasMultipleSplits = useHasMultipleSplitChildren(transaction?.comment?.originalTransactionID);
	const isReportOpen = isOpenReport(moneyRequestReport);
	const shouldShowSplitIndicator = isExpenseSplit && (hasMultipleSplits || isReportOpen);

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 574 to 575 in 9573a6c

	if (shouldShowSplitIndicator) {
	amountDescription += ` ${CONST.DOT_SEPARATOR} ${translate('iou.split')}`;

The split editor itself builds the visible split list from getChildTransactions(...) without includeOrphaned, so orphaned children with reportID === CONST.REPORT.UNREPORTED_REPORT_ID are hidden from the user and are not sent in the saved splitExpenses payload:

App/src/pages/iou/SplitExpensePage.tsx

Lines 164 to 168 in 9573a6c

	const childTransactions = getChildTransactions(allTransactions, allReports, transactionID);
	const splitFieldDataFromChildTransactions = childTransactions.map((childTransaction) => {
	const childTransactionReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${childTransaction?.reportID}`];
	return initSplitExpenseItemData(childTransaction, childTransactionReport, {isManuallyEdited: true});
	});

App/src/pages/iou/SplitExpensePage.tsx

Lines 291 to 300 in 9573a6c

	updateSplitTransactionsFromSplitExpensesFlow({
	allTransactionsList: allTransactions,
	allReportsList: allReports,
	allReportNameValuePairsList: allReportNameValuePairs,
	allSnapshots,
	transactionData: {
	reportID: draftTransaction?.reportID ?? String(CONST.DEFAULT_NUMBER_ID),
	originalTransactionID: draftTransaction?.comment?.originalTransactionID ?? String(CONST.DEFAULT_NUMBER_ID),
	splitExpenses,
	splitExpensesTotal: draftTransaction?.comment?.splitExpensesTotal ?? 0,

App/src/libs/TransactionUtils/index.ts

Lines 2782 to 2798 in 9573a6c

	/**
	* Retrieves all "child" transactions associated with a given original transaction.
	* By default excludes orphaned transactions (reportID '0'). Use includeOrphaned=true for counting.
	*/
	function getChildTransactions(transactions: OnyxCollection<Transaction>, reports: OnyxCollection<Report>, originalTransactionID: string | undefined, includeOrphaned = false) {
	return Object.values(transactions ?? {}).filter((currentTransaction) => {
	const isSplitChild = currentTransaction?.comment?.originalTransactionID === originalTransactionID;
	if (!isSplitChild || currentTransaction?.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	return false;
	}
	const isOrphaned = currentTransaction?.reportID === CONST.REPORT.UNREPORTED_REPORT_ID;
	if (isOrphaned) {
	return includeOrphaned;
	}
	const currentReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${currentTransaction?.reportID}`];
	return !!currentReport || currentTransaction?.comment?.source === CONST.IOU.TYPE.SPLIT;
	});

But the save path decides whether to call REVERT_SPLIT_TRANSACTION using an orphan-inclusive child list. In updateSplitTransactions(), allChildTransactions is fetched with includeOrphaned = true, and isReverseSplitOperation requires allChildTransactions.length === originalChildTransactions.length. The same predicate is duplicated in updateSplitTransactionsFromSplitExpensesFlow():

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 156 to 167 in 9573a6c

	// Get all children once (including orphaned), then filter for non-orphaned
	const allChildTransactions = getChildTransactions(allTransactionsList, allReportsList, originalTransactionID, true);
	const originalChildTransactions = allChildTransactions.filter((tx) => tx?.reportID !== CONST.REPORT.UNREPORTED_REPORT_ID);
	const processedChildTransactionIDs: string[] = [];
	const splitExpensesTotal = transactionData?.splitExpensesTotal ?? 0;
	const isCreationOfSplits = originalChildTransactions.length === 0;
	const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
	// Don't revert split if there are orphaned children (reportID '0') - they're still part of the split
	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

App/src/libs/actions/IOU/SplitTransactionUpdate.ts

Lines 1363 to 1369 in 9573a6c

	const splitExpenses = params.transactionData?.splitExpenses ?? [];
	const originalTransactionID = params.transactionData?.originalTransactionID ?? CONST.IOU.OPTIMISTIC_TRANSACTION_ID;
	const allChildTransactions = getChildTransactions(params.allTransactionsList, params.allReportsList, originalTransactionID, true);
	const originalChildTransactions = allChildTransactions.filter((tx) => tx?.reportID !== CONST.REPORT.UNREPORTED_REPORT_ID);
	const hasEditableSplitExpensesLeft = splitExpenses.some((expense) => (expense.statusNum ?? 0) < CONST.REPORT.STATUS_NUM.SUBMITTED);
	const isReverseSplitOperation =
	splitExpenses.length === 1 && originalChildTransactions.length > 0 && hasEditableSplitExpensesLeft && allChildTransactions.length === originalChildTransactions.length;

This reproduction creates that stale orphan state. An earlier removal while the remaining split is not eligible for reverse-split cleanup can leave the removed child parked as an unreported/orphaned split child. Later, after unapproval and another add/remove cycle, the user has one visible editable split left, but the hidden orphan makes allChildTransactions.length !== originalChildTransactions.length. The client sends UPDATE_SPLIT_TRANSACTION instead of REVERT_SPLIT_TRANSACTION, so the surviving transaction keeps the split metadata and MoneyRequestView continues to append Split.

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

Fix the split update state transition, not just the Amount label.

In SplitTransactionUpdate, replace the duplicated reverse-split predicate with a shared helper used by both updateSplitTransactions() and updateSplitTransactionsFromSplitExpensesFlow(). That helper should decide reverse-split eligibility from the active saved split list and active non-deleted children, so an orphaned child that is not represented by the current splitExpenses payload does not block reverting when exactly one editable visible split remains.

When the helper classifies the operation as a reverse split, keep using REVERT_SPLIT_TRANSACTION, restore the original transaction into the remaining report, and include the stale orphaned split children/snapshot entries for the same originalTransactionID in the optimistic/success cleanup. The restored transaction should no longer have split-child metadata, so getOriginalTransactionWithSplitInfo() returns isExpenseSplit: false.

This should stay scoped to the split update flow:

• Files touched: src/libs/actions/IOU/SplitTransactionUpdate.ts — updateSplitTransactions() around lines 156-167 and updateSplitTransactionsFromSplitExpensesFlow() around lines 1363-1369, plus the reverse cleanup block around lines 1002-1073.
• Tests touched: split transaction update / IOU split tests covering a lingering UNREPORTED_REPORT_ID child that is absent from the saved split list, and a MoneyRequestView assertion that a truly reverted single expense does not render Amount · Split.
• Platforms: all clients through shared IOU/Onyx state.
• Code paths not touched: the open-report amount-edit affordance in MoneyRequestView and initSplitExpense should keep the existing isReportOpen fallback for real remaining split children.
• API contracts/backend behavior changes: no new API contract; choose the existing REVERT_SPLIT_TRANSACTION command in the case that should already be a reverse split.

What alternative solutions did you explore? (Optional)

A label-only fix in MoneyRequestView could add shouldShowSplitLabel = isExpenseSplit && hasMultipleSplits and use that only for the text. That would hide the reported label, but the transaction would still be stored as a split child and the Amount row would still route through the split editor because the data model still says isExpenseSplit. For an explicit "Remove split > Save" revert, the better fix is to make the data state match the user action.

Relaxing only the statusNum < SUBMITTED check is also incomplete. It may help submitted/open-status edge cases, but it does not address the verified stale-orphan blocker: the orphan-inclusive allChildTransactions.length === originalChildTransactions.length check can still force UPDATE_SPLIT_TRANSACTION even when the visible split list has been reduced to one.

[aswin-s]

Proposal

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

On Web, after unapproving a previously-approved report and then removing a split from an expense (Amount > highlighted split > Remove split > Save), the Amount field still shows the "Split" indicator even though the expense is no longer split. Expected: once the split is removed, the "Split" indicator on the Amount field disappears.

What is the root cause of that problem?

The indicator is gated by shouldShowSplitIndicator = isExpenseSplit && (hasMultipleSplits || isReportOpen) in src/components/ReportActionItem/MoneyRequestView.tsx:356.

Two facts combine:

1. isExpenseSplit stays true after the split is removed. isExpenseSplit (getOriginalTransactionWithSplitInfo -> isExpenseSplit, src/libs/TransactionUtils/index.ts:2716) is keyed off comment.source === 'split' and comment.originalTransactionID. In this multi-step flow the removal is not recognized as a clean reverse split (isReverseSplitOperation, src/libs/actions/IOU/SplitTransactionUpdate.ts:166 requires exactly one editable split left and no unreported leftover siblings — allChildTransactions.length === originalChildTransactions.length). The earlier removed/unreported siblings and the unapprove leave that condition unmet, so the original transaction is never restored and the surviving child keeps its split metadata. isExpenseSplit therefore remains true.
2. hasMultipleSplits correctly becomes false — useHasMultipleSplitChildren (src/hooks/useHasMultipleSplitChildren.ts:17-22) excludes DELETE-pending and UNREPORTED_REPORT_ID children, so the freshly-removed split is no longer counted.

With hasMultipleSplits === false, the only thing keeping the indicator on is the || isReportOpen disjunct: unapproving the report (step 13) flips it back to Open, so isReportOpen (MoneyRequestView.tsx:355) is true.

Crucially, || isReportOpen is intentional, not a bug. It was added in commit dcc3c9b ("Show split indicator based on multiple splits and open report status") specifically so a split expense keeps the re-split affordance on an Open report — shouldShowSplitIndicator also gates canEditAmount (MoneyRequestView.tsx:367) and the initSplitExpense click handler (MoneyRequestView.tsx:958). The real defect is that the cosmetic "Split" label (MoneyRequestView.tsx:574-575) is driven by the same overloaded flag as the affordance, so an Open report shows the label even when the expense is no longer actually split.

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

Decouple the cosmetic label from the edit affordance so the label reflects whether the expense is actually still split, while the Open-report re-split affordance is preserved:

1. In src/components/ReportActionItem/MoneyRequestView.tsx, introduce a label-specific flag that drops the open-report override:
   • const shouldShowSplitLabel = isExpenseSplit && hasMultipleSplits;
   • Keep shouldShowSplitIndicator = isExpenseSplit && (hasMultipleSplits || isReportOpen); for the affordance.
2. Gate the amount-description label (MoneyRequestView.tsx:574-575) on shouldShowSplitLabel instead of shouldShowSplitIndicator. After the split is removed, hasMultipleSplits is false, so the label disappears as expected.
3. Leave canEditAmount (line 367) and the initSplitExpense branch (line 958) on shouldShowSplitIndicator so re-splitting on an Open report still works.

This fixes the visible bug (the lingering "Split" text) at the narrowest layer without changing the affordance behavior that the team has deliberately kept.

What alternative solutions did you explore? (Optional)

• Remove the || isReportOpen disjunct (shouldShowSplitIndicator = isExpenseSplit && hasMultipleSplits). Rejected. This is precisely PR Fix unable to re-split a transaction after its unreported sibling got deleted #91104 ("Fix unable to re-split a transaction after its unreported sibling got deleted", merge fba14b7), which was reverted on 2026-05-24 in [CP Staging] Revert "Fix unable to re-split a transaction after its unreported sibling got deleted" #91549 (7a059f4). That disjunct is the intentional re-split affordance from dcc3c9b; removing it kills canEditAmount/initSplitExpense for single-child splits on Open reports and reintroduces the exact regression the team just rolled back. Any fix touching this line must not reapply the reverted change.
• Clear comment.source/originalTransactionID on the surviving transaction when the last split is removed (so isExpenseSplit becomes false). This is the deepest root-cause fix but is riskier: those fields are relied on across the split flows and the removal/reverse-split path (SplitTransactionUpdate.ts) is shared backend-adjacent logic. The display-layer decoupling above is the narrower, safer frontend fix and is sufficient to resolve the reported symptom.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @huult (External)

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-26 19:08:22 UTC.

Proposal

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

On the expense details view, the Amount field keeps showing the " · Split" indicator after the user removes the split from a previously‑approved‑then‑unapproved expense. Once the split has been removed the amount is a regular single expense, so the "Split" label should no longer appear.

What is the root cause of that problem?

The visible " · Split" label on the Amount row and the amount‑edit affordance (whether the amount field is editable, and whether tapping it opens the split editor) are both driven by a single shouldShowSplitIndicator flag:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 355 to 356 in 9573a6c

	const isReportOpen = isOpenReport(moneyRequestReport);
	const shouldShowSplitIndicator = isExpenseSplit && (hasMultipleSplits || isReportOpen);

The label uses it here:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 574 to 576 in 9573a6c

	if (shouldShowSplitIndicator) {
	amountDescription += ` ${CONST.DOT_SEPARATOR} ${translate('iou.split')}`;
	}

and the amount‑edit affordance uses the same flag for both the editability gate and the tap handler that opens the split editor:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 363 to 367 in 9573a6c

	const canEditAmount =
	!isGPSDistanceRequest &&
	isEditable &&
	(canEditFieldOfMoneyRequest({reportAction: parentReportAction, fieldToEdit: CONST.EDIT_REQUEST_FIELD.AMOUNT, isChatReportArchived, transaction}) ||
	(shouldShowSplitIndicator && isSplitAvailable));

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 958 to 961 in 9573a6c

	if (shouldShowSplitIndicator && isSplitAvailable) {
	initSplitExpense(transaction, policy);
	return;
	}

shouldShowSplitIndicator is isExpenseSplit && (hasMultipleSplits || isReportOpen). After a split is removed, the remaining transaction still keeps comment.source === 'split', so isExpenseSplit stays true, while hasMultipleSplits correctly becomes false once a single child remains. The label should therefore disappear — but the || isReportOpen fallback keeps the whole flag true whenever the report is in the Open state. In this repro the report is un‑approved at step 13, putting it back into the Open state, so the stale "Split" label survives even though there is no longer a real multi‑way split.

The fallback cannot simply be dropped from the shared flag, though: it is also what keeps the amount‑edit affordance routing a reverted split through the split editor rather than the plain amount editor. Removing || isReportOpen from this single flag is exactly what an earlier change did, and it regressed amount editing — an error appeared when editing a reverted split's amount to a higher value (#91481) — so that change was reverted, which is why the stale label is back. The label and the edit affordance therefore need to be gated separately.

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

Split the single condition into two so the label and the edit affordance no longer share the open‑report fallback:

• Keep shouldShowSplitIndicator = isExpenseSplit && (hasMultipleSplits || isReportOpen) for the amount‑edit affordance only — the canEditAmount branch and the tap‑to‑open‑split‑editor handler — preserving today's editing behavior so the previously‑reverted edit error does not return.
• Add a label‑only condition, isExpenseSplit && hasMultipleSplits, and use it for the visible " · Split" label instead.

Because hasMultipleSplits (via useHasMultipleSplitChildren) counts the split's child transactions directly — including children that belong to an Open report, since those children carry that report's reportID — a genuine in‑progress multi‑way split still resolves to true and keeps its label, while a transaction whose siblings have all been removed resolves to false and the "Split" label disappears. This hides the stale label in the reported flow without touching the amount‑edit path that the open‑report fallback protects.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/91749-split-label-after-removal?expand=1

What alternative solutions did you explore? (Optional)

Drop || isReportOpen from the single shouldShowSplitIndicator flag entirely. This does hide the label, but because the same flag also gates the amount‑edit affordance it reintroduces the previously‑reverted error when editing a reverted split's amount to a higher value, so it is not safe.

A second option is to fix the source data so the remaining transaction is no longer treated as a split — clear comment.source / comment.originalTransactionID (so isExpenseSplit returns false) when the last sibling split is removed. This is a more invasive change to the split‑removal save flow and risks affecting other split‑aware screens, so gating the label on hasMultipleSplits is the smaller, more targeted fix.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022059348318856477553

[lxyct825-ops]

Proposal

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

[$250] Web - Expense - Amount field still displays “Split” after reverting a previously approved

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.