[$250] Incorrect amounts displayed after setting a split to $0.00 on OD

[mitarachim]

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.3.15-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: #81240
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Honor x6b/ Android 14
App Component: Money Requests

Action Performed:

1. Go to workspace chat.

2. Create an expense.

3. Open the expense.

4. Click More > Split > Save.

5. Navigate to OD.

6. On OD, open the report with split expenses.

7. On OD, open any split, change the amount to 0 and save it.
   Result: a) In the expense preview of the split, the original amount is displayed instead of "0".
   b) The total of the two splits is equal the original expense plus the split amount.

8. Go back to "My Reports" view
   Result: The report total is only one of the splits.

9. Open the report again
   Result: Incorrect values still remains.

10. Return to ND and refresh the same report on ND.
    Result: Correct values are displayed-> Expected

Expected Result:

After saving a split with $0.00, all views should display consistent amounts

Actual Result:

After saving a split with an amount of $0.00 on OD:

1. In the expense preview of the split, the original amount is displayed instead of "0".
2. The total of the two splits is equal the original expense plus the split amount.

In the "My Reports" view, only the amount of one split is shown, resulting in inconsistent values between views.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7068934_1770339903780.document_4911346861626885787_-_Trim.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022019624057650790520
• Upwork Job ID: 2019624057650790520
• Last Price Increase: 2026-02-20

Issue Owner

Current Issue Owner: @linhvovan29546

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @brianlee-expensify (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 Contributor-plus team member for initial proposal review - @linhvovan29546 (External)

[btkcodedev]

Proposal

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

When a user saves a split expense with an amount of $0.00 on the Original Details (OD) view, the following issues occur:

1. In the expense preview of the split, the original amount is displayed instead of $0.00
2. The total of the two splits equals the original expense amount plus the split amount (incorrect calculation)
3. In the "My Reports" view, only the amount of one split is shown
4. When navigating between different views (OD, ND, My Reports), inconsistent amounts are displayed
5. These incorrect values persist even after refreshing the report on ND

The expected behavior is that after saving a split with $0.00, all views should consistently display $0.00 for that split.

What is the root cause of that problem?

The root cause is the use of the logical OR operator (||) instead of the nullish coalescing operator (??) when handling modifiedAmount in the transaction calculations. Since 0 is a falsy value in JavaScript, the expression Number(transaction?.modifiedAmount) || transaction?.amount evaluates to the original transaction.amount when modifiedAmount is 0, rather than correctly using the 0 value.

Additionally, the validation logic in isSplitAction was using !amount which treats 0 as an invalid amount, preventing proper handling of $0.00 split expenses.

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

File 1: [~/App/src/components/ReportActionItem/TransactionPreview/index.tsx]

Lines 99-102:

const transactionRawAmount = Number(transaction?.modifiedAmount ?? transaction?.amount) ?? 0;

File 2: [~/App/src/libs/ReportSecondaryActionUtils.ts]

Lines 119-121:

if (amount == null && !isExpenseSplit) {
    return false;
}

File 3: [~/App/src/libs/ReportUtils.ts]

Lines 12145-12150:

const transactions = getReportTransactions(iouReport?.reportID).filter(
    (transaction) => !shouldExcludeDeletedTransactions || transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
);
// Use ?? instead of || to properly handle modifiedAmount of 0
return isIOUReport(iouReport) && transactions.some((transaction) => Number(transaction?.modifiedAmount ?? transaction?.amount) <= 0);

File 4: [~/App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx]

Lines 95-101:

if (!isIOUReport(iouReport) && action.childType !== CONST.REPORT.TYPE.IOU) {
    return false;
}

// Use ?? instead of || to properly handle modifiedAmount of 0
return transactions.some((transaction) => Number(transaction?.modifiedAmount ?? transaction?.amount) < 0);

These changes replace the logical OR operator with the nullish coalescing operator, which only falls back to the original amount when modifiedAmount is null or undefined, not when it is 0. The validation change uses == null to properly check for nullish values while allowing 0 as a valid amount for expense splits.

What alternative solutions did you explore? (Optional)

None

[ubaidsk]

Proposal

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

When a user edits a money request so the transaction modifiedAmount is 0 (for example, set the amount to 0 or create a split that results in 0), then navigates to a report preview, transaction preview, or search results, the app still uses the original amount instead of the valid modifiedAmount. This is a problem because the UI and related logic show and compute the wrong amount, which can flip payer/receiver logic and mis-handle negative/zero checks.

What is the root cause of that problem?

Several call sites choose between modifiedAmount and amount using Number(modifiedAmount) || amount. In JavaScript, 0 is falsy, so a valid modifiedAmount of 0 is ignored and the original amount is used. This happens in the money request report preview, transaction preview, report validation, search UI amount handling, and split conversion math. Examples:

App/src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx

Lines 95 to 101 in e663634

	if (!isIOUReport(iouReport) && action.childType !== CONST.REPORT.TYPE.IOU) {
	return false;
	}
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	return transactions.some((transaction) => (Number(transaction?.modifiedAmount) || transaction?.amount) < 0);
	}, [transactions, action.childType, iouReport]);

