[$250] Split expense - Third split is added as 0 after click 'Add split'

[vincdargento]

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.54-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-16750/folder/13176791/59413485/1313415729
Email or phone of affected tester (no customers): ndk.2303+284@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com/
2. Navigate to Workspace chat
3. Create a $10 expense
4. Open the expense details
5. Click on 'More > Split'
6. Split A to $3
7. Click 'Add Split'

Expected Result:

Verify a third split is added, A remains $3, B updates to $3.50, the new split C is added as $3.50

Actual Result:

A third split is added, new split is added as $0

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ahmedGaber93

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041862880505545592
• Upwork Job ID: 2041862880505545592
• Last Price Increase: 2026-04-22

[MelvinBot]

Proposal

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

When splitting a $10 expense where Split A is manually set to $3 and Split B auto-calculates to $7, clicking "Add Split" creates a third split with $0 instead of redistributing the remaining $7 evenly among the two unedited splits (B=$3.50, C=$3.50).

What is the root cause of that problem?

This is a regression from PR #87124 (which fixed #82455). That PR added a condition at src/libs/actions/IOU/Split.ts:2647 that skips redistribution when manually-edited splits exist AND the existing splits already sum to the total:

const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;

The problem: splitsAlreadyMatchTotal checks the existing splits (before the new one is added). Since existing splits almost always sum to the total, and any user edit sets hasManuallyEditedSplits = true, redistribution is skipped every time a user adds a split after editing any amount. The new split stays at its initialized value of $0.

The redistributeSplitExpenseAmounts function (Split.ts:2554-2581) already handles this correctly — it preserves manually-edited amounts and distributes the remainder among unedited splits. It just never gets called.

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

Modify the condition at Split.ts:2647 to check whether the updated splits (including the new $0 split) sum to the total, rather than the existing splits:

const updatedSum = updatedSplitExpenses.reduce((sum, split) => sum + split.amount, 0);
const splitsAlreadyMatchTotal = Math.abs(updatedSum) === Math.abs(total);
const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;

Since the new split has amount=0 and existing splits summed to the total, updatedSum will still equal the total numerically — but the key insight is that now there's an unedited split with $0 that needs a share. A cleaner alternative: always redistribute when addSplitExpenseField is called, since the entire purpose of this function is to add a new split that needs an amount. The edge case PR #87124 solved (edited amount exceeding total) is already handled correctly by redistributeSplitExpenseAmounts — it computes remaining = total - editedSum, which would be negative when edits exceed the total, and distributes that among unedited splits.

The simplest fix: remove the redistribution skip in addSplitExpenseField entirely — always call redistributeSplitExpenseAmounts (for non-distance requests):

// Remove lines 2639-2650 (the conditional logic) and replace with:
if (!isDistanceRequest) {
    redistributedSplitExpenses = redistributeSplitExpenseAmounts(updatedSplitExpenses, total, currency);
}

This preserves the original intent (user-edited amounts stay fixed, unedited splits share the remainder) while ensuring newly-added splits receive a proper amount.

What alternative solutions did you explore? (Optional)

The condition could be patched more narrowly (e.g., adding || updatedSplitExpenses.some(s => s.amount === 0 && !s.isManuallyEdited)), but since redistributeSplitExpenseAmounts already handles all edge cases correctly, the simplest approach is to always call it.

Related issues

• [Due for payment 2026-04-14] Expense - New split shows wrong amount which leads to higher total amount #82455 — "New split shows wrong amount" (fixed by PR fix: skip auto-redistribution when adding splits with manual edits #87124, which introduced this regression)
• [Due for payment 2026-04-17] [Due for payment 2026-04-16] Split scan - Amount on split details page is 0.00 despite entering a valid amount #87299 — "Amount on split details page is 0.00" (different bug — split scan display issue)
• Split expense - Expense cannot be split despite having amount on amount field #86351 — "Expense cannot be split despite having amount" (different bug — wrong Onyx key)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

Proposal

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

