[$250] Exported Report Applies Incorrect Currency Conversion to Manually Entered CAD Amount

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Needs subscription/card transaction)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @MitchExpensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Created a new expense for an Expensify subscription billed at $45.00 USD.
2. Credit card was charged C$62.85.
3. Manually entered C$62.85 as the expense amount (to match the actual credit card charge).
4. Attached the receipt showing the $45.00 USD billing amount.
5. Saved the expense to a report.
6. Exported the report to a spreadsheet.

Expected Result:

The exported report should display C$62.85, exactly matching the manually entered amount and the credit card charge. No additional currency conversion or tax recalculation should occur during export.

Actual Result:

The exported report displays the amount as C$85.63 instead of C$62.85. The system appears to convert the manually entered amount, resulting in an inflated exported value. A warning message also appears stating “Amount greater than scanned receipt,” suggesting the system is misinterpreting the entered currency and applying unintended conversion logic.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mananjadhav

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026671002416409575
• Upwork Job ID: 2026671002416409575
• Last Price Increase: 2026-02-25

[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.

[MelvinBot]

🔍 Issue Analysis

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

When a user manually enters an expense amount in a different currency (C$62.85 CAD) than the SmartScanned receipt ($45.00 USD), two problems occur:

1. A "Amount greater than scanned receipt" violation is triggered, even though C$62.85 is the correct CAD equivalent of $45 USD.
2. On export, the amount is inflated to C$85.63 — which appears to be the manually entered C$62.85 re-converted from USD→CAD (62.85 × ~1.362 ≈ 85.63), as if the system ignores the modifiedCurrency and treats the entered amount as still being in the original receipt currency (USD).

What is the root cause of that problem?

The root cause is server-side — the backend violation generation and/or export logic does not properly account for currency differences between the SmartScanned receipt and the user's manual edit.

Evidence from App codebase:

1. The modifiedAmount violation is entirely backend-generated. The client-side ViolationsUtils.getViolationsOnyxData() at src/libs/Violations/ViolationsUtils.ts:288-631 handles many violation types (overLimit, receiptRequired, missingCategory, etc.) but never creates or modifies the modifiedAmount violation. It comes from the backend response to UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY.

2. The Transaction stores original and modified values separately. When a receipt is scanned, results go to amount/currency. When a user edits, new values go to modifiedAmount/modifiedCurrency (src/libs/TransactionUtils/index.ts:699-706). Both fields are correctly sent to the server.

3. Client-side violations DO have a currency guard, but it only applies to client-generated violations:

   const canCalculateAmountViolations = policy.outputCurrency === currency;
   

   (src/libs/Violations/ViolationsUtils.ts:413). Since modifiedAmount is server-generated, this guard is irrelevant.

4. The violation data has no currency fields — only type and displayPercentVariance (src/types/onyx/TransactionViolation.ts:80-84). This strongly suggests the backend naively compares raw amounts (|6285| > |4500| → violation) without currency conversion.

5. The export math confirms the bug: C$62.85 × ~1.362 (USD→CAD rate) ≈ C$85.63. The system appears to take the user-entered 62.85, treat it as USD (the receipt currency), and re-convert it to CAD — indicating the backend ignores modifiedCurrency during export amount resolution.

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

Since the root cause is in the backend (Auth or Web-Expensify), not in the App:

1. Violation generation fix (backend): When generating the modifiedAmount violation for SmartScanned receipts, the server should check if modifiedCurrency differs from currency. If the currencies differ, it should either skip the violation or convert both amounts to a common currency before comparing.

2. Export amount fix (backend): When resolving the amount for export, the server should use modifiedAmount + modifiedCurrency together. If the user changed the currency via modifiedCurrency, the export should use the modifiedAmount in modifiedCurrency directly — not re-convert the modifiedAmount using the original receipt's currency.

Note: The App codebase correctly sends both modifiedAmount and modifiedCurrency to the server (via UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY). The bug is in how the backend processes these values. This requires investigation of the backend violation generation and export logic in the Auth/Web-Expensify repos.

What alternative solutions did you explore? (Optional)

• Client-side pre-flight check: The App could skip sending the violation display when it detects the modifiedCurrency differs from the transaction's currency on a modifiedAmount violation. However, this would only hide the symptom — the export amount issue would remain, and the violation would still be generated server-side.
• Client-side currency normalization before sending: The App could convert the entered amount to the receipt's currency before sending to the server. This would prevent the violation but lose the user's intent of recording the expense in their local currency.

Detailed Investigation

Data Flow

1. SmartScan scans receipt → sets transaction.amount = -4500 ($45.00 USD), transaction.currency = "USD"
2. User manually edits → transaction.modifiedAmount = -6285 (C$62.85), transaction.modifiedCurrency = "CAD"
3. App calls updateMoneyRequestAmountAndCurrency() → sends UPDATE_MONEY_REQUEST_AMOUNT_AND_CURRENCY to server
4. Server compares modifiedAmount (6285) vs amount (4500) — likely naively comparing raw numbers without currency conversion
5. Server generates modifiedAmount violation with type='smartscan' and displayPercentVariance
6. On export, server appears to use modifiedAmount (6285) but treats it as being in currency (USD) rather than modifiedCurrency (CAD), then converts to CAD → C$85.63

Evidence Chain

• Violation is backend-only: Confirmed by exhaustive review of getViolationsOnyxData() — it handles 15+ violation types but never touches modifiedAmount
• Currency data is correctly sent: getUpdatedTransaction() at TransactionUtils/index.ts:699-706 correctly sets both modifiedAmount and modifiedCurrency
• Export math confirms currency confusion: C$62.85 × 1.362 ≈ C$85.63 — the system re-converts the CAD amount as if it were USD

Relevant Code

• src/libs/TransactionUtils/index.ts:667-706 - getUpdatedTransaction sets modified fields
• src/libs/Violations/ViolationsUtils.ts:288-631 - Client-side violations (does NOT generate modifiedAmount)
• src/libs/Violations/ViolationsUtils.ts:409-413 - Currency guard for client-side violations
• src/libs/actions/IOU/index.ts:8558-8611 - updateMoneyRequestAmountAndCurrency sends to server
• src/types/onyx/Transaction.ts:438-578 - Transaction type with amount/modified/original fields
• src/types/onyx/TransactionViolation.ts:80-84 - Violation data structure (no currency fields)
• src/languages/en.ts:7670-7681 - Violation translation text

---

Next Steps for Contributor+ team: This is a backend bug in Auth/Web-Expensify. The App correctly sends modifiedAmount and modifiedCurrency to the server — the server-side violation generation and export amount resolution need to be fixed to handle cross-currency edits. Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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