Scan - Fix displays on LHN when submit report having expense edit the amount higher than receipt

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.48-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: https://test-management.browserstack.com/projects/2219752/test-runs/67224479/folder/13176933/41237702/1622117723?sort=-identifier
Email or phone of affected tester (no customers): lekima20+631407@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create a workspace setting Submissions manually
• Navigate to the workspace chat create a scan expense then crop the receipt

1. Open https://staging.new.expensify.com
2. Navigate to the workspace chat
3. Create another scan expense
4. After scanning completed, edit the amount higher than receipt
5. Submit the report

Expected Result:

Verify a RBR is NOT displayed in the LHN but it does display in the expense page when the report is in Outstanding state (submitted)

Actual Result:

Fix is displayed in the LHN

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7223331_1785575998660.Recording__2361.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7223331

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022083874072008394810
• Upwork Job ID: 2083874072008394810
• Last Price Increase: 2026-08-02

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/de6a707aec23d4d16974e425c28a3e312879d87eebe29892f8dbab2f1e75c569

[MelvinBot]

Proposal

What is the root cause of that problem?

Editing a scanned expense's amount higher than the receipt attaches a modifiedAmount transaction violation ("Amount greater than scanned receipt"). The LHN red-brick-road (RBR) decision for the submitter is made in getViolatingReportIDForRBRInLHN.

That function already has logic that is meant to suppress the modifiedAmount RBR in the LHN once the report is submitted/processing (i.e. Outstanding) — ReportUtils.ts:9461:

const excludedNoticeNamesForLHN = isProcessingReport(potentialReport) ? [CONST.VIOLATIONS.MODIFIED_AMOUNT] : [];

But that exclusion list is passed only to the notice-type branch (hasNoticeTypeViolationsForRBRInLHN). The RBR also fires from the hasViolations (type violation) and hasWarningTypeViolations (type warning) branches, which get no exclusion. Because the "amount higher than receipt" modifiedAmount violation is a violation/warning type (not notice), it slips past the suppression and the RBR wrongly persists in the submitter's LHN after submission. It still correctly shows on the expense page.

Why the type is violation/warning, not notice

The bug reproduces on staging, and staging matches current HEAD where the 9461 notice-exclusion already exists. If this violation were notice-typed it would already be suppressed. modifiedAmount can carry any of the three types (its type is assigned by the backend), and the expense-page logic in TransactionPreviewUtils.ts explicitly treats MODIFIED_AMOUNT as VIOLATION-or-NOTICE. Existing tests (ReportUtilsTest.ts ~L15475) only cover the notice case, which is why the gap was missed.

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

Apply the same MODIFIED_AMOUNT exclusion (for processing reports) to all three violation-type branches in getViolatingReportIDForRBRInLHN, not just the notice branch. Concretely, mirror the excludedViolationNames filtering that hasNoticeTypeViolationsForRBRInLHN already does for the hasViolations and hasWarningTypeViolations branches so a modifiedAmount violation of any type is stripped from the LHN RBR check once the report isProcessingReport. Add unit tests covering modifiedAmount with violation and warning types (submitted report ⇒ no LHN RBR) alongside the existing notice test.

What alternative solutions did you explore? (Optional)

Filter MODIFIED_AMOUNT out of the transaction violations once (before all three branch checks) when the report is processing, rather than threading an exclusion list through each helper — same effect, less duplication.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97647) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: When a scanned expense's amount is edited higher than the receipt, the server sends a modifiedAmount violation with type = VIOLATION; the LHN exclusion added in PR #88230 (excludedNoticeNamesForLHN) only filters NOTICE-type violations in hasNoticeTypeViolationsForRBRInLHN, leaving the VIOLATION-type modifiedAmount to pass through hasViolations and incorrectly trigger the RBR in LHN for submitted reports.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES