[$250] Expense - Receipt error on failed scanned expense can´t be dismissed.

[applause-bot]

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: 9.3.89-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90879
Email or phone of affected tester (no customers): ibellicotest+2723@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has a workspace.

1. Open the staging.new.expxensify.com website.
2. Navigate to workspace chat.
3. Create a scan expense and add a receipt to it that will make the request fail.
4. While expense is still scanning, open the report.
5. Wait until scanning finishes.
6. Note that request error is triggered, but user has no way to dismiss it.

Expected Result:

User should be able to dismiss error on failed scan expense and transaction thread should be deleted.

Actual Result:

There is no option to dismiss error triggered by failed scan expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165996_1780023083418.Scan_Fail.1.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060330160828943358
• Upwork Job ID: 2060330160828943358
• Last Price Increase: 2026-05-29

[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/6d8aaeb4fcc0df13ad2012b9df51e9199f3347f48035145c65af3be2a1233259

[MelvinBot]

Proposal

What is the root cause of that problem?

When a server-side SmartScan resolves to failed (receipt.state = SCANFAILED), the failure is surfaced only as a transaction violation (SMARTSCAN_FAILED) rendered by ReceiptAuditMessages — which is plain text with no dismiss / X / button.

The dismiss UI in the transaction thread (the X / "Save receipt" / "Delete expense" buttons inside MoneyRequestReceiptView) is gated on the errors prop coming from the fallbackReceiptError memo, which only reads transaction.errors / parentReportAction.errors / reportCreationError. Those are populated only by the upload / Create API failureData path in MoneyRequestBuilder — i.e. when the create request fails. They are not written when the upload succeeded but the SmartScan later failed server-side. Result: errors = {}, so the dismiss UI never renders.

Two secondary gates reinforce this:

• MessagesRow hides the X whenever the error type is a receipt error (it expects DotIndicatorMessage to render replacement buttons), but DotIndicatorMessage only renders those buttons when a RECEIPT_ERROR exists in messages — which, again, is never the case for SCANFAILED.
• ErrorUtils.getLatestErrorMessageField strips receipt errors from the action-wrapper OfflineWithFeedback in PureReportActionItem, so no X appears on the IOU action either.

PR #90879 (caught the regression during QA) only refactored what happens after dismiss is clicked (cleanUpMoneyRequest now receives transactionThreadReport) — it did not touch the rendering gate. The dismiss button was already missing on this path before #90879.

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

Broaden the fallbackReceiptError memo in MoneyRequestReceiptView.tsx:319-358 so it emits a synthetic CONST.IOU.RECEIPT_ERROR whenever transaction.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED, even if transaction.errors / parentReportAction.errors are empty.

This wires SCANFAILED into the existing dismiss pipeline that PR #90879 just finished refactoring:

1. OfflineWithFeedback renders the dismiss UI (X + "Save receipt" / "Delete expense").
2. The X invokes the existing dismissReceiptError handler, which calls cleanUpMoneyRequest(..., transactionThreadReport) — already the behavior the user expects (transaction thread deleted, parent updated).

One thing to confirm during implementation: the cleanUpMoneyRequest branch in dismissReceiptError is gated on transaction.pendingAction === ADD. A SCANFAILED transaction may have pendingAction = null by the time the user sees the error, in which case the fallback branch (clearError + clearAllRelatedReportActionErrors) runs but does not delete the transaction thread. The QA expectation is thread deletion, so the dismiss handler should also call cleanUpMoneyRequest when SCANFAILED is the sole reason, regardless of pendingAction.

What alternative solutions did you explore? (Optional)

• Give ReceiptAuditMessages its own inline dismiss + delete CTAs for the SCANFAILED violation. Rejected: duplicates a UI flow that already exists in MoneyRequestReceiptView's OfflineWithFeedback, and would need its own cleanup path.
• Inject RECEIPT_ERROR into transaction.errors server-side / in the success handler when the API response carries receipt.state = SCANFAILED. More invasive (touches Onyx-update code paths in MoneyRequestBuilder / IOU.ts) and risks affecting unrelated flows like the chat preview red-brick-road.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92070) 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 - @huult (External)

[wildan-m]

Proposal

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

When a scanned (SmartScan) expense's create request fails, the failed expense shows a receipt error in the expense report, but the user has no way to dismiss it. The expected behavior is that the user can dismiss the error on the failed scan expense and the transaction thread is deleted.

What is the root cause of that problem?

When a scan request fails, the optimistic transaction (and the linked IOU report action) is given a receipt error (CONST.IOU.RECEIPT_ERROR) in the request's failureData:

