[$250] Expense - Edited expense shows the original amount instead of 0.00 amount in the table

[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: 9.3.75-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86824
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense with amount that is not zero.
4. Open the expense.
5. Click Amount.
6. Edit the amount to 0.00 and save it.
7. Create one more expense in the same report.

Expected Result:

The edited expense will show 0.00 amount in the table.

Actual Result:

The edited expense shows the original amount instead of 0.00 amount in the table.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7157266_1779122385574.20.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056448477046924432
• Upwork Job ID: 2056448477046924432
• Last Price Increase: 2026-05-18

Issue Owner

Current Issue Owner: @robertjchen

[MelvinBot]

Proposal

What is the root cause of that problem?

Multiple display paths use JavaScript's logical OR (||) instead of nullish coalescing (??) when choosing between modifiedAmount and amount. When a user edits an expense to $0.00, modifiedAmount is set to 0. Since 0 is falsy in JavaScript, Number(0) || transaction.amount evaluates to transaction.amount (the original pre-edit value), so the table/list shows the original amount instead of $0.00.

The primary culprit is TransactionPreview/index.tsx:104:

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

The canonical getAmount() function handles this correctly using hasValidModifiedAmount() (which only rejects undefined, null, and '' — not 0). The bug is that several call sites bypass getAmount() and inline the fallback with ||.

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

Replace || with proper nullish-aware checks at each affected call site. The primary fix for the reported symptom is in TransactionPreview/index.tsx:104 — change:

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

to use the same pattern as getAmount():

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

The same pattern should be applied to other affected sites:

• SearchUIUtils.ts:1330
• SearchUIUtils.ts:1710
• MoneyRequestReportPreview/index.tsx:100
• ReportUtils.ts:12628
• IOU/MoneyRequestBuilder.ts:1367

Related issues

• Expensify/App#87812 — Currency in original amount column doesn't update after editing (similar || vs ?? pattern)
• Expensify/App#90219 — Amount changes to negative after moving IOU to workspace (related amount display logic)

---

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.

[KJ21-ENG]

Proposal

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

After an expense in a workspace report is edited down to 0.00, the report table can later show the expense's previous/original amount instead of 0.00.

What is the root cause of that problem?

The report details table renders the required amount column through the TOTAL branch in TransactionItemRowWide.

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 536 to 544 in eaaffe3

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL: {
	const isFromExpenseReport = isExpenseReport(transactionItem.report ?? report);
	const hasConvertedAmount = transactionItem.convertedAmount != null;
	// Offline expenses don't have a BE-computed convertedAmount yet — fall back to the unconverted
	// amount in the transaction's own currency so users don't see a misleading $0.00 placeholder.
	// Pass isFromExpenseReport so IOU reports stay positive while expense reports get NewDot's signed display.
	const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);
	// When converted, display in the report's output currency; otherwise use the transaction's own currency.
	const totalCurrency = hasConvertedAmount ? (report?.currency ?? policy?.outputCurrency ?? getCurrency(transactionItem)) : getCurrency(transactionItem);

That branch treats the mere presence of transactionItem.convertedAmount as authoritative:

const hasConvertedAmount = transactionItem.convertedAmount != null;
const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);

But editing an expense amount updates modifiedAmount on the transaction. getAmount() already correctly treats a valid modifiedAmount of 0 as the display amount:

App/src/libs/TransactionUtils/index.ts

Lines 1017 to 1020 in eaaffe3

	let amount = Number(transaction?.modifiedAmount) ?? 0;
	if (hasValidModifiedAmount(transaction)) {
	return -amount;
	}

The table bypasses that logic whenever an older convertedAmount is still present, so after the report is refreshed/re-rendered by adding another expense, the row can keep displaying the stale converted/original amount instead of the edited modifiedAmount = 0.

Sorting has the same stale source for the report TOTAL column:

App/src/libs/ReportUtils.ts

Lines 13304 to 13307 in eaaffe3

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL_AMOUNT:
	return getTransactionAmount(transaction, isExpenseReport(report), transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID);
	case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
	return Math.abs(transaction.convertedAmount ?? 0);

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

Make the report table amount calculation treat modifiedAmount as newer than convertedAmount.

In TransactionItemRowWide, import/use hasValidModifiedAmount from TransactionUtils, and change the TOTAL branch so it only uses convertedAmount when there is no valid modified amount on the transaction. If modifiedAmount is present, render via getAmount(transactionItem, isFromExpenseReport) and use getCurrency(transactionItem) while the backend has not supplied a fresh converted value. This preserves the existing no-convertedAmount fallback and makes a valid edited zero display as 0.00 instead of being hidden behind stale converted data.

