[Due for payment 2026-05-13] [Due for payment 2026-05-11] [$250] Scan-The receiver is asked to fill out the missing information

[nlemma]

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.50-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/folder/13176933/test-cases/41237724
Email or phone of affected tester (no customers): agexptest+pr270326e@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

Action Performed:

1. Open the Expensify app
2. Start the Submit expense flow in a 1:1 conversation with a user you have access to
3. Select the scan option
4. Upload a picture that will fail the scan process
5. Wait for the scan to fail
6. Log in as the receiver
7. Navigate to the IOU details that failed the scan

Expected Result:

The receiver is not asked to fill out the missing information.

Actual Result:

There is a message from Concierge asking to fill out the missing information.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7115067_1774628516276.complete_missing_information.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dmkt9

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037610341320925683
• Upwork Job ID: 2037610341320925683
• Last Price Increase: 2026-03-27

[MelvinBot]

Proposal

What is the root cause of that problem?

When a SmartScan fails on a receipt in a 1:1 IOU conversation, several client-side display paths show "missing information" prompts to both the sender and the receiver, without checking whether the current user is the expense creator. There is no dedicated Concierge chat message — the "Concierge message" the reporter sees is the combination of:

1. A server-generated RECEIPTSCANFAILED report action rendered as a system message in the transaction thread (visible to both parties)
2. Client-side violation indicators (RBR, "Receipt missing details" text) on the transaction preview card shown to both parties
3. The smartscanFailed violation warning computed client-side and displayed in the expense detail view for both parties

The core problem is that hasMissingSmartscanFields() (App/src/libs/TransactionUtils/index.ts:1499) is a user-agnostic function — it purely checks whether the transaction has empty required fields (merchant, date, amount) but never checks who is viewing it. This function is used directly in:

• TransactionPreviewUtils.ts:399,424,427 — hasFieldErrors feeds into shouldShowRBR, which controls the red error indicator on the transaction card in the chat. Both sender and receiver see this.
• ReportUtils.ts:5251 — getTransactionReportName() returns "Receipt missing details" for any viewer when fields are missing.
• MoneyRequestView.tsx:555 — The expense detail page shows field-level errors ("Missing merchant name") to both parties.

Notably, the LHN (Left Hand Navigation) sidebar RBR dot does correctly gate on wasActionTakenByCurrentUser() at App/src/libs/ReportUtils.ts:5203, so only the sender sees the red dot in the sidebar. But this pattern was never applied to the transaction preview card or the report name.

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

Add a sender/owner check to the display paths that show scan failure indicators to the receiver:

1. In TransactionPreviewUtils.ts — In createTransactionPreviewConditionals, gate hasFieldErrors on the current user being the expense creator for IOU reports. When computing hasErrorOrOnHold, only include hasFieldErrors if the current user is the action creator (similar to how getReportActionWithMissingSmartscanFields uses wasActionTakenByCurrentUser at ReportUtils.ts:5203). This will prevent the receiver from seeing the RBR indicator on the transaction card.

2. In ReportUtils.ts:5251 — In getTransactionReportName(), add a check for whether the current user is the expense creator before returning translate('iou.receiptMissingDetails'). For non-creators, fall through to the normal transaction name display.

3. In MoneyRequestView.tsx:555 — Gate the hasErrors value on the current user being the expense creator for IOU reports, so field-level error messages (e.g., "Missing merchant name") aren't shown to the receiver.

The RECEIPTSCANFAILED system message in the transaction thread (PureReportActionItem.tsx:1680) may also need adjustment — the smartscanFailed violation message already has a canEdit parameter that suppresses "Enter details manually" when the user cannot edit (App/src/languages/en.ts:8025), so this same pattern could be applied more broadly.

What alternative solutions did you explore? (Optional)

An alternative would be to handle this server-side by not pushing the RECEIPTSCANFAILED report action to the receiver's transaction thread at all, or by adding a whisper-like mechanism so only the sender sees it. However, the client-side approach is more consistent with existing patterns (the LHN already uses wasActionTakenByCurrentUser for this exact purpose) and doesn't require backend changes.

---

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 - @dmkt9 (External)

[melvin-bot]

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

[abbasifaizan70]

Proposal

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

When a submitter creates a scan expense in a 1:1 chat and the SmartScan fails, the receiver later opens the IOU details and sees a Concierge/system message telling them to fill in missing expense information.