When a user splits a $10 expense, edits split A to $3 (which auto-updates split B to $7), and then clicks "Add Split", the third split is created with an amount of $0. The expected behavior is that the remaining $7 should be redistributed among the two unedited splits so each becomes $3.50.

What is the root cause of that problem?

The gating condition that was added to addSplitExpenseField in src/libs/actions/IOU/Split.ts skips redistribution in exactly this scenario:

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

Lines 2639 to 2650 in 946de58

	// Check if existing splits already sum to the total
	const existingSum = existingSplits.reduce((sum, split) => sum + split.amount, 0);
	const hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited);
	const splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total);
	let redistributedSplitExpenses = updatedSplitExpenses;
	// Skip redistribution only when manual edits exist AND splits sum to total
	const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;
	if (!isDistanceRequest && shouldRedistribute) {
	redistributedSplitExpenses = redistributeSplitExpenseAmounts(updatedSplitExpenses, total, currency);
	}

Walking through the condition with the reported reproduction data (total = $10, existing splits [A = $3 edited, B = $7 unedited]):

1. existingSum = 3 + 7 = 10
2. splitsAlreadyMatchTotal = Math.abs(10) === Math.abs(10) → true
3. hasManuallyEditedSplits = true (A was edited)
4. shouldRedistribute = !true || !true → false
5. redistributeSplitExpenseAmounts is skipped and the newly appended split keeps its initial value of 0.

In practice the guard collapses to "whenever any split has ever been edited, keep the new split at zero". That is because updateSplitExpenseAmountField rebalances the unedited splits every time the edited one changes, so by the time the user clicks "Add Split" the existing splits almost always sum to the total. The only way for splitsAlreadyMatchTotal to be false is if the user has edited multiple splits to under- or over-shoot the total, which is a different code path that redistributeSplitExpenseAmounts would handle anyway.

redistributeSplitExpenseAmounts itself is already correct — it filters out edited splits via split.isManuallyEdited, computes remaining = total - editedSum, and distributes only the remainder among the unedited splits (including the freshly appended zero one):

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

Lines 2554 to 2581 in 946de58

	function redistributeSplitExpenseAmounts(splitExpenses: SplitExpense[], total: number, currency: string): SplitExpense[] {
	// Calculate sum of manually edited splits
	const editedSum = splitExpenses.filter((split) => split.isManuallyEdited).reduce((sum, split) => sum + split.amount, 0);
	// Find all unedited splits
	const uneditedSplits = splitExpenses.filter((split) => !split.isManuallyEdited);
	const uneditedCount = uneditedSplits.length;
	// If no unedited splits, return as-is
	if (uneditedCount === 0) {
	return splitExpenses;
	}
	// Redistribute remaining amount among unedited splits
	const remaining = total - editedSum;
	const lastUneditedIndex = uneditedCount - 1;
	let uneditedIndex = 0;
	return splitExpenses.map((split) => {
	if (split.isManuallyEdited) {
	return split;
	}
	const isLast = uneditedIndex === lastUneditedIndex;
	const newAmount = calculateIOUAmount(lastUneditedIndex, remaining, currency, isLast, true);
	uneditedIndex += 1;
	return {...split, amount: newAmount};
	});
	}

Additionally, the existing Jest case should preserve edited splits when adding a new split at tests/unit/SplitExpenseAutoAdjustmentTest.ts was intended to cover exactly this behavior — its comment block reads "New split + Split 2: share remaining 700 -> 350 each" — but it only asserts that split 1 stays locked at 300 and that the total still equals 1000. It never asserts the value of the unedited splits, so the regression passed the test with [300, 700, 0] even though that contradicts the comment. This assertion gap is why the bug landed undetected.

App/tests/unit/SplitExpenseAutoAdjustmentTest.ts