Also update getTransactionSortValue(..., CONST.SEARCH.TABLE_COLUMNS.TOTAL, ...) to use the same precedence, so sorting the report table does not continue to order the row by the stale original amount.

Add a focused regression test for a workspace expense transaction with an original amount/stale convertedAmount and modifiedAmount: 0, asserting that the report table total display/sort value resolves to 0.

What alternative solutions did you explore? (Optional)

Clearing convertedAmount in the amount edit optimistic update would also avoid the stale display, but that spreads a display-specific freshness rule into the mutation path and still leaves other consumers needing to know that modifiedAmount supersedes converted totals. Keeping the precedence rule in the table/sort calculation is more local and matches the existing getAmount() contract.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-18 18:59:10 UTC.

Proposal

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

After editing an expense amount to 0.00 in a workspace report, the report table row still shows the original (pre-edit) amount instead of 0.00. The regression surfaces after another expense is created in the same report (causing the table to re-render/re-sort).

What is the root cause of that problem?

The report table renders the required amount column through the TABLE_COLUMNS.TOTAL branch added in PR #86824:

src/components/TransactionItemRow/TransactionItemRowWide.tsx:538-557

const hasConvertedAmount = transactionItem.convertedAmount != null;
const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);
const totalCurrency = hasConvertedAmount ? (report?.currency ?? policy?.outputCurrency ?? getCurrency(transactionItem)) : getCurrency(transactionItem);

getConvertedAmount in src/libs/TransactionUtils/index.ts:1116-1139 reads transaction.convertedAmount directly. The backend-supplied convertedAmount is not refreshed by the optimistic edit (no modifiedConvertedAmount exists), so as long as the stale convertedAmount is present, the row displays the pre-edit value and the edited modifiedAmount: 0 is ignored.

The canonical getAmount function already does the right thing via hasValidModifiedAmount, which deliberately treats 0 as a valid edited value (only rejects undefined/null/''). Existing analog call sites — ViolationsUtils.ts:466 and MergeTransactionUtils.ts:628 — already use the hasValidModifiedAmount(t) ? Number(t.modifiedAmount) : t.amount guard. The TOTAL branch is the new outlier.

The same staleness exists in the sort path for the TOTAL column, which is what triggers the user-visible regression when a second expense is added and the table re-sorts:

src/libs/ReportUtils.ts:13300-13301

case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
    return Math.abs(transaction.convertedAmount ?? 0);

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

1. In TransactionItemRowWide.tsx:538-557, import hasValidModifiedAmount from @libs/TransactionUtils and prefer the edited amount when present:

   const isFromExpenseReport = isExpenseReport(transactionItem.report ?? report);
   const hasEditedAmount = hasValidModifiedAmount(transactionItem);
   const hasConvertedAmount = !hasEditedAmount && transactionItem.convertedAmount != null;
   const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);
   const totalCurrency = hasConvertedAmount ? (report?.currency ?? policy?.outputCurrency ?? getCurrency(transactionItem)) : getCurrency(transactionItem);

   This treats a locally edited modifiedAmount (including 0) as newer than the stale BE convertedAmount, matching the existing getAmount/hasValidModifiedAmount contract used in ViolationsUtils and MergeTransactionUtils.

2. In getTransactionSortValue (ReportUtils.ts:13300-13301), apply the same precedence so that re-sorting the table after a new expense is added doesn't order the edited row by its stale convertedAmount:

   case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
       return Math.abs(hasValidModifiedAmount(transaction) ? Number(transaction.modifiedAmount) : (transaction.convertedAmount ?? 0));

   This is required because the user's reproduction step 7 ("Create one more expense in the same report") is precisely what re-triggers sorting/rendering and exposes the stale value.

3. Add a Jest regression test for TransactionItemRowWide rendering the TOTAL column and for getTransactionSortValue(..., TOTAL, ...) with a transaction whose amount/convertedAmount are non-zero but modifiedAmount = 0, asserting both the rendered text and the sort value resolve to 0.

What alternative solutions did you explore? (Optional)