App/src/libs/actions/IOU/MoneyRequestBuilder.ts

Lines 983 to 1010 in 92b1883

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
	value: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	pendingFields: clearedPendingFields,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iou.report.reportID}`,
	value: {
	...(shouldCreateNewMoneyRequestReport
	? {
	[iou.createdAction.reportActionID]: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	},
	[iou.action.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.genericCreateFailureMessage'),
	},
	}
	: {
	[iou.action.reportActionID]: {
	errors: getReceiptError(transaction.receipt, transaction.receipt?.filename, isScanRequest, errorKey, CONST.IOU.ACTION_PARAMS.MONEY_REQUEST, retryParams),
	},
	}),
	},
	},

This receipt error is meant to be surfaced through OfflineWithFeedback → ErrorMessageRow → MessagesRow → DotIndicatorMessage. For receipt errors, the regular dismiss "X" is intentionally suppressed and the dismiss action is delegated to a dedicated DotIndicatorMessage, which renders a "Save receipt" button and a "Delete expense" button:

App/src/components/MessagesRow.tsx

Lines 44 to 45 in 92b1883

	const hasReceiptUploadError = Object.values(messages).some((message) => isReceiptError(message));
	const showDismissButton = !!onDismiss && !hasReceiptUploadError;

App/src/components/DotIndicatorMessage.tsx

Lines 110 to 126 in 92b1883

	const buttonsRow = (
	<View style={[styles.flexRow, styles.gap3]}>
	<Button
	small
	text={translate('iou.error.saveReceipt')}
	onPress={() => {
	fileDownload(translate, receiptError.source, receiptError.filename);
	}}
	/>
	<Button
	small
	danger
	text={translate('iou.deleteExpense', {count: 1})}
	onPress={dismissError}
	/>
	</View>
	);

The "Delete expense" button is the dismiss control — it calls dismissError, which deletes the failed expense and its transaction thread.

In the transaction thread, MoneyRequestReceiptView passes the receipt error to OfflineWithFeedback, so the "Delete expense" dismiss button renders correctly there. But when the user opens the expense report, the failed expense is rendered by PureReportActionItem, and the errors it passes to OfflineWithFeedback come from getLatestErrorMessageField(action):

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

Line 563 in 92b1883

errors={(linkedTransactionRouteError ?? !isOnSearch) ? getLatestErrorMessageField(action as OnyxDataWithErrors) : {}}

getLatestErrorMessageField intentionally filters out receipt errors:

App/src/libs/ErrorUtils.ts

Lines 102 to 127 in 92b1883

	function getLatestErrorMessageField<TOnyxData extends OnyxDataWithErrors>(onyxData: OnyxEntry<TOnyxData>): Errors {
	const errors = onyxData?.errors ?? {};
	if (isEmptyValueObject(errors)) {
	return {};
	}
	// Receipt errors are handled separately by MoneyRequestReceiptView and DotIndicatorMessage
	// and should never surface as a generic text error via this utility.
	const filteredKeys = Object.keys(errors)
	.filter((k) => !isReceiptError(errors[k]))
	.sort()
	.reverse();
	const key = filteredKeys.at(0) ?? '';
	if (!key) {
	return {};
	}
	const currentLocale = IntlStore.getCurrentLocale();
	if (errors[key] === CONST.ERROR.BANK_ACCOUNT_SAME_DEPOSIT_AND_WITHDRAWAL_ERROR) {
	return {key: translate(currentLocale, 'bankAccount.error.sameDepositAndWithdrawalAccount')};
	}
	return {key: errors[key]};
	}

Because the receipt error is filtered out, the errors object passed to OfflineWithFeedback is empty, so MessagesRow/DotIndicatorMessage never render in the report-action context, and the "Delete expense" dismiss button is never shown. The user therefore sees the failed scan expense but has no way to dismiss it from the report.

Note that the dismiss handler itself is already fully wired in PureReportActionItem — dismissError calls cleanUpMoneyRequest, which deletes the transaction thread (exactly the expected result). Only the affordance to trigger it is missing because the receipt error is filtered out before it can reach the UI.

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

Lines 234 to 246 in 92b1883

	const dismissError = () => {
	const transactionID = isMoneyRequestAction(action) ? getOriginalMessage(action)?.IOUTransactionID : undefined;
	if (isSendingMoney && transactionID && reportID) {
	cleanUpMoneyRequest(transactionID, action, reportID, transactionThreadReport, report, chatReport, undefined, originalReportID, true);
	return;
	}
	if (action.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD && isReportActionLinked) {
	navigation.setParams({reportActionID: ''});
	}
	if (transactionID) {
	clearError(transactionID);
	}
	clearAllRelatedReportActionErrors(reportID, action, originalReportID);

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

In PureReportActionItem, when the report action is a money-request action that carries receipt errors, include those receipt errors in the errors passed to the wrapping OfflineWithFeedback (in addition to the filtered generic message from getLatestErrorMessageField). Concretely:

• Compute the receipt errors from the action's own errors (the entries for which isReceiptError is true), scoped to money-request actions.
• Pass {...getLatestErrorMessageField(action), ...receiptErrors} as the errors prop of the OfflineWithFeedback at the line referenced above, instead of only the receipt-filtered result.

This makes MessagesRow → DotIndicatorMessage render the receipt-error UI with its "Save receipt" and "Delete expense" buttons in the expense report, mirroring the transaction-thread behavior. The "Delete expense" button is wired to the existing dismissError handler, which calls cleanUpMoneyRequest and deletes the transaction thread — matching the expected result.

This change is intentionally scoped to money-request actions, so it does not alter the generic behavior of getLatestErrorMessageField (which is relied on by other callers to avoid surfacing receipt errors as plain text).

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92070-dismiss-failed-scan-error-in-report?expand=1

What alternative solutions did you explore? (Optional)

• Remove the receipt-error filter from getLatestErrorMessageField so receipt errors surface everywhere. Rejected: the filtering is intentional and shared by many callers; removing it would re-introduce raw receipt error text in places that deliberately suppress it, and is far broader than needed to fix this issue.

[melvin-bot]

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

[aswin-s]

Proposal

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

On Android app and Windows/Chrome, when a user creates a scan expense that will fail, opens the report while the receipt is still scanning, and waits for the scan to fail, the resulting receipt error cannot be dismissed — clicking dismiss does nothing and the failed transaction thread is never cleaned up. The expected behavior is that the user can dismiss the error and the optimistic transaction thread is deleted.

What is the root cause of that problem?

PR #90879 changed cleanUpMoneyRequest to stop looking up the transaction thread report fresh and instead receive it as a parameter (src/libs/actions/IOU/DeleteMoneyRequest.ts:303). In MoneyRequestReceiptView.tsx, that value is supplied by a render-time subscription: const [parentReportActionChildReport] = useOnyx(\${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(parentReportAction?.childReportID)}`) (src/components/ReportActionItem/MoneyRequestReceiptView.tsx:152). When the report is opened *while scanning*, parentReportAction?.childReportIDis empty/undefined, sogetNonEmptyStringOnyxIDreturnsundefined (src/libs/getNonEmptyStringOnyxID.ts:5) and the subscription resolves to undefined. That undefinedis passed intocleanUpMoneyRequestatMoneyRequestReceiptView.tsx:434→prepareToCleanUpMoneyRequest, making shouldDeleteTransactionThreadfalse andtransactionThreadID undefined (DeleteMoneyRequest.ts:233), so the thread-deletion Onyx operations (DeleteMoneyRequest.ts:375-388) never run and the dismiss is effectively a no-op. Before the PR, cleanUpMoneyRequestresolved the thread fresh viagetAllReports()` at call time, which by then contained the arrived report.

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

1. In src/libs/actions/IOU/DeleteMoneyRequest.ts:310-311, fall back to a fresh lookup inside cleanUpMoneyRequest when the passed transactionThreadReport is empty — mirror the working analog already present in getNavigationUrlOnMoneyRequestDelete at DeleteMoneyRequest.ts:260-261 (getAllReports()?.[\${ONYXKEYS.COLLECTION.REPORT}${reportAction.childReportID}`]), e.g. const threadReport = transactionThreadReport ?? getAllReports()?.[...], and pass threadReportintoprepareToCleanUpMoneyRequest`.
2. This keeps the PR Refactor cleanUpMoneyRequest to pass transactionThreadReport #90879 prop as the fast path while restoring correctness for reports opened mid-scan, where the subscription captured undefined.
3. No platform twin needed — the logic is in shared DeleteMoneyRequest.ts; the symptom is reported on Android/Web only because that is where QA ran the repro.
4. Verify the other cleanUpMoneyRequest caller(s) still compile with the unchanged signature, since the fix is internal to the function body and does not change its parameters.

What alternative solutions did you explore? (Optional)

Re-derive childReportID in the component before the useOnyx call so the subscription binds to the correct key, but that still races the mid-scan ordering; the fresh lookup at delete time is the reliable fix.

[ReaperOAK]

Proposal

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

When a user opens an expense report while a scan expense is still processing and the scan subsequently fails, the resulting receipt error cannot be dismissed — the "Delete expense" button either never renders (when viewing from the expense report) or executes as a no-op (when viewing from the transaction thread, because the thread report is never cleaned up).

What is the root cause of that problem?

There are two distinct root causes, both traceable to PR #90879:

---

Root Cause 1 — cleanUpMoneyRequest loses the transaction thread report when report is opened mid-scan (primary regression from #90879)

File: src/libs/actions/IOU/DeleteMoneyRequest.ts

PR #90879 refactored cleanUpMoneyRequest to accept transactionThreadReport as a parameter instead of doing a fresh getAllReports() lookup at call time. The caller, MoneyRequestReceiptView.tsx, supplies this value via a useOnyx subscription:

// src/components/ReportActionItem/MoneyRequestReceiptView.tsx
const [parentReportActionChildReport] = useOnyx(
  `${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(parentReportAction?.childReportID)}`
);

The critical scenario: when the user opens the report while scanning is in progress, parentReportAction.childReportID is undefined at that render cycle. getNonEmptyStringOnyxID returns undefined, so useOnyx subscribes to no valid key and parentReportActionChildReport is undefined.

The important distinction from the critique of Competitor 3: useOnyx will re-subscribe when parentReportAction updates — but parentReportAction.childReportID is only written to Onyx when the child report is created server-side. When the scan fails, the server never confirms the child report creation back to the client in the same way, leaving childReportID absent on the action stored in Onyx. The transaction thread report may exist in allReports (written optimistically during the create flow) but parentReportAction.childReportID is never populated, so the useOnyx key never resolves to a valid report.

As a result, parentReportActionChildReport is undefined when cleanUpMoneyRequest is called (via the dismiss handler at MoneyRequestReceiptView.tsx:~434). Inside DeleteMoneyRequest.ts, prepareToCleanUpMoneyRequest receives undefined for transactionThreadReport, so shouldDeleteTransactionThread is false and transactionThreadID is undefined — the thread-deletion Onyx operations never execute. The dismiss becomes a no-op.

Notably, getNavigationUrlOnMoneyRequestDelete in the same file already performs its own fresh lookup as a fallback:

// src/libs/actions/IOU/DeleteMoneyRequest.ts (getNavigationUrlOnMoneyRequestDelete)
getAllReports()?.[`${ONYXKEYS.COLLECTION.REPORT}${reportAction.childReportID}`]

This pattern is the correct approach that cleanUpMoneyRequest lost after #90879.

---

Root Cause 2 — Receipt errors filtered from PureReportActionItem, "Delete expense" button never rendered from report view

File: src/libs/ErrorUtils.ts, function getLatestErrorMessageField

File: src/pages/inbox/report/PureReportActionItem.tsx

PureReportActionItem passes errors to its OfflineWithFeedback wrapper via:

errors={getLatestErrorMessageField(action)}

getLatestErrorMessageField intentionally filters out RECEIPT_ERROR type errors so they don't show at the action-level OfflineWithFeedback. The intent is that receipt errors surface via MoneyRequestReceiptView's own OfflineWithFeedback. But when MoneyRequestReceiptView's dismiss is broken (Root Cause 1), and the user is viewing the expense from the report

[KJ21-ENG]

Proposal

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

A scanned expense can finish with a failed SmartScan state while the user is already viewing the expense report / transaction thread. The UI shows the failed-scan receipt error, but it does not expose the existing dismiss/delete control, so the user cannot remove the failed expense and its transaction thread.

What is the root cause of that problem?

The failed scan is not being routed through the same error shape that the dismiss UI expects.

When SmartScan fails, the app adds a smartscanFailed transaction violation in ViolationsUtils.getViolationsOnyxData() when transaction.receipt.state === SCAN_FAILED and the required SmartScan fields are still missing:

App/src/libs/Violations/ViolationsUtils.ts

Lines 375 to 389 in eaaffe3

	// Only show SmartScan failed when scan failed AND the user hasn't filled required fields yet
	// Note: amount === 0 is a placeholder value for scanning transactions, not a user-entered value
	const hasUserStartedFixingSmartscan =
	(!TransactionUtils.isAmountMissing(updatedTransaction) && updatedTransaction.amount !== 0) || !TransactionUtils.isMerchantMissing(updatedTransaction);
	const shouldShowSmartScanFailedError =
	isScanRequest &&
	updatedTransaction.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED &&
	TransactionUtils.hasMissingSmartscanFields(updatedTransaction, iouReport) &&
	!hasUserStartedFixingSmartscan;
	const hasSmartScanFailedError = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.SMARTSCAN_FAILED);
	if (shouldShowSmartScanFailedError && !hasSmartScanFailedError) {
	newTransactionViolations.push({name: CONST.VIOLATIONS.SMARTSCAN_FAILED, type: CONST.VIOLATION_TYPES.WARNING, showInReview: true});
	}
	if (!shouldShowSmartScanFailedError && hasSmartScanFailedError) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.SMARTSCAN_FAILED});

That violation is treated as a receipt-image violation in MoneyRequestReceiptView and rendered through ReceiptAuditMessages:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 103 to 111 in eaaffe3

	const receiptImageViolationNames = new Set<OnyxTypes.ViolationName>([
	CONST.VIOLATIONS.RECEIPT_REQUIRED,
	CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED,
	CONST.VIOLATIONS.RECEIPT_NOT_SMART_SCANNED,
	CONST.VIOLATIONS.CASH_EXPENSE_WITH_NO_RECEIPT,
	CONST.VIOLATIONS.SMARTSCAN_FAILED,
	CONST.VIOLATIONS.PROHIBITED_EXPENSE,
	CONST.VIOLATIONS.RECEIPT_GENERATED_WITH_AI,
	]);

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 267 to 297 in eaaffe3

	const [receiptImageViolations, receiptViolations] = useMemo(() => {
	const imageViolations = [];
	const allViolations = [];
	const filteredViolations = filterReceiptViolations(transactionViolations ?? []);
	for (const violation of filteredViolations) {
	const isReceiptFieldViolation = receiptFieldViolationNames.has(violation.name);
	const isReceiptImageViolation = receiptImageViolationNames.has(violation.name);
	const isRTERViolation = violation.name === CONST.VIOLATIONS.RTER;
	if (isReceiptFieldViolation || isReceiptImageViolation || isRTERViolation) {
	const cardID = violation.data?.cardID;
	const card = cardID ? cardList?.[cardID] : undefined;
	const violationMessage = ViolationsUtils.getViolationTranslation({
	violation,
	translate,
	canEdit: isActionTakenByCurrentUser && isEditable,
	companyCardPageURL,
	connectionLink,
	card,
	isMarkAsCash,
	routeDistanceMeters,
	distanceUnit,
	});
	allViolations.push(violationMessage);
	if (isReceiptImageViolation || isRTERViolation) {
	imageViolations.push(violationMessage);
	}
	}
	}
	return [imageViolations, allViolations];
	}, [transactionViolations, translate, isActionTakenByCurrentUser, isEditable, companyCardPageURL, connectionLink, cardList, isMarkAsCash, routeDistanceMeters, distanceUnit]);

App/src/components/ReceiptAudit.tsx

Lines 59 to 70 in eaaffe3

	function ReceiptAuditMessages({notes = []}: {notes?: string[]}) {
	const styles = useThemeStyles();
	return (
	<View style={[styles.mtn1, styles.mb2, styles.ph5, styles.gap1]}>
	{notes.length > 0 &&
	notes.map((message) => (
	<View key={message}>
	<RenderHTML html={`<rbr>${message}</rbr>`} />
	</View>
	))}
	</View>
	);

ReceiptAuditMessages is only text. It has no dismiss action.

The dismiss/delete affordance is elsewhere: OfflineWithFeedback -> ErrorMessageRow -> MessagesRow -> DotIndicatorMessage. That path only renders the receipt-error buttons when the errors prop contains a CONST.IOU.RECEIPT_ERROR object:

App/src/components/MessagesRow.tsx

Lines 44 to 45 in eaaffe3

	const hasReceiptUploadError = Object.values(messages).some((message) => isReceiptError(message));
	const showDismissButton = !!onDismiss && !hasReceiptUploadError;

App/src/components/DotIndicatorMessage.tsx

Lines 91 to 124 in eaaffe3

	if (receiptError) {
	const isStackedLayout = !(isInNarrowPaneModal && !isSmallScreenWidth);
	const messageRow = (
	<View style={[styles.dotIndicatorMessage, isStackedLayout && styles.alignItemsStart, styles.flex1]}>
	<View style={styles.offlineFeedbackErrorDot}>
	<Icon
	src={expensifyIcons.DotIndicator}
	fill={isErrorMessage ? theme.danger : theme.success}
	/>
	</View>
	<Text
	style={[StyleUtils.getDotIndicatorTextStyles(isErrorMessage), textStyles, styles.flex1]}
	accessibilityRole={isErrorMessage ? CONST.ROLE.ALERT : undefined}
	accessibilityLiveRegion={isErrorMessage ? 'assertive' : undefined}
	>
	{translate('iou.error.receiptUploadFailedMessage')}
	</Text>
	</View>
	);
	const buttonsRow = (
	<View style={[styles.flexRow, styles.gap3]}>
	<Button
	small
	text={translate('iou.error.saveReceipt')}
	onPress={() => {
	fileDownload(translate, receiptError.source, receiptError.filename);
	}}
	/>
	<Button
	small
	danger
	text={translate('iou.deleteExpense', {count: 1})}
	onPress={dismissError}
	/>

For this SmartScan-failed path, transaction.errors, parentReportAction.errors, and reportCreationError can all be empty, so MoneyRequestReceiptView builds errors = {} and the dismiss UI never appears:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 303 to 342 in eaaffe3

	const errorsWithoutReportCreation = useMemo(
	() => ({
	...(transaction?.errorFields?.route ?? transaction?.errorFields?.waypoints ?? transaction?.errors),
	...parentReportAction?.errors,
	}),
	[transaction?.errorFields?.route, transaction?.errorFields?.waypoints, transaction?.errors, parentReportAction?.errors],
	);
	const reportCreationError = useMemo(() => (getCreationReportErrors(report) ? getMicroSecondOnyxErrorWithTranslationKey('report.genericCreateReportFailureMessage') : {}), [report]);
	const hasReceiptUploadError = Object.values(errorsWithoutReportCreation).some((error) => isReceiptError(error));
	// Whether to show receipt audit result (e.g.`Verified`, `Issue Found`) and messages (e.g. `Receipt not verified. Please confirm accuracy.`)
	// `!!(receiptViolations.length || didReceiptScanSucceed)` is for not showing `Verified` when `receiptViolations` is empty and `didReceiptScanSucceed` is false.
	const shouldShowAuditMessage =
	!isTransactionScanning &&
	(hasReceipt || !!receiptRequiredViolation || !!itemizedReceiptRequiredViolation || !!customRulesViolation) &&
	!!(receiptViolations.length || didReceiptScanSucceed) &&
	isPaidGroupPolicy(report);
	const shouldShowReceiptAudit = !isInvoice && (shouldShowReceiptEmptyState || hasReceipt || hasReceiptUploadError);
	const fallbackReceiptError = useMemo(() => {
	if (hasReceiptUploadError || isEmptyObject(reportCreationError) || !hasReceipt || !transaction?.receipt) {
	return {};
	}
	return getMicroSecondOnyxErrorObject({
	error: CONST.IOU.RECEIPT_ERROR,
	source: transaction.receipt.source?.toString() ?? '',
	filename: transaction.receipt.filename ?? '',
	});
	}, [hasReceiptUploadError, reportCreationError, hasReceipt, transaction]);
	const errors = useMemo(() => {
	if (hasReceiptUploadError) {
	return errorsWithoutReportCreation;
	}
	if (!isEmptyObject(fallbackReceiptError)) {
	return {...errorsWithoutReportCreation, ...fallbackReceiptError};
	}
	return {...errorsWithoutReportCreation, ...reportCreationError};
	}, [hasReceiptUploadError, fallbackReceiptError, errorsWithoutReportCreation, reportCreationError]);

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 520 to 555 in eaaffe3

	{(hasReceipt || !isEmptyObject(errors)) && (
	<OfflineWithFeedback
	shouldDisableOpacity={canShowReceiptActions}
	pendingAction={receiptPendingAction}
	errors={errors}
	errorRowStyles={[styles.mh4, !shouldShowReceiptEmptyState && styles.mt3]}
	onClose={() => {
	if (!transaction?.transactionID && !linkedTransactionID) {
	return;
	}
	const errorEntries = Object.entries(errors ?? {});
	const errorMessages = mapValues(Object.fromEntries(errorEntries), (error) => error);
	const hasReceiptError = Object.values(errorMessages).some((error) => isReceiptError(error));
	if (!hasReceiptError) {
	dismissReceiptError();
	return;
	}
	showConfirmModal({
	title: translate('iou.dismissReceiptError'),
	prompt: translate('iou.dismissReceiptErrorConfirmation'),
	confirmText: translate('common.dismiss'),
	cancelText: translate('common.cancel'),
	shouldShowCancelButton: true,
	danger: true,
	}).then((result) => {
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	dismissReceiptError();
	});
	}}
	dismissError={dismissReceiptError}
	style={[shouldShowAuditMessage ? styles.mt3 : styles.mv3, !showReceiptErrorWithEmptyState && styles.flex1]}

There is a second manifestation in the report action wrapper. PureReportActionItem already has dismissError wired to cleanUpMoneyRequest for failed request cleanup, but it passes getLatestErrorMessageField(action) into OfflineWithFeedback:

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

Lines 327 to 367 in eaaffe3

	const dismissError = useCallback(() => {
	const transactionID = isMoneyRequestAction(action) ? getOriginalMessage(action)?.IOUTransactionID : undefined;
	if (isSendingMoney && transactionID && reportID) {
	cleanUpMoneyRequest(transactionID, action, reportID, report, chatReport, undefined, originalReportID, true);
	return;
	}
	if (action.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD && isReportActionLinked) {
	navigation.setParams({reportActionID: ''});
	}
	if (transactionID) {
	clearError(transactionID);
	}
	clearAllRelatedReportActionErrors(reportID, action, originalReportID);
	}, [action, isSendingMoney, reportID, originalReportID, isReportActionLinked, report, chatReport, navigation]);
	const showDismissReceiptErrorModal = useCallback(async () => {
	const result = await showConfirmModal({
	title: translate('iou.dismissReceiptError'),
	prompt: translate('iou.dismissReceiptErrorConfirmation'),
	confirmText: translate('common.dismiss'),
	cancelText: translate('common.cancel'),
	shouldShowCancelButton: true,
	danger: true,
	});
	if (result.action === ModalActions.CONFIRM) {
	dismissError();
	}
	}, [showConfirmModal, translate, dismissError]);
	const onClose = useCallback(() => {
	const errors = linkedTransactionRouteError ?? getLatestErrorMessageField(action as OnyxDataWithErrors);
	const errorEntries = Object.entries(errors ?? {});
	const errorMessages = mapValues(Object.fromEntries(errorEntries), (error) => error);
	const hasReceiptError = Object.values(errorMessages).some((error) => isReceiptError(error));
	if (hasReceiptError) {
	showDismissReceiptErrorModal();
	} else {
	dismissError();
	}
	}, [linkedTransactionRouteError, action, showDismissReceiptErrorModal, dismissError]);

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

Lines 1079 to 1087 in eaaffe3

	<OfflineWithFeedback
	onClose={onClose}
	dismissError={dismissError}
	pendingAction={
	draftMessage !== undefined ? undefined : (action.pendingAction ?? (action.isOptimisticAction ? CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD : undefined))
	}
	shouldHideOnDelete={!isDeletedParentAction}
	errors={(linkedTransactionRouteError ?? !isOnSearch) ? getLatestErrorMessageField(action as OnyxDataWithErrors) : {}}
	errorRowStyles={[styles.ml10, styles.mr2]}

getLatestErrorMessageField() intentionally filters receipt errors out because receipt errors are supposed to be handled by the receipt-specific UI:

App/src/libs/ErrorUtils.ts

Lines 102 to 127 in eaaffe3

	function getLatestErrorMessageField<TOnyxData extends OnyxDataWithErrors>(onyxData: OnyxEntry<TOnyxData>): Errors {
	const errors = onyxData?.errors ?? {};
	if (isEmptyValueObject(errors)) {
	return {};
	}
	// Receipt errors are handled separately by MoneyRequestReceiptView and DotIndicatorMessage
	// and should never surface as a generic text error via this utility.
	const filteredKeys = Object.keys(errors)
	.filter((k) => !isReceiptError(errors[k]))
	.sort()
	.reverse();
	const key = filteredKeys.at(0) ?? '';
	if (!key) {
	return {};
	}
	const currentLocale = IntlStore.getCurrentLocale();
	if (errors[key] === CONST.ERROR.BANK_ACCOUNT_SAME_DEPOSIT_AND_WITHDRAWAL_ERROR) {
	return {key: translate(currentLocale, 'bankAccount.error.sameDepositAndWithdrawalAccount')};
	}
	return {key: errors[key]};
	}

So the failed scan is visible as smartscanFailed / RECEIPT_SCAN_FAILED, but neither the receipt detail view nor the report action wrapper gets the receipt-error payload needed to render the delete/dismiss controls.

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

Add an explicit SmartScan-failed receipt-error bridge in the UI layer that already owns dismissal.

1. In MoneyRequestReceiptView, detect the failed scan state with the existing data already available there, e.g. transaction.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED or the presence of CONST.VIOLATIONS.SMARTSCAN_FAILED in transactionViolations.

2. When that condition is true and there is no existing receipt upload error, create the same synthetic CONST.IOU.RECEIPT_ERROR object currently used by fallbackReceiptError via getMicroSecondOnyxErrorObject({error: CONST.IOU.RECEIPT_ERROR, source, filename}).

3. Merge that synthetic error into the errors passed to OfflineWithFeedback. This makes DotIndicatorMessage render the existing Save receipt and Delete expense buttons for SmartScan failures, instead of rendering only the non-actionable audit message.

4. Update dismissReceiptError so a failed SmartScan created from a scan request calls cleanUpMoneyRequest(..., isSingleTransactionView = true) even after transaction.pendingAction has been cleared. Today the cleanup branch is gated on transaction.pendingAction === ADD; a server-finished SCAN_FAILED transaction can be no longer pending, but the expected result is still to delete the failed expense/thread. The guard should be based on "this is a failed scan expense that should be removed", not only "the original create request is still pending".

5. For the report-action context, do not remove the global receipt-error filter from getLatestErrorMessageField(). Instead, in PureReportActionItem, locally include receipt errors / failed-scan receipt errors for money request actions when passing errors to OfflineWithFeedback, so the same DotIndicatorMessage delete button can invoke the already-wired dismissError handler. That keeps the broad utility behavior intact and scopes the change to money-request receipt failures.

This reuses the existing confirmation and cleanup flow instead of introducing a new SmartScan-specific delete path. The cleanup code already deletes the transaction, transaction violations, and transaction thread when cleanUpMoneyRequest runs:

App/src/libs/actions/IOU/DeleteMoneyRequest.ts

Lines 286 to 358 in eaaffe3

	function cleanUpMoneyRequest(
	transactionID: string,
	reportAction: OnyxTypes.ReportAction,
	reportID: string,
	iouReport: OnyxEntry<OnyxTypes.Report>,
	chatReport: OnyxEntry<OnyxTypes.Report>,
	isChatIOUReportArchived: boolean | undefined,
	originalReportID: string | undefined,
	isSingleTransactionView = false,
	) {
	const {shouldDeleteTransactionThread, shouldDeleteIOUReport, updatedReportAction, updatedIOUReport, updatedReportPreviewAction, transactionThreadID, reportPreviewAction} =
	prepareToCleanUpMoneyRequest(transactionID, reportAction, iouReport, chatReport, isChatIOUReportArchived, false);
	const urlToNavigateBack = getNavigationUrlOnMoneyRequestDelete(transactionID, reportAction, iouReport, chatReport, isChatIOUReportArchived, isSingleTransactionView);
	// build Onyx data
	// Onyx operations to delete the transaction, update the IOU report action and chat report action
	const reportActionsOnyxUpdates: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [];
	const onyxUpdates: Array<
	OnyxUpdate<typeof ONYXKEYS.COLLECTION.TRANSACTION | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS | typeof ONYXKEYS.COLLECTION.REPORT>
	> = [
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: null,
	},
	];
	if (shouldDeleteIOUReport) {
	onyxUpdates.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
	value: {
	[reportAction.reportActionID]: shouldDeleteIOUReport
	? null
	: {
	pendingAction: null,
	},
	},
	});
	} else {
	reportActionsOnyxUpdates.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${iouReport?.reportID}`,
	value: {
	[reportAction.reportActionID]: shouldDeleteIOUReport
	? null
	: {
	pendingAction: null,
	},
	},
	});
	}
	if (reportPreviewAction?.reportActionID) {
	reportActionsOnyxUpdates.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${chatReport?.reportID}`,
	value: {
	[reportPreviewAction.reportActionID]: {
	...updatedReportPreviewAction,
	pendingAction: null,
	errors: null,
	},
	},
	});
	}
	// added the operation to delete associated transaction violations
	onyxUpdates.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
	value: null,
	});

App/src/libs/actions/IOU/DeleteMoneyRequest.ts

Lines 360 to 373 in eaaffe3

	// added the operation to delete transaction thread
	if (shouldDeleteTransactionThread) {
	onyxUpdates.push(
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${transactionThreadID}`,
	value: null,
	},
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${transactionThreadID}`,
	value: null,
	},
	);

What alternative solutions did you explore? (Optional)

One option is to add a bespoke dismiss button directly to ReceiptAuditMessages or the RECEIPT_SCAN_FAILED system message. I would avoid that because it duplicates the receipt-error button UI and risks creating a second cleanup path.

Another option is to stop filtering receipt errors in getLatestErrorMessageField(). That is too broad because the utility is shared and explicitly documents that receipt errors should not surface as generic text errors.