[RCA #83896] Expense - Negative amount is changed to positive amount after duplicating expense

[jponikarchuk]

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.42-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83896
Email or phone of affected tester (no customers): sdjsdjosijnsodiosd@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 negative amount.
4. Open the expense.
5. Click More > Duplicate expense.
6. Open the duplicated expense.

Expected Result:

The duplicated expense will have negative amount.

Actual Result:

The duplicated expense shows positive amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #83896

[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: #83896 - "Implement core "Duplicate report" action logic." by @Krishna2323 (High confidence)
Related Issues: None found

Recommendation: REVERT

The PR introduced a bug in the duplicate report functionality where negative expense amounts are converted to positive amounts. This is a clear regression that breaks expected behavior for duplicating negative expenses.

Labels: No label changes made (keeping DeployBlockerCash as this is a frontend bug in the App repository)

📋 Detailed Analysis

Evidence

• The issue states that duplicating an expense with a negative amount results in the duplicated expense showing a positive amount
• The bug is reproducible on staging but not production, which aligns with PR Implement core "Duplicate report" action logic. #83896 being in the current staging deploy (version 9.3.42-0)
• PR Implement core "Duplicate report" action logic. #83896 was merged on 2026-03-20 and is listed in the StagingDeployCash issue Deploy Checklist: New Expensify 2026-03-23 #86080
• The issue reporter was automatically assigned this PR by melvin-bot

Verification

• The affected code is in /home/runner/_work/App/App/src/libs/actions/IOU/Duplicate.ts
• Line 524 contains: amount: Math.abs(transactionDetails?.amount ?? 0),
• Line 525 contains: taxAmount: Math.abs(transactionDetails?.taxAmount ?? 0),
• This code is in the buildDuplicateTransactionParams function which is called by both duplicateExpenseTransaction and duplicateReport functions
• PR Implement core "Duplicate report" action logic. #83896 modified this file extensively (299 additions, 87 deletions)

Root Cause

The buildDuplicateTransactionParams function applies Math.abs() to the amount when duplicating transactions. This was likely done to ensure amounts are positive, but it incorrectly converts negative amounts (which are valid in Expensify for refunds, corrections, etc.) to positive values.

The bug occurs at line 524 in src/libs/actions/IOU/Duplicate.ts:

amount: Math.abs(transactionDetails?.amount ?? 0),

When a negative expense is duplicated, Math.abs() strips the negative sign, resulting in a positive amount in the duplicated expense.

Fix Required

Remove the Math.abs() call from the amount field (and potentially taxAmount) to preserve the original sign of the amount when duplicating.

[MelvinBot]

Proposal

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

When duplicating an expense that has a negative amount (e.g., a credit or refund), the duplicated expense shows a positive amount instead of preserving the negative sign.

What is the root cause of that problem?

The root cause is Math.abs() applied to both amount and taxAmount in buildDuplicateTransactionParams() at src/libs/actions/IOU/Duplicate.ts:524-525:

amount: Math.abs(transactionDetails?.amount ?? 0),
taxAmount: Math.abs(transactionDetails?.taxAmount ?? 0),

This was introduced in PR #83896. Here's how the sign is lost:

1. A negative expense on an expense report is stored with a positive amount in Onyx (expense reports negate amounts for storage).
2. getTransactionDetails(transaction) calls getAmount(), which negates the stored value back to a negative display amount (e.g., stored +5000 becomes -5000).
3. Math.abs() strips the negative sign, forcing it to 5000.
4. getMoneyRequestInformation() then negates again for expense report storage (-5000), which represents a normal positive expense — the credit/refund semantics are lost.

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

Remove Math.abs() from lines 524-525 of src/libs/actions/IOU/Duplicate.ts, passing the amount directly:

• amount: transactionDetails?.amount ?? 0
• taxAmount: transactionDetails?.taxAmount ?? 0

This is safe because getTransactionDetails() already returns correctly sign-corrected amounts. For non-expense-report transactions, getAmount() already applies Math.abs() internally (since "IOU requests cannot have negative values"). For expense report transactions, the sign is meaningful and should be preserved.

What alternative solutions did you explore? (Optional)

An alternative would be to call getTransactionDetails(transaction, undefined, undefined, true) with allowNegativeAmount=true and keep Math.abs(). However, this is more complex and still doesn't solve the problem — allowNegativeAmount only affects the non-expense-report code path, and the expense report path already returns the correct signed amount regardless of that flag. Simply removing Math.abs() is the minimal and correct fix.

---

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.

[Krishna2323]

Working on the PR...