Lines 93 to 133 in 946de58

	it('should preserve edited splits when adding a new split', async () => {
	// Setup: 2 splits - one edited at $3, one unedited at $7
	const initialSplits = [
	createSplitExpense('split1', 300, true), // Edited/locked
	createSplitExpense('split2', 700, false), // Unedited
	];
	const mockTransaction = createMockDraftTransaction(initialSplits);
	await Onyx.set(`${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${ORIGINAL_TRANSACTION_ID}`, mockTransaction);
	await waitForBatchedUpdates();
	// Action: Add a new split
	addSplitExpenseField(mockTransaction, mockTransaction, undefined);
	await waitForBatchedUpdates();
	// Verify: 3 splits
	// Split 1: locked at 300
	// New split + Split 2: share remaining 700 -> 350 each
	const draftTransaction = await new Promise<OnyxEntry<Transaction>>((resolve) => {
	const connection = Onyx.connect({
	key: `${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${ORIGINAL_TRANSACTION_ID}`,
	callback: (value) => {
	Onyx.disconnect(connection);
	resolve(value);
	},
	});
	});
	const splitExpenses = draftTransaction?.comment?.splitExpenses ?? [];
	expect(splitExpenses.length).toBe(3);
	// Verify split 1 is still 300 and marked as edited
	const split1 = splitExpenses.find((s) => s.transactionID === 'split1');
	expect(split1?.amount).toBe(300);
	expect(split1?.isManuallyEdited).toBe(true);
	// Verify total matches
	const totalAmount = splitExpenses.reduce((sum, split) => sum + split.amount, 0);
	expect(totalAmount).toBe(TOTAL_AMOUNT);
	});

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

Remove the shouldRedistribute gate in addSplitExpenseField and always run redistributeSplitExpenseAmounts on the updated array for non-distance requests. The lines that compute existingSum, hasManuallyEditedSplits, splitsAlreadyMatchTotal, and shouldRedistribute can all be dropped.

Verifying this is safe by re-running both relevant scenarios against redistributeSplitExpenseAmounts:

Bug scenario — [A = $3 edited, B = $7 unedited] → append C = $0 unedited:

• editedSum = $3
• uneditedSplits = [B, C], uneditedCount = 2
• remaining = $10 − $3 = $7
• Distributed via calculateIOUAmount → B = $3.50, C = $3.50
• Final: [A = $3, B = $3.50, C = $3.50] ✅ matches expected result

The scenario PR #87124 was originally guarding — [A = $5 edited, B = $5 edited] → append C = $0 unedited:

• editedSum = $10
• uneditedSplits = [C], uneditedCount = 1
• remaining = $10 − $10 = $0
• C = calculateIOUAmount(0, 0, USD, true, true) = $0
• Final: [A = $5, B = $5, C = $0] ✅ same outcome as the skip branch

So unconditionally calling redistributeSplitExpenseAmounts fixes the reported bug without regressing the all-edited case. The existing test should keep new split at 0 when manual edits exist and sum matches total continues to pass unchanged.

As part of the fix, the assertions in the should preserve edited splits when adding a new split test should also be tightened to explicitly check that split2 and the new split are both 350, matching the test's own comment. That closes the regression-detection gap that let this bug slip through.

What alternative solutions did you explore? (Optional)

One alternative is to keep the guard but recompute splitsAlreadyMatchTotal against updatedSplitExpenses (which includes the new zero split) instead of existingSplits. In the bug scenario the sum is still numerically $10, so this alone does not help — it would need to be combined with an extra check like "any unedited split has amount === 0". That adds branching for no benefit: redistributeSplitExpenseAmounts is already effectively a no-op when the unedited splits do not need to change (remaining === 0 makes calculateIOUAmount return 0), so the guard is unnecessary. Dropping it is simpler and strictly more correct.

Compare branch

https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87378-split-add-zero?expand=1

[wildan-m]

Proposal updated — added compare branch with implementation.

[MassoudFSharifi]

Proposal

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

When a user starts a brand-new split from an expense, manually changes one split amount, and then taps Add split, the newly added split is created with 0 instead of sharing the remaining amount with the still auto-managed split rows.

---

What is the root cause of that problem?

The bug is in the SplitExpensePage -> addSplitExpenseField() path, not in redistributeSplitExpenseAmounts() itself.

