[$250] Expense - No violation when editing an existing receipt expense to a zero amount

[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: v9.3.3-0
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: #79197
Email or phone of affected tester (no customers): applausetester+im_1501.3@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari, Chrome
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com
2. Login with Expensifail account
3. Go to workspace chat
4. Create a scan expense which will be successful
5. Open the expense details
6. Edit the amount to zero

Expected Result:

The violation message appears stating that the amount is different from the smartscanned amount

Actual Result:

No violation when editing an existing receipt expense to a zero amount

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7050378_1768501562035.Recording__1274.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013064919522501250
• Upwork Job ID: 2013064919522501250
• Last Price Increase: 2026-01-26

Issue Owner

Current Issue Owner: @jjcoffee

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

Triggered auto assignment to @RachCHopkins (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.

[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: #79197 - "[BETA] Allow zero-amount expenses - ROUND 5" by @Gonals (High confidence)
Related Issues: None

Recommendation: REVERT

This PR introduced changes to allow zero-amount expenses behind the zero_expenses beta flag. However, it inadvertently broke the modifiedAmount violation that should appear when editing a receipt expense to zero if the smartscanned amount was different.

The PR author explicitly stated in the test steps that the smartscan difference violation should still appear:

"Confirm you can edit an existing receipt expense to set the amount to zero. No violation should show (beyond the amount being different to the smartscanned amount when relevant)."

Labels: Keeping DeployBlockerCash (App deploy is blocked). This is a frontend bug in the App repository.

Detailed Analysis

Evidence

PR #79197 changed the type of modifiedAmount from number (with 0 as default) to string (with ' as empty). The new hasValidModifiedAmount() function treats modifiedAmount = '0' (zero as string) as a valid modification.

However, the backend-generated modifiedAmount violation is not appearing when a receipt expense is edited to zero, even though the smartscanned amount was different. This suggests the app is not properly signaling to the backend that the amount was modified, or the zero-amount logic is interfering with violation generation.

Verification

1. PR [BETA] Allow zero-amount expenses - ROUND 5 #79197 modifies core transaction amount handling: Changed modifiedAmount type from number to string across multiple files
2. The bug is reproducible on staging: Confirmed in the issue report
3. The feature is behind a beta flag: CONST.BETAS.ZERO_EXPENSES - affects users in the beta
4. PR merge timeline: Merged on 2026-01-15, aligns with when bug appeared

Root Cause

The changes in how modifiedAmount is handled (number vs string, and how zero values are interpreted) are interfering with the backend's ability to detect that an amount was modified from the smartscanned value. The modifiedAmount violation is a backend-generated violation that should appear when the user changes the amount away from what was smartscanned, but the app's new zero-amount handling is likely preventing this signal from being sent correctly to the backend.

Key code changes in the PR:

• modifiedAmount changed from number to string type
• hasValidModifiedAmount() function treats '0' as valid, which may be causing issues with violation detection
• Multiple places now use Number(transaction.modifiedAmount) conversions