Expected result: only the submitter (the person who can complete that expense) is prompted to enter missing fields.
Actual result: the receiver also sees a "please enter details manually" prompt.

What is the root cause of that problem?

RECEIPT_SCAN_FAILED actions are rendered with a static translation in PureReportActionItem.tsx, so the text always asks to enter details manually, regardless of who is viewing the report action.

App/src/pages/inbox/report/PureReportActionItem.tsx

Lines 1680 to 1682 in 2eaa12f

	} else if (isActionOfType(action, CONST.REPORT.ACTIONS.TYPE.RECEIPT_SCAN_FAILED)) {
	children = <ReportActionItemBasicMessage message={translate('iou.receiptScanningFailed')} />;
	} else if (isRenamedAction(action)) {

The static message key is iou.receiptScanningFailed, which includes manual-entry instructions for everyone.

App/src/languages/en.ts

Line 1326 in 2eaa12f

receiptScanningFailed: 'Receipt scanning failed. Please enter the details manually.',

There is already a role-aware translation path (violations.smartscanFailed) that supports {canEdit}, but it is not used in this report action rendering branch.

App/src/languages/en.ts

Line 8025 in 2eaa12f

brokenConnection530Error: 'Receipt pending due to broken bank connection',

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

Update the RECEIPT_SCAN_FAILED rendering branch to use role-aware copy instead of unconditional instruction text.

App/src/pages/inbox/report/PureReportActionItem.tsx

Lines 1680 to 1682 in 2eaa12f

	} else if (isActionOfType(action, CONST.REPORT.ACTIONS.TYPE.RECEIPT_SCAN_FAILED)) {
	children = <ReportActionItemBasicMessage message={translate('iou.receiptScanningFailed')} />;
	} else if (isRenamedAction(action)) {

} else if (isActionOfType(action, CONST.REPORT.ACTIONS.TYPE.RECEIPT_SCAN_FAILED)) {
    const canEditFailedScanDetails = wasActionTakenByCurrentUser(action);
    children = <ReportActionItemBasicMessage message={translate('violations.smartscanFailed', {canEdit: canEditFailedScanDetails})} />;
}

This keeps the instruction for the submitter while removing the misleading "enter details manually" ask for the receiver.

[trasnake87]

Proposal

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

When a SmartScan fails on a receipt in a 1:1 IOU, the receiver (not the sender) sees the "Receipt scanning failed" violation and RBR indicator, implying they should fix the missing information — but only the sender can edit the expense.

What is the root cause of that problem?

The centralized violation-visibility gatekeeper shouldShowViolation() has explicit per-user rules for RTER, RECEIPT_NOT_SMART_SCANNED, OVER_AUTO_APPROVAL_LIMIT, and others, but is missing a rule for SMARTSCAN_FAILED. It falls through to return true, making the violation visible to everyone. Since useTransactionViolations filters all violations through shouldShowViolation before passing them to TransactionPreview, MoneyRequestView, and MoneyRequestReceiptView, this single omission propagates the smartscan-failed violation to the receiver across all display paths.

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

Add a SMARTSCAN_FAILED rule to shouldShowViolation in src/libs/TransactionUtils/index.ts that restricts the violation to the expense submitter only — the same pattern already used for RTER. This is a single-line fix that cascades through all consumers of useTransactionViolations.

--- a/src/libs/TransactionUtils/index.ts
+++ b/src/libs/TransactionUtils/index.ts
@@ -1708,6 +1708,10 @@ function shouldShowViolation(
         return false;
     }
 
+    if (violationName === CONST.VIOLATIONS.SMARTSCAN_FAILED) {
+        return isSubmitter;
+    }
+
     return true;
 }

This is safe because the server already validates who can edit a transaction — this change only affects client-side display. The isSubmitter variable (line 1684) uses isCurrentUserSubmitter(iouReport) which checks report.ownerAccountID === currentUserAccountID, correctly identifying the expense creator in a 1:1 IOU.

What alternative solutions did you explore? (Optional)

Adding owner checks to each individual display path (TransactionPreviewUtils, ReportUtils.getTransactionReportName, MoneyRequestView) as separate guards — but that requires changes across 3+ files and risks missing future display paths, whereas the shouldShowViolation approach is the canonical single-point filter already used for other violation types.

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

[twilight2294]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.