• Clearing convertedAmount in the optimistic edit action. Rejected: spreads a display-freshness rule into the mutation path and would still leave any other consumer of convertedAmount needing to know that modifiedAmount supersedes it. Keeping precedence at the render/sort site is more local and consistent with the existing getAmount contract.
• Fixing initializeAmount in MoneyRequestAmountForm.tsx (the newAmount ? ... : '' falsy check). Rejected as the root cause: the save path produces the correct modifiedAmount = 0 on the transaction (confirmed via hasValidModifiedAmount treating 0 as valid, and the screencast showing the edit persisting in other surfaces); the symptom is purely on the report-table render/sort path introduced by PR fixed custom report deploy blockers #86824.
• Replacing || with ?? across TransactionPreview, SearchUIUtils, MoneyRequestReportPreview, ReportUtils:12628, MoneyRequestBuilder:1367. Those are real bugs for 0-amount edits in their respective surfaces and worth fixing as a follow-up, but they are not the table the reporter is looking at. The table column the reporter sees is TABLE_COLUMNS.TOTAL in TransactionItemRowWide, whose stale source is convertedAmount, not a ||-vs-?? issue.

[aswin-s]

Proposal updated by depth-review — Posted proposal correctly identifies the TransactionItemRowWide TOTAL branch but misses the parallel staleness in getTransactionSortValue (ReportUtils.ts:13301), which competitor 3 correctly flags — adding a second expense re-sorts the table by Math.abs(transaction.convertedAmount ?? 0), so the edited 0 row will also sort incorrectly even if the display is fixed.

[emkhalid]

Proposal

After a user edits a workspace report expense amount to 0.00, the report table shows the expense's original non-zero amount instead of 0.00 after another expense is added to the same report. The hidden condition is that the edited transaction still has the old convertedAmount, and the table uses that stale value.

What is the root cause of that problem?

In src/components/TransactionItemRow/TransactionItemRowWide.tsx, TransactionItemRowWide() renders the report table TOTAL column by treating any existing convertedAmount as the value to display.

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 538 to 544 in 28343e0

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL: {
	const isFromExpenseReport = isExpenseReport(transactionItem.report ?? report);
	const hasConvertedAmount = transactionItem.convertedAmount != null;
	// Offline expenses don't have a BE-computed convertedAmount yet — fall back to the unconverted
	// amount in the transaction's own currency so users don't see a misleading $0.00 placeholder.
	// Pass isFromExpenseReport so IOU reports stay positive while expense reports get NewDot's signed display.
	const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);

When the amount is edited to zero, the transaction gets modifiedAmount = 0, but the old convertedAmount can remain on the transaction. Because this branch only checks transactionItem.convertedAmount != null, it calls getConvertedAmount() and displays the stale original amount instead of using getAmount(), which already respects modifiedAmount.

The same stale value is also used in src/libs/ReportUtils.ts, where getTransactionSortValue() sorts the TOTAL column with Math.abs(transaction.convertedAmount ?? 0).

App/src/libs/ReportUtils.ts

Lines 13298 to 13301 in 28343e0

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL_AMOUNT:
	return getTransactionAmount(transaction, isExpenseReport(report), transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID);
	case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
	return Math.abs(transaction.convertedAmount ?? 0);

hasValidModifiedAmount() treats 0 as a valid modified amount because it only rejects undefined, null, and ''.

App/src/libs/TransactionUtils/index.ts

Lines 633 to 638 in 28343e0

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

getAmount() already uses that helper and returns the edited zero amount, but getConvertedAmount() reads only convertedAmount.

App/src/libs/TransactionUtils/index.ts

Lines 1000 to 1026 in 28343e0

	function getAmount(transaction: OnyxInputOrEntry<Transaction>, isFromExpenseReport = false, isFromTrackedExpense = false, allowNegative = false, disableOppositeConversion = false): number {
	// IOU requests cannot have negative values, but they can be stored as negative values, let's return absolute value
	if (!isFromExpenseReport && !isFromTrackedExpense && !allowNegative) {
	const amount = Number(transaction?.modifiedAmount) ?? 0;
	if (hasValidModifiedAmount(transaction)) {
	return Math.abs(amount);
	}
	return Math.abs(transaction?.amount ?? 0);
	}
	if (disableOppositeConversion) {
	return transaction?.amount ?? 0;
	}
	// Expense report case:
	// The amounts are stored using an opposite sign and negative values can be set,
	// we need to return an opposite sign than is saved in the transaction object
	let amount = Number(transaction?.modifiedAmount) ?? 0;
	if (hasValidModifiedAmount(transaction)) {
	return -amount;
	}
	amount = transaction?.amount ?? 0;
	// To avoid -0 being shown, lets only change the sign if the value is other than 0.
	return amount ? -amount : 0;
	}

App/src/libs/TransactionUtils/index.ts