App/src/components/ReportActionItem/TransactionPreview/index.tsx

Lines 94 to 96 in e663634

	// See description of `transactionRawAmount` prop for more context
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const transactionRawAmount = (Number(transaction?.modifiedAmount) || transaction?.amount) ?? 0;

App/src/libs/ReportUtils.ts

Lines 12485 to 12489 in e663634

	const transactions = getReportTransactions(iouReport?.reportID).filter(
	(transaction) => !shouldExcludeDeletedTransactions || transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	);
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	return isIOUReport(iouReport) && transactions.some((transaction) => (Number(transaction?.modifiedAmount) || transaction?.amount) <= 0);

App/src/libs/SearchUIUtils.ts

Lines 1111 to 1121 in e663634

	return Math.abs(amount).toString().length >= maxLength;
	}
	function isTransactionAmountTooLong(transactionItem: TransactionListItemType | OnyxTypes.Transaction) {
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const amount = Math.abs(Number(transactionItem.modifiedAmount) || transactionItem.amount);
	return isAmountTooLong(amount);
	}
	function isTransactionTaxAmountTooLong(transactionItem: TransactionListItemType | OnyxTypes.Transaction) {
	// it won't matter if pass true or false as second argument to getTaxAmount here because isAmountTooLong function uses Math.abs on the returned value of getTaxAmount

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

Lines 3425 to 3433 in e663634

	const {convertedAmount: originalConvertedAmount, ...existingTransactionWithoutConvertedAmount} = existingTransaction;
	optimisticTransaction = fastMerge(existingTransactionWithoutConvertedAmount, optimisticTransaction, false);
	// Calculate proportional convertedAmount for the split based on the original conversion rate
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing -- modifiedAmount can be empty string
	const originalAmount = Number(existingTransaction.modifiedAmount) || existingTransaction.amount;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing -- modifiedAmount can be empty string
	const splitAmount = Number(optimisticTransaction.modifiedAmount) || optimisticTransaction.amount;
	if (originalConvertedAmount && originalAmount && splitAmount) {

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

Use hasValidModifiedAmount() to detect when a modifiedAmount is present (including 0) and only fall back to amount when modifiedAmount is missing or empty.

Reference for the helper behavior:

App/src/libs/TransactionUtils/index.ts

Lines 617 to 622 in e663634

	function hasValidModifiedAmount(transaction: OnyxEntry<Transaction> | null): boolean {
	if (!transaction) {
	return false;
	}
	return transaction?.modifiedAmount !== undefined && transaction?.modifiedAmount !== null && transaction?.modifiedAmount !== '';
	}

Example:

In src/components/ReportActionItem/TransactionPreview/index.tsx
...
-    const transactionRawAmount = (Number(transaction?.modifiedAmount) || transaction?.amount) ?? 0;
+    const transactionRawAmount = hasValidModifiedAmount(transaction) ? Number(transaction?.modifiedAmount) : (transaction?.amount ?? 0);

Apply this consistently in:

• MoneyRequestReportPreview for payer/receiver visibility checks.
• TransactionPreview for transactionRawAmount.
• ReportUtils.doesReportContainRequestsFromMultipleUsers for zero/negative checks.
• SearchUIUtils by introducing a helper that returns modifiedAmount when valid and reusing it for amount length checks and getToFieldValue.
• IOU.getMoneyRequestInformation when calculating proportional convertedAmount during splits.

What alternative solutions did you explore? (Optional)

[twinkle-react]

Proposal

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

After saving a split with amount $0.00 on OD, presentation surfaces like expense preview, report totals, and My Reports show inconsistent values because presentation and decision code treats 0 as missing and falls back to original amounts.

What is the root cause of that problem?

In this implementation, call sites assume a falsy amount or modifiedAmount means it is missing, using checks like if (!amount) and fallbacks like Number(modifiedAmount) || amount in presentation helpers, starting from src/libs/TransactionUtils/index.ts in the function hasValidModifiedAmount, which wrongly excludes numeric 0 and directly causes inconsistent amount selection.

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

Single invariant (exact).
Presentation and decision logic must treat an explicit numeric modifiedAmount, including 0, as authoritative. Only undefined, null, or '' mean no modified amount.

Apply the smallest shared-layer fix.
Owner is presentation and decision helpers only.

Update hasValidModifiedAmount to accept numeric 0.
Replace falsy checks like if (!amount) with explicit numeric checks.
Replace Number(modifiedAmount) || amount with empty-string-aware coalesce.

Exact code delta and scope.
Files changed are presentation only.

Code changes are pasted below, at the described locations.

// src/libs/ReportSecondaryActionUtils.ts
// Determine split info up-front so we can allow editing existing expense-splits even when amount is 0.
// Treat undefined/null/empty-string as "no amount"; numeric 0 is a valid explicit amount.
const {isBillSplit, isExpenseSplit} = getOriginalTransactionWithSplitInfo(reportTransaction, originalTransaction);
const {amount} = getTransactionDetails(reportTransaction) ?? {};
const hasAmount = typeof amount === 'number';

// If there's no numeric amount and this is not already an expense split, disallow split action.
// Allow existing expense splits to pass through so they can be edited (including zero-amount split items).
if (!hasAmount && !isExpenseSplit) {
    return false;
}

if (isBillSplit) {
    return false;
}

// src/libs/TransactionUtils/index.ts
function hasValidModifiedAmount(transaction: OnyxEntry<Transaction> | null): boolean {
    if (!transaction) {
        return false;
    }

    // Numeric 0 is a valid explicit modifiedAmount; only undefined/null/'' indicate "no modified amount"
    return transaction?.modifiedAmount !== undefined
        && transaction?.modifiedAmount !== null
        && transaction?.modifiedAmount !== '';
}

// src/components/ReportActionItem/TransactionPreview/index.tsx
// Prefer explicit modifiedAmount when present. Treat '' as missing. Numeric 0 is valid.
const modified = transaction?.modifiedAmount;
const transactionRawAmount = (modified === '' || modified == null)
    ? (transaction?.amount ?? 0)
    : Number(modified);

// src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx
// Prefer explicit modifiedAmount when present. Treat '' as missing. Numeric 0 is valid.
return transactions.some((transaction) => {
    const modified = transaction?.modifiedAmount;
    const amountToUse = (modified === '' || modified == null)
        ? (transaction?.amount ?? 0)
        : Number(modified);
    return amountToUse < 0;
});

// src/libs/SearchUIUtils.ts
// numeric modifiedAmount (including 0) is valid; '' means not present
const modified = transactionItem.modifiedAmount;
const amount = Math.abs(
    (modified === '' || modified == null)
        ? (transactionItem.amount ?? 0)
        : Number(modified),
);

// src/libs/actions/IOU/index.ts
// Prefer explicit modifiedAmount when present ('' treated as missing). Numeric 0 is valid.
const modifiedOriginal = existingTransaction.modifiedAmount;
const originalAmount = (modifiedOriginal === '' || modifiedOriginal == null)
    ? (existingTransaction.amount ?? 0)
    : Number(modifiedOriginal);

const modifiedSplit = optimisticTransaction.modifiedAmount;
const splitAmount = (modifiedSplit === '' || modifiedSplit == null)
    ? (optimisticTransaction.amount ?? 0)
    : Number(modifiedSplit);

// src/libs/ReportUtils.ts
const modified = transaction?.modifiedAmount;
const amountToUse = (modified === '' || modified == null)
    ? (transaction?.amount ?? 0)
    : Number(modified);
return amountToUse <= 0;

// Pseudocode
// General usage snippet (preferred, centralized pattern)

// Option A: use helper
const amountToUse = hasValidModifiedAmount(transaction)
    ? Number(transaction.modifiedAmount)
    : (transaction?.amount ?? 0);

// Option B: inline coalesce
const modified = transaction?.modifiedAmount;
const amountToUse = (modified === '' || modified == null)
    ? (transaction?.amount ?? 0)
    : Number(modified);

Notes and constraints.
Treat '' as missing. Numeric 0 is authoritative.
Prefer hasValidModifiedAmount(...) at call sites.
Keep edits presentation and decision only.
Do not change persistence, API, or optimistic write shapes.
Add a one-line comment at each changed site saying numeric 0 is valid and empty string is missing.

Risk and ownership.
Owners are ReportSecondaryActionUtils, TransactionUtils, and the listed presentation helpers.
Regression risk is low because changes are small and local.
This restores editing and display for zero-amount splits.
Confirm product intent if zero splits were meant to be blocked.

What alternative solutions did you explore? (Optional)

Persist-layer rejection by blocking zero splits at updateSplitTransactions was considered but rejected because it changes persisted semantics and has higher risk.
Silently coercing '' to 0 was rejected because it removes the difference between explicit 0 and no modified amount.