Here is the real sequence in the current code:

1. In the initial split flow, initSplitExpense() creates the two starting split rows with isManuallyEdited: false in (src/libs/actions/SplitExpenses.ts).
2. When the user edits split A, updateSplitExpenseAmountField() marks only that row as isManuallyEdited: true and then correctly redistributes the remainder to the unedited rows in (src/libs/actions/IOU/Split.ts).
3. When the user taps Add split, SplitExpensePage calls addSplitExpenseField() in (src/pages/iou/SplitExpensePage.tsx).
4. addSplitExpenseField() currently computes:
   • hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited)
   • splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total)
   • shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits
5. After step 2, the draft already matches the total, and at least one split is manually edited, so shouldRedistribute becomes false. That skips redistributeSplitExpenseAmounts(), and the new split stays at its initialized amount of 0.

The guard is too broad because it collapses two different product states into one:

• Initial split flow: only some rows are manually edited, and the remaining auto-managed rows should still rebalance.
• Re-opened existing split flow: initSplitExpense() seeds child transactions with isManuallyEdited: true in (src/libs/actions/SplitExpenses.ts), so when all existing rows already sum to the total, the new split should stay 0 to preserve the behavior introduced for #82455.

So the actual root cause is that addSplitExpenseField() checks whether any existing split is manually edited, when it should only skip redistribution when all existing splits are manually edited and the draft already balances.

---

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

Keep the current architecture and helper usage, but narrow the addSplitExpenseField() guard so we only skip redistribution for the #82455 case: when every existing split is already user-managed and the current draft already sums to the original amount.

That gives us the correct behavior in both codepaths:

• Initial split flow: at least one existing split is still auto-managed, so adding a new split redistributes the remaining amount across the unedited rows.
• Re-opened existing split flow: all existing child splits are already marked isManuallyEdited: true, so adding a new split keeps it at 0 when the draft already balances.

This is stronger than removing the guard entirely because it fixes this regression without reintroducing the behavior that #87124 intentionally preserved.

Implementation

// File: src/libs/actions/IOU/Split.ts

@@
-    const hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited);
+    const hasUneditedSplits = existingSplits.some((split) => !split.isManuallyEdited);
     const splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total);

     let redistributedSplitExpenses = updatedSplitExpenses;

-    // Skip redistribution only when manual edits exist AND splits sum to total
-    const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;
+    // Only keep the new split at 0 when the draft already balances and every existing split is user-managed.
+    const shouldRedistribute = !splitsAlreadyMatchTotal || hasUneditedSplits;
     if (!isDistanceRequest && shouldRedistribute) {
         redistributedSplitExpenses = redistributeSplitExpenseAmounts(updatedSplitExpenses, total, currency);
     }

This works because redistributeSplitExpenseAmounts() already has the correct behavior for mixed states: it preserves isManuallyEdited rows and only redistributes the remainder across unedited rows. The change simply makes sure we still call that helper in the initial split flow, while preserving the intentional skip for previously-saved split expenses where all rows are already locked.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

Removing the guard entirely and always redistributing is weaker because it would also change the re-opened existing-split behavior that #82455 intentionally protected.

Recomputing the sum against updatedSplitExpenses is also weaker, because appending a new 0 split does not change the numeric sum, so that still does not distinguish between “some rows are still auto-managed” and “all rows are already manually owned.”

[github-actions]

⚠️ @MassoudFSharifi Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[abbasifaizan70]

Proposal

What is the root cause of that problem?

The split flow preserves manually edited rows and redistributes only the unedited rows. When a user edits A to $3, A becomes manually edited and B stays unedited. After that, clicking Add split appends a new unedited split C with amount 0.

The bug is in the redistribution guard: it skips redistribution whenever splits already match the total and there is at least one manual edit. In this case, that condition is too broad because B and C are still unedited and should be redistributed to share the remaining amount.

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