Lines 1116 to 1139 in 28343e0

	function getConvertedAmount(
	transaction: OnyxInputOrEntry<Transaction>,
	isFromExpenseReport = false,
	isFromTrackedExpense = false,
	allowNegative = false,
	disableOppositeConversion = false,
	): number {
	// IOU requests cannot have negative values, but they can be stored as negative values, let's return absolute value
	if (!isFromExpenseReport && !isFromTrackedExpense && !allowNegative) {
	return Math.abs(transaction?.convertedAmount ?? 0);
	}
	if (disableOppositeConversion) {
	return transaction?.convertedAmount ?? 0;
	}
	// Expense report case:
	// The amounts are stored using an opposite sign and negative values can be set,
	// we need to return an opposite sign than is saved in the transaction object
	const convertedAmount = transaction?.convertedAmount ?? 0;
	// To avoid -0 being shown, lets only change the sign if the value is other than 0.
	return convertedAmount ? -convertedAmount : 0;
	}

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

In src/components/TransactionItemRow/TransactionItemRowWide.tsx, update the original TOTAL branch so convertedAmount is used only when there is no valid modifiedAmount.

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 538 to 544 in 28343e0

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL: {
	const isFromExpenseReport = isExpenseReport(transactionItem.report ?? report);
	const hasConvertedAmount = transactionItem.convertedAmount != null;
	// Offline expenses don't have a BE-computed convertedAmount yet — fall back to the unconverted
	// amount in the transaction's own currency so users don't see a misleading $0.00 placeholder.
	// Pass isFromExpenseReport so IOU reports stay positive while expense reports get NewDot's signed display.
	const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);

diff --git a/src/components/TransactionItemRow/TransactionItemRowWide.tsx b/src/components/TransactionItemRow/TransactionItemRowWide.tsx
@@
     getOriginalCurrencyForDisplay,
     getReimbursable,
     getTaxName,
+    hasValidModifiedAmount,
     isDeletedTransaction as isDeletedTransactionUtil,
@@
 case CONST.SEARCH.TABLE_COLUMNS.TOTAL: {
     const isFromExpenseReport = isExpenseReport(transactionItem.report ?? report);
-    const hasConvertedAmount = transactionItem.convertedAmount != null;
+    const hasModifiedAmount = hasValidModifiedAmount(transactionItem);
+    const hasConvertedAmount = !hasModifiedAmount && transactionItem.convertedAmount != null;
     const totalAmount = hasConvertedAmount ? getConvertedAmount(transactionItem, isFromExpenseReport) : getAmount(transactionItem, isFromExpenseReport);
     const totalCurrency = hasConvertedAmount ? (report?.currency ?? policy?.outputCurrency ?? getCurrency(transactionItem)) : getCurrency(transactionItem);

This makes the displayed TOTAL use getAmount() when modifiedAmount is present, including 0, so a stale convertedAmount cannot override the edited amount.

In src/libs/ReportUtils.ts, update the original TOTAL sort branch to use the same precedence.

App/src/libs/ReportUtils.ts

Lines 13298 to 13301 in 28343e0

	case CONST.SEARCH.TABLE_COLUMNS.TOTAL_AMOUNT:
	return getTransactionAmount(transaction, isExpenseReport(report), transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID);
	case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
	return Math.abs(transaction.convertedAmount ?? 0);

diff --git a/src/libs/ReportUtils.ts b/src/libs/ReportUtils.ts
@@
     hasMissingSmartscanFields as hasMissingSmartscanFieldsTransactionUtils,
     hasNoticeTypeViolation,
     hasReceipt as hasReceiptTransactionUtils,
+    hasValidModifiedAmount,
     hasViolation,
@@
 case CONST.SEARCH.TABLE_COLUMNS.TOTAL:
-    return Math.abs(transaction.convertedAmount ?? 0);
+    return Math.abs(hasValidModifiedAmount(transaction) ? Number(transaction.modifiedAmount) : (transaction.convertedAmount ?? 0));

This keeps sorting consistent with the rendered value, so adding another expense and re-sorting the report table does not continue to order the edited row by the old amount.

What alternative solutions did you explore? (Optional)

I considered clearing or recalculating convertedAmount in the optimistic amount edit path. I rejected that because convertedAmount is backend-derived report-currency data, and recalculating it locally can be wrong for currency conversion cases. The safer fix is to keep the stale converted value from taking precedence over a valid local edit.

I also considered fixing MoneyRequestAmountForm.tsx where 0 can initialize to an empty frontend string. That is a separate zero-handling issue, but it is not the root cause here because the edit flow still submits 0 and stores modifiedAmount = 0 correctly.

Fix Video Demo

fix_edited_amount.webm