Expense-Manually entered split percentage auto-updates after focus change

[nlemma]

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: V9.4.19-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: #81626
Email or phone of affected tester (no customers): dreamnitethedragon@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Redminote 10S Android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Open workspace chat
3. Create a distance manual expense with distance 1mi
4. Open the expense
5. Tap More → Split → Percent
6. Remove the second split and enter 1
7. Keep cursor on first split
8. Note second split changed to 1.3

Expected Result:

Once a percentage is manually entered (1% in step 6), that value should remain unchanged. The system should not auto-update the edited split after focus change.

Actual Result:

After entering 1% in step 6, the second split automatically changes to 1.3% when focus remains on or shifts to the first split. The manually edited percentage is modified without additional user input.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7077485_1771029490317.Screenrecorder-2026-02-14-05-58-39-435.mp4

View all open jobs on GitHub

[melvin-bot]

@blimpich recently merged #81626, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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: #81626 - "feat: update amounts/percentages split logic to match OD (rework)" by @ikevin127 (High confidence)
Related Issues: None

Recommendation: REVERT

This PR implements automatic split redistribution logic that has a fundamental issue with percentage mode. The auto-redistribution is triggering on every percentage edit, causing manually entered percentages to change unexpectedly when focus shifts.

The bug affects core expense splitting functionality and makes percentage splits nearly unusable. A revert is the safest path forward to unblock the deploy while the author can rework the logic.

Labels: DeployBlockerCash will be kept (this is an App/frontend bug). DeployBlocker label should be removed if present since this does not block the backend deploy.

📋 Detailed Analysis

Evidence

PR #81626 was merged on 2026-02-12 and is listed in the current StagingDeployCash. The issue was caught during Pull Request QA execution for this specific PR. The issue description explicitly mentions:

If this was caught during regression testing, add the test name, ID and link from BrowserStack: #81626

Verification

The PR modifies the following key files that handle split expense logic:

• src/libs/actions/IOU/Split.ts - Contains redistributeSplitExpenseAmounts() and updateSplitExpenseAmountField()
• src/pages/iou/SplitExpensePage.tsx - UI layer that handles split expense editing
• src/components/SelectionList/ListItem/SplitListItem/SplitPercentageInput.tsx - Percentage input component
• src/types/onyx/IOU.ts - Added isManuallyEdited flag to track edited splits

All modified files are in the App repository (no backend changes).

Root Cause

When a user edits a percentage split value, the following happens:

1. User enters "1%" in the second split field
2. onSplitExpenseValueChange() converts the percentage to an amount via calculateSplitAmountFromPercentage()
3. updateSplitExpenseAmountField() is called, which:
   • Marks the current split as isManuallyEdited: true
   • Calls redistributeSplitExpenseAmounts() to redistribute OTHER unedited splits
4. The first split (unedited) gets auto-adjusted to accommodate the 1% allocation
5. Percentages are recalculated from the new amounts using calculateSplitPercentagesFromAmounts()
6. Due to rounding and the redistribution algorithm, the "1%" displays as "1.3%"

The core issue: The redistribution logic works by preserving manually edited values and redistributing among unedited ones. However, in percentage mode, this creates a confusing UX where entering "1%" doesn't result in exactly "1%" being displayed after focus change, because:

• The system converts percentage → amount → redistributes other splits → recalculates percentages from amounts
• Floating point math and rounding in the redistribution can cause the displayed percentage to differ from what was entered

From the PR diff (line 2202 in Split.ts):

const redistributedSplitExpenses = redistributeSplitExpenseAmounts(splitWithUpdatedAmount, total, currency);

This redistribution is called on EVERY amount update, including percentage edits, which triggers the auto-adjustment behavior that users find unexpected.