[$250] 86774-Scan-RBR is displayed in LHN in the submitted state if the higher amount violation is present

[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: v9.3.51-7
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/folder/13176933/test-cases/41237702
Email or phone of affected tester (no customers): agexptest+pr010426e@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Money Requests
Slack conversation (hyperlinked to channel name): #QA channel

Action Performed:

Preconditions: User is a workspace employee who has at least one smartscanned expense.

1. Go to https://staging.new.expensify.com/
2. Log in as a workspace employee
3. Go to the workspace chat
4. Go to the expense details
5. Edit the amount so it's higher than the scanned account
6. Submit the scan expense

Expected Result:

RBR is not displayed in the LHN but it does display in the expense page when the report is in the Outstanding state (submitted).

Actual Result:

RBR is displayed in the LHN if a "higher amount" violation is present.

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

Bug7119440_1775087884396.RBR_in_LHN_-_scan_receipt.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @KJ21-ENG

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039498000122243608
• Upwork Job ID: 2039498000122243608
• Last Price Increase: 2026-04-02

[MelvinBot]

Proposal

What is the root cause of that problem?

The modifiedAmount violation (displayed as "Amount greater than scanned receipt") is a NOTICE-type violation with showInReview: true set by the backend. The LHN RBR indicator is controlled by getViolatingReportIDForRBRInLHN, which intentionally allows both open and processing (submitted) reports to show RBR (line 9251-9253):

// Allow both open and processing reports to show RBR for violations
if (!isOpenOrProcessingReport(potentialReport)) {
    return false;
}

A submitted report is classified as "processing" via isProcessingReport (stateNum=SUBMITTED, statusNum=SUBMITTED), so it passes this gate.

The function then checks three violation paths (lines 9266-9295): hasViolations (type VIOLATION), hasWarningTypeViolations (type WARNING), and hasNoticeTypeViolations (type NOTICE) — all with showInReview=true. The modifiedAmount NOTICE violation matches hasNoticeTypeViolations and passes through.

Additionally, shouldShowViolation (called via hasVisibleViolationsForUser) has special-case filtering for violations like RECEIPT_NOT_SMART_SCANNED, OVER_AUTO_APPROVAL_LIMIT, and RTER, but has no special case for MODIFIED_AMOUNT — it falls through to return true at line 1716 regardless of report state.

The result: when a user edits a SmartScanned expense to a higher amount and submits it, the modifiedAmount NOTICE violation passes all gates and causes RBR to appear in the LHN for the submitted report.

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

Add a condition in shouldShowViolation for MODIFIED_AMOUNT that returns false when the report is no longer open (i.e., when it has been submitted/is processing). This mirrors the pattern already used for other violations like RECEIPT_NOT_SMART_SCANNED (line 1704-1706).

In src/libs/TransactionUtils/index.ts, before return true at line 1716, add:

if (violationName === CONST.VIOLATIONS.MODIFIED_AMOUNT) {
    return isReportOpen;
}

This ensures the modifiedAmount violation only triggers RBR in the LHN when the report is still open (editable by the submitter). Once submitted, the violation remains visible on the expense details page (which uses separate display logic in TransactionPreviewUtils) but no longer propagates to the LHN RBR indicator.

What alternative solutions did you explore? (Optional)

1. Modifying getViolatingReportIDForRBRInLHN to exclude notice-type violations for processing reports — this would skip hasNoticeTypeViolations entirely when the report is submitted. However, this is too broad and could suppress other legitimate notice-type violations that should still show RBR in LHN for submitted reports.

2. Backend fix to set showInReview: false — the backend could stop setting showInReview: true on modifiedAmount violations for submitted reports. However, this property may be needed for the approver's review view, and the frontend is the right place to control LHN-specific display.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

After increasing a SmartScanned expense amount and submitting the expense report, the LHN still shows a red-brick-road violation indicator for that submitted report. Expected behavior is: the violation remains visible in expense details, but LHN should not keep RBR for this submitted-state “higher amount than scanned receipt” case.

What is the root cause of that problem?

LHN RBR uses a broad violation gate that still allows submitted (processing) reports and includes notice-type violations, so modifiedAmount continues to qualify after submit.

shouldDisplayViolationsRBRInLHN() explicitly allows both open and processing reports:

App/src/libs/ReportUtils.ts

Lines 9011 to 9013 in 1d43910

	// Allow both open and processing reports to show RBR for violations
	if (!isOpenOrProcessingReport(potentialReport)) {
	return false;

It then includes notice-type violations in the LHN decision:

App/src/libs/ReportUtils.ts

Lines 9046 to 9055 in 1d43910

	hasNoticeTypeViolations(
	potentialReport.reportID,
	transactionViolations,
	currentUserAccountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserEmail ?? '',
	true,
	transactions,
	potentialReport,
	policy,
	))

modifiedAmount visibility is not specially filtered for processing reports in shouldShowViolation() (it falls through to default true), so it remains a visible violation signal for LHN checks:

App/src/libs/TransactionUtils/index.ts

Lines 1673 to 1710 in 1d43910

	function shouldShowViolation(
	iouReport: OnyxEntry<Report>,
	policy: OnyxEntry<Policy>,
	violationName: ViolationName,
	currentUserEmail: string,
	shouldShowRterForSettledReport = true,
	transaction?: OnyxEntry<Transaction>,
	): boolean {
	const isSubmitter = isCurrentUserSubmitter(iouReport);
	const isPolicyMember = isPolicyMemberPolicyUtils(policy, currentUserEmail);
	const isReportOpen = isOpenExpenseReport(iouReport);
	const isAttendeeTrackingEnabled = policy?.isAttendeeTrackingEnabled ?? false;
	if (violationName === CONST.VIOLATIONS.AUTO_REPORTED_REJECTED_EXPENSE) {
	return isSubmitter || isPolicyAdmin(policy);
	}
	if (violationName === CONST.VIOLATIONS.OVER_AUTO_APPROVAL_LIMIT) {
	return isPolicyAdmin(policy) && !isSubmitter && isProcessingReport(iouReport);
	}
	if (violationName === CONST.VIOLATIONS.RTER) {
	return (isSubmitter || isInstantSubmitEnabled(policy)) && (shouldShowRterForSettledReport || !isSettled(iouReport));
	}
	if (violationName === CONST.VIOLATIONS.RECEIPT_NOT_SMART_SCANNED) {
	return isPolicyMember && !isSubmitter && !isReportOpen;
	}
	if (violationName === CONST.VIOLATIONS.MISSING_ATTENDEES) {
	return isAttendeeTrackingEnabled;
	}
	if (violationName === CONST.VIOLATIONS.MISSING_CATEGORY && isCategoryBeingAnalyzed(transaction)) {
	return false;
	}
	return true;

Media confirms this path: after submit, expense status is Outstanding and the same report tile in LHN still shows the RBR dot.

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

1. Add a targeted LHN-only exclusion for MODIFIED_AMOUNT when report state is processing/submitted, instead of globally hiding that violation.
2. Implement this in shouldDisplayViolationsRBRInLHN() by filtering out modifiedAmount from the notice-type branch for processing reports.
3. Keep expense-details violation rendering unchanged (so users still see “Amount greater than scanned receipt” on the transaction/report details page).
4. Add regression coverage for: edit SmartScanned amount higher -> submit -> verify no LHN RBR for that submitted report while expense details still show the violation.

What alternative solutions did you explore? (Optional)

• A global rule in shouldShowViolation() to hide modifiedAmount for non-open reports would also remove it from screens that should still display the warning.
• A backend showInReview change is broader and risks affecting approver/review flows. A scoped LHN-side filter is safer and aligned with the expected behavior split.

[trasnake87]

Proposal

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

When a smartscanned expense has its amount manually edited to a higher value, a modifiedAmount NOTICE violation appears. After submitting the report, this NOTICE violation incorrectly causes the RBR (red brick road) indicator to appear in the LHN, even though NOTICE violations on submitted reports should only appear on the expense detail page, not in the LHN.

What is the root cause of that problem?

The root cause is in ViolationsUtils.hasVisibleViolationsForUser at https://github.com/Expensify/App/blob/main/src/libs/Violations/ViolationsUtils.ts#L869-L896. This function determines whether a report has violations visible to the current user, and it is a required gate for the LHN RBR indicator (called from getViolatingReportIDForRBRInLHN). However, it does not account for the report's state when evaluating NOTICE-type violations. For processing (submitted) reports, NOTICE violations like modifiedAmount are informational and should not drive RBR in the LHN. The function currently treats all non-dismissed violations equally regardless of report state and violation severity type.

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

We should update hasVisibleViolationsForUser in src/libs/Violations/ViolationsUtils.ts to exclude NOTICE-type violations for processing (submitted) reports. This ensures that informational notices don't trigger the RBR indicator in the LHN after submission, while still allowing them to appear on the expense detail page through other code paths.

hasVisibleViolationsForUser(
    report: OnyxEntry<Report>,
    violations: OnyxCollection<TransactionViolation[]>,
    currentUserEmail: string,
    currentUserAccountID: number,
    policy: OnyxEntry<Policy>,
    transactions: Transaction[],
): boolean {
    if (!report || !violations || !transactions) {
        return false;
    }

    const isProcessing = report?.stateNum === CONST.REPORT.STATE_NUM.SUBMITTED && report?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED;

    return transactions.some((transaction) => {
        const transactionViolations = violations[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`];
        if (!transactionViolations) {
            return false;
        }

        return transactionViolations.some((violation: TransactionViolation) => {
            // For processing (submitted) reports, NOTICE-type violations are informational
            // and should not drive RBR in the LHN
            if (isProcessing && violation.type === CONST.VIOLATION_TYPES.NOTICE) {
                return false;
            }

            return (
                !isViolationDismissed(transaction, violation, currentUserEmail, currentUserAccountID, report, policy) &&
                shouldShowViolation(report, policy, violation.name, currentUserEmail, true, transaction)
            );
        });
    });
},

This fix is minimal and targeted: it adds a single condition check at the point where violations are evaluated for LHN visibility, filtering NOTICE violations for submitted reports without affecting how they display on expense detail pages.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!