Lines 2639 to 2648 in 24db80a

	// Check if existing splits already sum to the total
	const existingSum = existingSplits.reduce((sum, split) => sum + split.amount, 0);
	const hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited);
	const splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total);
	let redistributedSplitExpenses = updatedSplitExpenses;
	// Skip redistribution only when manual edits exist AND splits sum to total
	const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;
	if (!isDistanceRequest && shouldRedistribute) {

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

We should only skip redistribution when all existing splits are manually edited and already sum to the total. If at least one existing split is unedited, the remaining amount should be redistributed across unedited splits (including the newly added split), which gives the expected $3 / $3.50 / $3.50 result for a $10 total after editing A to $3.

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

Lines 2639 to 2648 in 24db80a

	// Check if existing splits already sum to the total
	const existingSum = existingSplits.reduce((sum, split) => sum + split.amount, 0);
	const hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited);
	const splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total);
	let redistributedSplitExpenses = updatedSplitExpenses;
	// Skip redistribution only when manual edits exist AND splits sum to total
	const shouldRedistribute = !splitsAlreadyMatchTotal || !hasManuallyEditedSplits;
	if (!isDistanceRequest && shouldRedistribute) {

const existingSum = existingSplits.reduce((sum, split) => sum + split.amount, 0);
const hasManuallyEditedSplits = existingSplits.some((split) => split.isManuallyEdited);
const allExistingSplitsManuallyEdited = existingSplits.length > 0 && existingSplits.every((split) => split.isManuallyEdited);
const splitsAlreadyMatchTotal = Math.abs(existingSum) === Math.abs(total);

let redistributedSplitExpenses = updatedSplitExpenses;

const shouldRedistribute = !(splitsAlreadyMatchTotal && hasManuallyEditedSplits && allExistingSplitsManuallyEdited);

App/tests/unit/SplitExpenseAutoAdjustmentTest.ts

Lines 93 to 133 in 24db80a

	it('should preserve edited splits when adding a new split', async () => {
	// Setup: 2 splits - one edited at $3, one unedited at $7
	const initialSplits = [
	createSplitExpense('split1', 300, true), // Edited/locked
	createSplitExpense('split2', 700, false), // Unedited
	];
	const mockTransaction = createMockDraftTransaction(initialSplits);
	await Onyx.set(`${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${ORIGINAL_TRANSACTION_ID}`, mockTransaction);
	await waitForBatchedUpdates();
	// Action: Add a new split
	addSplitExpenseField(mockTransaction, mockTransaction, undefined);
	await waitForBatchedUpdates();
	// Verify: 3 splits
	// Split 1: locked at 300
	// New split + Split 2: share remaining 700 -> 350 each
	const draftTransaction = await new Promise<OnyxEntry<Transaction>>((resolve) => {
	const connection = Onyx.connect({
	key: `${ONYXKEYS.COLLECTION.SPLIT_TRANSACTION_DRAFT}${ORIGINAL_TRANSACTION_ID}`,
	callback: (value) => {
	Onyx.disconnect(connection);
	resolve(value);
	},
	});
	});
	const splitExpenses = draftTransaction?.comment?.splitExpenses ?? [];
	expect(splitExpenses.length).toBe(3);
	// Verify split 1 is still 300 and marked as edited
	const split1 = splitExpenses.find((s) => s.transactionID === 'split1');
	expect(split1?.amount).toBe(300);
	expect(split1?.isManuallyEdited).toBe(true);
	// Verify total matches
	const totalAmount = splitExpenses.reduce((sum, split) => sum + split.amount, 0);
	expect(totalAmount).toBe(TOTAL_AMOUNT);
	});

const initialSplits = [
    createSplitExpense('split1', 300, true),
    createSplitExpense('split2', 700, false),
];

const split1 = splitExpenses.find((s) => s.transactionID === 'split1');
const split2 = splitExpenses.find((s) => s.transactionID === 'split2');
const newSplit = splitExpenses.find((s) => s.transactionID !== 'split1' && s.transactionID !== 'split2');

expect(split1?.amount).toBe(300);
expect(split2?.amount).toBe(350);
expect(newSplit?.amount).toBe(350);