[$250] Scan - Submit button is not displayed while SmartScan is processing the receipt

[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.4.34-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: #95716
Email or phone of affected tester (no customers): jose.sat94+10jul@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Pro/13.7.8, Samsung Galaxy S21/Android 15, iPhone 13/18.6.2
App Component: Other

Action Performed:

1. Launch the Expensify app.
2. Log in with a valid account.
3. Ensure the account is a member of a Collect/Control workspace with Tags enabled.
4. Tap the FAB (+) and select Create expense.
5. Open the Scan tab.
6. Capture or upload a receipt.
7. Select the workspace as the destination.
8. Wait until the confirmation screen appears while SmartScan is still processing the receipt.

Expected Result:

The Submit button should be available while SmartScan is still processing the receipt, allowing the expense to be submitted before SmartScan finishes so the ScanSkipConfirmation flow can execute successfully.

Actual Result:

The Submit button is not displayed while SmartScan is processing the receipt, preventing the expense from being submitted before SmartScan finishes and blocking the ScanSkipConfirmation flow.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208545_1784067239913.WEB.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7208545

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077175485050583873
• Upwork Job ID: 2077175485050583873
• Last Price Increase: 2026-07-14

[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/b324d86724f413369f2b9cb7af50f661d1d0bf6463e69ca03fbabec5c6c6c5d8

[MelvinBot]

Issue Analysis

⚠️ Confidence: medium. The root‑cause area is well supported by code, but the exact reason the Submit button appears "not displayed" during scan is a runtime/layout symptom that should be confirmed by reproducing the flow (see How to confirm below).

Root cause (area): This is a confirmation‑screen issue in IOURequestStepConfirmation.tsx / MoneyRequestConfirmationList.tsx — not in PR #95716. The confirm button has no code condition that hides it based on tags or scan state; it is always rendered and only switched to a spinner state during specific loading. The two things that can visually remove it during a scan are a full‑screen loader overlay and compact‑mode layout (details below).

PR #95716 is coincidental, not causal. The bug reproduces in production (per the report), while #95716 merged on 2026‑07‑13 and only changed how policyTagList is resolved in createTransaction and in the skip‑confirmation path — it touches nothing that controls button visibility. It was simply the PR under QA when this flow was exercised.

Important nuance about the report wording: When the workspace requires a tag, the scan flow does not use ScanSkipConfirmation. ScanRouter.tsx:46-55 forces shouldSkipConfirmation = false when the policy requires a tag/category, so the user is routed to the full confirmation screen (which is exactly where a Submit button is expected). So "blocking the ScanSkipConfirmation flow" is a mislabel — the real question is why Submit isn't visible on the standard confirmation screen during scan.

How to confirm / recommended next step: Reproduce on macOS Chrome with a tag‑required workspace and watch the confirm‑button region while SmartScan runs, checking which of the two mechanisms below is active (screen‑covering loader vs. button scrolled below the fold).

Investigation details & evidence

The confirm button is always in the tree (no tag/scan hide gate):

• MoneyRequestConfirmationList.tsx:514-531 — footerContent renders whenever !isReadOnly; no tag/scan condition.
• ConfirmationFooterContent.tsx:109-147 — the button always renders; scan only sets isLoading={isConfirmed || isConfirming || isLoadingReceipt} (spinner), never removes it.
• isLoadingReceipt is isStitchingReceipt || (isOdometerDistanceRequest && !hasVerifiedBlobs) (IOURequestStepConfirmation.tsx:975) — a single scanned receipt with tags does not trigger it, so the spinner state is not the cause here.

Candidate mechanism #1 — full‑screen loader overlay:

• IOURequestStepConfirmation.tsx:908-916 shows a FullScreenLoadingIndicator (covering the button) when isScanRequest(transaction) && !Object.values(receiptFiles).length. receiptFiles is populated by the local ReceiptFileValidator (local file validation, independent of server SmartScan), so this should clear quickly — but if it lingers in the global‑create scan path it would present as "Submit not shown for the whole scan."

Candidate mechanism #2 — compact scan‑mode layout:

• MoneyRequestConfirmationList.tsx:507-511 sets isCompactMode = !showMoreFields && isScanRequest && !isInLandscapeMode and gives the field list flex1, which can push the footer button below the fold on small screens — matching "button not displayed" (it's off‑screen, not absent).

What PR #95716 actually changed (button‑irrelevant): policyTagList resolution in createTransaction ([MoneyRequest.ts]) and the submit payload of ScanSkipConfirmation.tsx:185-188. Neither affects whether a button renders on the confirmation screen. Also note the QA repro uses FAB → global‑create scan, which does not even reach ScanSkipConfirmation.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis (e.g. after reproducing to confirm which mechanism above is active). Because pinning the exact fix depends on runtime behavior, I'd recommend confirming the mechanism before implementation rather than jumping straight to a code change.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:47:37 UTC.

Proposal

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

On a Collect/Control workspace with delayed submission, a scanned expense lands in an open (Draft) expense report. While SmartScan is still processing the receipt, the report offers no way to submit: the header shows only the "More" dropdown (no green Submit button), the "More" menu has no Submit entry, and the Search page row shows "View" instead of "Submit". The Submit button only appears after SmartScan finishes (the QA video shows the header jumping from "Receipt scan in progress. Check back later or enter the details now." with no button to "Waiting for you to submit expenses." with the Submit button once the scan completes).

What is the root cause of that problem?

When the scan expense is created, createTransaction in src/libs/actions/IOU/MoneyRequest.ts sets receipt.state = CONST.IOU.RECEIPT_STATE.SCAN_READY before calling requestMoney, and the server keeps the receipt in SCANNING until OCR completes. For that whole window, isScanning/isReceiptBeingScanned in TransactionUtils returns true (receipt.state === SCAN_READY || receipt.state === SCANNING). Every submit affordance in the app is gated on that flag. The header's green button comes from getReportPrimaryAction → isSubmitAction, which bails out because a scanning transaction is counted as unsubmittable:

App/src/libs/ReportPrimaryActionUtils.ts

Lines 141 to 145 in 890332b

	const hasNoSubmittableTransaction =
	reportTransactionsList.length > 0 &&
	reportTransactionsList.every(
	(transaction) => isScanning(transaction) || (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
	);

The "More" menu entry is separately killed by an even stricter any-scanning gate in ReportSecondaryActionUtils.isSubmitAction:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 227 to 231 in 890332b

	const isAnyReceiptBeingScanned = reportTransactions?.some((transaction) => isReceiptBeingScanned(transaction));
	if (isAnyReceiptBeingScanned) {
	return false;
	}

The Search page action is gated by canSubmitReport in ReportWorkflow.ts, which repeats the same isScanningTransaction(t) clause, and the report preview button in the workspace chat has !isAnyReceiptBeingScanned in canSubmit in src/libs/ReportPreviewActionUtils.ts. Because the repro report contains exactly one transaction and it is scanning, all four surfaces hide Submit simultaneously, and they all reappear the moment receipt.state flips to scan-complete — exactly the before/after captured in the QA recording. Note this is not a regression from PR #95716: that PR only changed how policyTagList is plumbed into createTransaction and never touches submit eligibility. These gates trace back to older changes (the More-menu one was added for issue #75840), which is why the issue reproduces in production as well. The current state is also internally inconsistent: a multi-expense report where only one receipt is scanning already shows the primary Submit button (the primary gate uses .every()), and submitting it sends the still-scanning expense along — and instant-submit policies routinely place scanning expenses directly into already-submitted Processing reports — so "a submitted report containing a scanning receipt" is a fully supported state; only the all-scanning report is blocked.

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

Remove the scanning condition from the submit-eligibility checks so a report whose receipts are merely still scanning can be submitted, while keeping the genuine blockers (scan failed with missing fields, pending card transactions, submission-blocking violations) intact. In ReportPrimaryActionUtils.isSubmitAction drop isScanning(transaction) from the hasNoSubmittableTransaction predicate:

const hasNoSubmittableTransaction =
    reportTransactionsList.length > 0 &&
    reportTransactionsList.every(
        (transaction) => (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
    );

Apply the same one-line relaxation to the mirrored clause in canSubmitReport so the Search page stays consistent:

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

Lines 287 to 291 in 890332b

	const hasNoSubmittableTransaction =
	transactions.length > 0 && transactions.every((t) => isScanningTransaction(t) || (isExpensifyCardTransaction(t) && isPending(t)) || hasSmartScanFailedWithMissingFields([t], report));
	const hasAnySubmissionBlockingViolations = transactions.some((transaction) =>
	hasSubmissionBlockingViolations(transaction, allViolations, currentUserEmailParam, currentUserAccountID, report, reportOwnerLogin, policy),
	);

and delete the isAnyReceiptBeingScanned early return in ReportSecondaryActionUtils.isSubmitAction plus the !isAnyReceiptBeingScanned term in ReportPreviewActionUtils.canSubmit, so the More menu and the chat report preview agree with the header. This is safe because submitReport already handles these reports today via the mixed-report path (the backend continues the scan after submission and back-fills amount/merchant, updating the now-Processing report), and isScanning already returns false once a user manually enters an amount, so the manual-entry escape hatch is unaffected. The Approve-side scanning gates (isApproveAction, canApprove, and the hasOnlyPendingCardOrScanningTransactions check in SearchUIUtils) are deliberately left untouched, since approving locks amounts and hiding Approve during scanning was a separate product decision. The unit tests in tests/unit/ReportPrimaryActionUtilsTest.ts, tests/unit/ReportSecondaryActionUtilsTest.ts, and tests/actions/ReportPreviewActionUtilsTest.ts that assert the old hidden-while-scanning behavior get updated to assert Submit is now offered.

What alternative solutions did you explore? (Optional)

We considered following the pending-card pattern from PR #87750 (always render the Submit button but intercept the press with an explanatory modal via showConfirmModal), but rejected it because the issue's expected result is that submission actually proceeds before SmartScan finishes, and unlike pending card transactions (which don't exist as postable expenses yet) a scanning expense is a real transaction the backend already accepts in submitted reports. We also considered relaxing only the primary-action gate, but that would leave the More menu, Search, and report preview inconsistent with the header.

[aswin-s]

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

On iOS, Android, and Web, when a member of a Collect/Control workspace with Tags enabled scans a receipt via FAB → Create expense → Scan and reaches the confirmation screen while SmartScan is still processing, the Submit button is missing. Expected behavior is that the Submit button remains visible and pressable so the user can submit before SmartScan completes.

What is the root cause of that problem?

In src/pages/iou/request/step/IOURequestStepConfirmation.tsx:824, shouldShowSmartScanFields is computed as !!transaction?.receipt?.isTestDriveReceipt || isMovingTransactionFromTrackExpense || requestType !== CONST.IOU.REQUEST_TYPE.SCAN — which is FALSE for an in-flight SmartScan (requestType === SCAN, no test-drive, not moving). This false value is passed into MoneyRequestConfirmationList at line 978 and consumed by MoneyRequestConfirmationListFooter (via visibilityFlags.shouldShowSmartScanFields at src/components/MoneyRequestConfirmationList.tsx:568), which suppresses the merchant/amount/date rows AND collapses the footer such that the submit CTA is not rendered while SmartScan is pending. Because the CTA is gated on scan-fields being visible rather than on receipt-parsed state, the user cannot submit early, which contradicts the ScanSkipConfirmation flow the Expected Result names.

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

1. src/pages/iou/request/step/IOURequestStepConfirmation.tsx:975 — decouple the Submit CTA's presence entirely from shouldShowSmartScanFields. The footer containing the Submit button must render regardless of whether SmartScan fields are shown.

2. src/components/MoneyRequestConfirmationList.tsx:514 — ensure footerContent (which builds the Submit CTA) is not indirectly gated by shouldShowSmartScanFields/isCompactMode collapsing the footer region during a pending scan.

3. src/components/MoneyRequestConfirmationList/ConfirmationFooterContent.tsx:141 — keep the button rendered and pressable while SmartScan is processing. Do not pass isLoadingReceipt into isLoading on the button, because a loading button blocks onPress and disabled is set to true internally (the press handler short-circuits when isLoading === true). Instead, show the button in its normal enabled state so the user can tap Submit and trigger the ScanSkipConfirmation flow. The button's existing isLoading guard (isConfirmed || isConfirming) already covers the post-tap spinner; no change is needed there.

   The diff here reduces to removing isLoadingReceipt from any isLoading or isDisabled expression that gates the submit button, and ensuring the footer is rendered whenever the confirmation screen is shown, not only when shouldShowSmartScanFields is true.

4. Verify iOS/Android/Web parity — the code path is shared, no platform-specific override should re-hide the button.

5. Re-run the repro with a Collect/Control workspace + Tags enabled to confirm the Submit button appears and is tappable throughout SmartScan processing (not just visible but blocked).

What alternative solutions did you explore? (Optional)

One alternative considered was keeping isLoadingReceipt in the button's isLoading prop to show a spinner during SmartScan. This was ruled out because Button short-circuits onPress and sets disabled={true} when isLoading is true, so the button would be visible but still unpressable — reproducing the original problem in a different form. The correct fix is to make the button fully interactive during SmartScan, not to swap one blocking state for another.

[ahmdshrif]

Proposal

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

When a receipt is still being processed by SmartScan, the report's Submit primary action button is not displayed, so the user cannot submit the expense report until scanning finishes.

What is the root cause of that problem?

The Submit primary action is gated by isSubmitAction in ReportPrimaryActionUtils. It computes hasNoSubmittableTransaction as every transaction being scanning / a pending card txn / a failed SmartScan, and if so it returns false (no Submit button):

App/src/libs/ReportPrimaryActionUtils.ts

Lines 141 to 149 in 890332b

	const hasNoSubmittableTransaction =
	reportTransactionsList.length > 0 &&
	reportTransactionsList.every(
	(transaction) => isScanning(transaction) || (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
	);
	if (hasNoSubmittableTransaction) {
	return false;
	}

Because isScanning(transaction) is treated as "not submittable", a report whose only transaction(s) are still being SmartScanned reports hasNoSubmittableTransaction === true, and Submit is hidden for the whole scanning window. isScanning is truthy while the receipt is in the scanning state (TransactionUtils.isScanning → isReceiptBeingScanned), so the button only appears once the scan resolves.

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

A scanning expense is a valid, submittable expense (the amount can be entered/edited manually), so it should not count toward hasNoSubmittableTransaction. Drop the isScanning(...) term from that predicate so only genuinely non-submittable transactions (pending Expensify Card txns and SmartScan-failed-with-missing-fields) suppress Submit:

reportTransactionsList.every(
    (transaction) =>
        (isExpensifyCardTransaction(transaction) && isPending(transaction)) ||
        hasSmartScanFailedWithMissingFields([transaction], report),
);

App/src/libs/ReportPrimaryActionUtils.ts

Lines 141 to 149 in 890332b

	const hasNoSubmittableTransaction =
	reportTransactionsList.length > 0 &&
	reportTransactionsList.every(
	(transaction) => isScanning(transaction) || (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
	);
	if (hasNoSubmittableTransaction) {
	return false;
	}

Regression check: confirm reports consisting solely of pending-card or scan-failed transactions still correctly hide Submit, and that submitting a still-scanning report behaves as expected server-side.

[lorretheboy]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:46:42 UTC.

Proposal

What is the root cause of that problem?

The Submit button isn't removed — it's covered. IOURequestStepConfirmation mounts a full-screen loader over the whole step while its local receiptFiles state is empty:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 908 to 916 in 09ce5e0

	{(isLoading || (isScanRequest(transaction) && !Object.values(receiptFiles).length)) && (
	<FullScreenLoadingIndicator
	reasonAttributes={{
	context: 'IOURequestStepConfirmation',
	isLoading,
	isScanRequestWithNoReceipts: isScanRequest(transaction) && !Object.values(receiptFiles).length,
	}}
	/>
	)}

That state is only ever filled by ReceiptFileValidator, asynchronously. Its effect resolves a promise and then publishes — unless ignore was flipped by the cleanup:

App/src/pages/iou/request/step/confirmation/ReceiptFileValidator.tsx

Lines 118 to 144 in 09ce5e0

	).then(() => {
	// Bail if the effect already re-ran on a newer transactions emission — the fresh closure validates from scratch.
	if (ignore) {
	return;
	}
	if (resetInitialTransactionReceipt) {
	setMoneyRequestReceipt(initialTransactionID, '', '', true, '');
	}
	if (isScanFilesCanBeRead) {
	onReceiptFilesChange(newReceiptFiles);
	return;
	}
	if (requestType === CONST.IOU.REQUEST_TYPE.MANUAL) {
	Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_SCAN.getRoute(CONST.IOU.ACTION.CREATE, iouType, initialTransactionID, reportID, Navigation.getActiveRouteWithoutParams()));
	return;
	}
	removeDraftTransactionsByIDs(draftTransactionIDs, true);
	if (requestType) {
	navigateToStartMoneyRequestStep(requestType, iouType, initialTransactionID, reportID, action, backToReport);
	}
	});
	return () => {
	ignore = true;
	};
	// eslint-disable-next-line react-hooks/exhaustive-deps -- draftTransactionIDs is intentionally excluded to avoid re-running on draft changes
	}, [requestType, iouType, initialTransactionID, reportID, action, backToReport, report, transactions, participants, isReceiptReady, onReceiptFilesChange]);

The bug is in that dependency array. It lists report and participants, but the effect body never reads either one — the body only touches transactions, requestType, the IDs, and onReceiptFilesChange. They are phantom deps that do nothing except restart validation.

And they churn constantly. participants is rebuilt from privateIsArchivedMap, participantsPolicies, reportAttributesDerived and reportDrafts — each keyed to a whole Onyx collection:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 271 to 288 in 09ce5e0

	const participants = useMemo(
	() =>
	transaction?.participants?.map((participant) => {
	if (participant.isSender && iouType === CONST.IOU.TYPE.INVOICE) {
	return participant;
	}
	const privateIsArchived = privateIsArchivedMap[`${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${participant.reportID}`];
	const participantReportDraft = reportDrafts?.[`${ONYXKEYS.COLLECTION.REPORT_DRAFT}${participant.reportID}`];
	const participantPolicy = participant.policyID ? participantsPolicies[participant.policyID] : policy;
	// Phone contacts always have an optimistic accountID but no reportID; getReportOption
	// is designed for report-backed participants and discards participant.text, so route
	// any participant without a reportID to getParticipantsOption instead.
	return participant.accountID || !participant.reportID
	? getParticipantsOption(participant, personalDetails, translate)
	: getReportOption(participant, privateIsArchived, participantPolicy, personalDetails, conciergeReportID, reportAttributesDerived, participantReportDraft);
	}) ?? [],
	[transaction?.participants, iouType, personalDetails, reportAttributesDerived, privateIsArchivedMap, participantsPolicies, policy, conciergeReportID, reportDrafts, translate],
	);

So on a Collect/Control workspace, policy/tag/report data streams into Onyx right after the destination is picked → participants/report get new identities → the effect restarts → the in-flight file read is discarded by ignore → receiptFiles stays {} → the loader never lifts and Submit stays covered. Tags make it reproducible because they extend the window of Onyx churn past the file read. transactions has the same problem: it re-emits on every unrelated field SmartScan writes, though the effect only reads each item's receipt.

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

Keep the receiptFiles gate — it is load-bearing. It is tempting to just drop !Object.values(receiptFiles).length from the loader condition, but that is a receipt-loss bug. receiptFiles is not merely a readiness flag; it carries the actual File blob into submission:

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Lines 1036 to 1059 in 09ce5e0

	if (Object.values(receiptFiles).filter((receipt) => !!receipt).length && !!transaction) {
	// If the transaction amount is zero, then the money is being requested through the "Scan" flow and the GPS coordinates need to be included.
	if (transaction.amount === 0 && !isSharingTrackExpense && !isCategorizingTrackExpense && locationPermissionGranted) {
	if (userLocation) {
	requestMoney(shouldHandleNavigation, {
	lat: userLocation.latitude,
	long: userLocation.longitude,
	});
	markSubmitExpenseEnd();
	return;
	}
	getCurrentPositionWithGeolocationSpan((gpsCoords) => requestMoney(shouldHandleNavigation, gpsCoords));
	return;
	}
	// Otherwise, the money is being requested through the "Manual" flow with an attached image and the GPS coordinates are not needed.
	requestMoney(shouldHandleNavigation);
	markSubmitExpenseEnd();
	return;
	}
	requestMoney(shouldHandleNavigation);
	markSubmitExpenseEnd();

If Submit is pressed while receiptFiles is {}, that guard fails and we fall through to requestMoney(...) with receipt: receiptFiles[item.transactionID] → undefined — creating a scan expense with no receipt at all, and silently making gpsRequired falsy. That's worse than the reported bug.

Fix the actual defect instead: make the validator stop restarting.

1. Delete report and participants from the dep array. They are never read in the effect body, so this is a pure no-op for behavior and removes the dominant source of restarts.
2. Key the effect on the receipts it actually reads rather than on the whole transactions array — a small signature string, e.g. transactionID:source:filename joined per transaction. This mirrors the pattern already used one file over, where transactionIDs is deliberately keyed on transactions.length to avoid churn:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 139 to 141 in 09ce5e0

	// Depend on transactions.length to avoid updating transactionIDs when only the transaction details change
	// eslint-disable-next-line react-hooks/exhaustive-deps
	const transactionIDs = useMemo(() => transactions?.map((transaction) => transaction.transactionID), [transactions.length]);

The effect then runs once per real receipt change, the promise resolves without being ignored, onReceiptFilesChange publishes, the loader lifts, and Submit is available while SmartScan is still processing — with the receipt correctly attached, so ScanSkipConfirmation can run.

Also worth fixing the stale doc comment above the effect, which claims it validates "when transactions, participants, or report change" — that description is what produced the phantom deps.

Test: mount the confirmation step for a scan transaction, emit an unrelated Onyx update (a policy tag write) while the file read is in flight, and assert Submit is visible and the receipt survives submission.

What alternative solutions did you explore? (Optional)

• Publish results even when ignore is set, on the reasoning that the validated files are still correct for the transactions that were read. This narrows the race but doesn't close it: two runs can resolve out of order, letting a stale result overwrite a fresh one. Removing the needless restarts is safer than making the restarts survivable.
• Drop the !Object.values(receiptFiles).length term from the loader. Rejected for the receipt-loss reason above — it makes the button appear by letting users submit a receiptless scan.
• Memoize privateIsArchivedMap/participantsPolicies so participants stops changing identity. This helps generally, but it treats a shared hook as the fix for one screen's effect and still leaves unused deps that will re-open the hole on the next churn source.

[samranahm]

Proposal

What is the root cause of that problem?

When a user captures or uploads a receipt on the Scan tab and reaches the confirmation screen while SmartScan is still processing, the Submit button is not shown, so the expense cannot be submitted early and the ScanSkipConfirmation flow never runs.

The Scan flow is routed through ScanRouter, which renders ScanNewReceipt inside MultiScanGate for the create flow:

App/src/pages/iou/request/step/IOURequestStepScan/ScanRouter.tsx

Lines 127 to 154 in 890332b

	function ScanRouter({report, action, iouType, reportID, transactionID, transaction, backTo, backToReport}: ScanRouterProps) {
	const isEditing = action === CONST.IOU.ACTION.EDIT;
	if (backTo || isEditing) {
	return (
	<ScanEditReceipt
	report={report}
	transactionID={transactionID}
	backTo={backTo}
	isEditing={isEditing}
	/>
	);
	}
	return (
	<MultiScanGate>
	<ScanNewReceipt
	report={report}
	action={action}
	iouType={iouType}
	reportID={reportID}
	transactionID={transactionID}
	transaction={transaction}
	backToReport={backToReport}
	/>
	</MultiScanGate>
	);
	}

After a receipt is captured, the confirmation step renders the money request confirmation list, whose action button is the FormAlertWithSubmitButton component:

App/src/components/FormAlertWithSubmitButton.tsx

Lines 97 to 176 in 890332b

	function FormAlertWithSubmitButton({
	message = '',
	isDisabled = false,
	isMessageHtml = false,
	containerStyles,
	isLoading: isOnyxLoading = false,
	onFixTheErrorsLinkPressed = () => {},
	enabledWhenOffline = false,
	disablePressOnEnter = false,
	isSubmitActionDangerous = false,
	footerContent,
	buttonRef,
	buttonStyles,
	buttonText,
	isAlertVisible = false,
	onSubmit,
	useSmallerSubmitButtonSize = false,
	errorMessageStyle,
	enterKeyEventListenerPriority = 0,
	shouldRenderFooterAboveSubmit = false,
	shouldBlendOpacity = false,
	addButtonBottomPadding = true,
	shouldPreventDefaultFocusOnPress = false,
	shouldShowLoadingImmediatelyOnPress = true,
	sentryLabel,
	}: FormAlertWithSubmitButtonProps) {
	const styles = useThemeStyles();
	const style = [!shouldRenderFooterAboveSubmit && footerContent && addButtonBottomPadding ? styles.mb3 : {}, buttonStyles];
	const {isLoading, startWithLoading} = usePressLoading({isLoading: isOnyxLoading});
	const submit = () => {
	if (!shouldShowLoadingImmediatelyOnPress) {
	onSubmit();
	return;
	}
	startWithLoading(onSubmit);
	};
	// Disable pressOnEnter for Android Native to avoid issues with the Samsung keyboard,
	// where pressing Enter saves the form instead of adding a new line in multiline input.
	// More details: https://github.com/Expensify/App/issues/46644
	const isAndroidNative = getPlatform() === CONST.PLATFORM.ANDROID;
	const pressOnEnter = isAndroidNative ? false : !disablePressOnEnter;
	return (
	<FormAlertWrapper
	containerStyles={[styles.justifyContentEnd, containerStyles]}
	isAlertVisible={isAlertVisible}
	isMessageHtml={isMessageHtml}
	message={message}
	onFixTheErrorsLinkPressed={onFixTheErrorsLinkPressed}
	errorMessageStyle={errorMessageStyle}
	>
	{(isOffline: boolean | undefined) => (
	<View>
	{shouldRenderFooterAboveSubmit && footerContent}
	{isOffline && !enabledWhenOffline ? (
	<Button
	success
	shouldBlendOpacity={shouldBlendOpacity}
	isDisabled
	text={buttonText}
	style={style}
	danger={isSubmitActionDangerous}
	medium={useSmallerSubmitButtonSize}
	large={!useSmallerSubmitButtonSize}
	onMouseDown={shouldPreventDefaultFocusOnPress ? (e) => e.preventDefault() : undefined}
	sentryLabel={sentryLabel}
	/>
	) : (
	<Button
	ref={buttonRef}
	success
	shouldBlendOpacity={shouldBlendOpacity}
	pressOnEnter={pressOnEnter}
	enterKeyEventListenerPriority={enterKeyEventListenerPriority}
	text={buttonText}
	style={style}
	onPress={submit}

The confirmation list gates whether this button renders on the SmartScan processing state of the transaction receipt. While the receipt still has a scanning/loading state (the transaction amount and merchant are not yet parsed), the confirmation footer treats the transaction as not ready and skips rendering the Submit button entirely. Because the button never renders during processing, the user cannot trigger the ScanSkipConfirmation path that is designed to let submission happen before SmartScan finishes.

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

1. In the money request confirmation list that renders the Scan confirmation footer (the component that mounts FormAlertWithSubmitButton), the condition that hides the button while the receipt is being SmartScanned should be removed for the create Scan flow. The button should always render for a scan request so the user can submit early.

2. Keep using FormAlertWithSubmitButton for the action, and pass the scan-processing state through its existing isLoading prop rather than hiding the whole button. This shows the button in a loading/disabled-friendly state while still allowing the press, which is what the ScanSkipConfirmation flow expects:

App/src/components/FormAlertWithSubmitButton.tsx

Lines 97 to 176 in 890332b

	function FormAlertWithSubmitButton({
	message = '',
	isDisabled = false,
	isMessageHtml = false,
	containerStyles,
	isLoading: isOnyxLoading = false,
	onFixTheErrorsLinkPressed = () => {},
	enabledWhenOffline = false,
	disablePressOnEnter = false,
	isSubmitActionDangerous = false,
	footerContent,
	buttonRef,
	buttonStyles,
	buttonText,
	isAlertVisible = false,
	onSubmit,
	useSmallerSubmitButtonSize = false,
	errorMessageStyle,
	enterKeyEventListenerPriority = 0,
	shouldRenderFooterAboveSubmit = false,
	shouldBlendOpacity = false,
	addButtonBottomPadding = true,
	shouldPreventDefaultFocusOnPress = false,
	shouldShowLoadingImmediatelyOnPress = true,
	sentryLabel,
	}: FormAlertWithSubmitButtonProps) {
	const styles = useThemeStyles();
	const style = [!shouldRenderFooterAboveSubmit && footerContent && addButtonBottomPadding ? styles.mb3 : {}, buttonStyles];
	const {isLoading, startWithLoading} = usePressLoading({isLoading: isOnyxLoading});
	const submit = () => {
	if (!shouldShowLoadingImmediatelyOnPress) {
	onSubmit();
	return;
	}
	startWithLoading(onSubmit);
	};
	// Disable pressOnEnter for Android Native to avoid issues with the Samsung keyboard,
	// where pressing Enter saves the form instead of adding a new line in multiline input.
	// More details: https://github.com/Expensify/App/issues/46644
	const isAndroidNative = getPlatform() === CONST.PLATFORM.ANDROID;
	const pressOnEnter = isAndroidNative ? false : !disablePressOnEnter;
	return (
	<FormAlertWrapper
	containerStyles={[styles.justifyContentEnd, containerStyles]}
	isAlertVisible={isAlertVisible}
	isMessageHtml={isMessageHtml}
	message={message}
	onFixTheErrorsLinkPressed={onFixTheErrorsLinkPressed}
	errorMessageStyle={errorMessageStyle}
	>
	{(isOffline: boolean | undefined) => (
	<View>
	{shouldRenderFooterAboveSubmit && footerContent}
	{isOffline && !enabledWhenOffline ? (
	<Button
	success
	shouldBlendOpacity={shouldBlendOpacity}
	isDisabled
	text={buttonText}
	style={style}
	danger={isSubmitActionDangerous}
	medium={useSmallerSubmitButtonSize}
	large={!useSmallerSubmitButtonSize}
	onMouseDown={shouldPreventDefaultFocusOnPress ? (e) => e.preventDefault() : undefined}
	sentryLabel={sentryLabel}
	/>
	) : (
	<Button
	ref={buttonRef}
	success
	shouldBlendOpacity={shouldBlendOpacity}
	pressOnEnter={pressOnEnter}
	enterKeyEventListenerPriority={enterKeyEventListenerPriority}
	text={buttonText}
	style={style}
	onPress={submit}

<FormAlertWithSubmitButton
    buttonText={translate('common.submit')}
    onSubmit={onConfirm}
    isLoading={isScanRequest && isReceiptBeingScanned}
    enabledWhenOffline
/>

3. On confirm, when the receipt is still processing, route through the existing ScanSkipConfirmation handler so the expense is submitted before SmartScan finishes, matching the expected result in the issue.

This fixes the root cause because the Submit button is no longer conditionally unmounted during SmartScan processing, so users on Collect/Control workspaces can submit and the skip-confirmation flow executes.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-14 23:45:47 UTC.

Proposal

What is the root cause of that problem?

The missing control is the expense report's primary Submit action, not the Create expense button on the scan confirmation page. In the recording, Create expense is available and is used while the receipt is scanning; after the app opens the newly created report, Submit is absent until SmartScan finishes, then appears in the report header.

The report header gets its primary action from useReportPrimaryAction, which passes the report's live transactions into getReportPrimaryAction.

App/src/components/MoneyReportHeader.tsx

Lines 84 to 150 in 09ce5e0

	const isReportInRHP = route.name !== SCREENS.REPORT;
	const shouldDisplaySearchRouter = !isReportInRHP || isSmallScreenWidth;
	const isReportInSearch = route.name === SCREENS.RIGHT_MODAL.SEARCH_REPORT || route.name === SCREENS.RIGHT_MODAL.SEARCH_MONEY_REQUEST_REPORT;
	const backTo = (route.params as {backTo?: Route} | undefined)?.backTo;
	const primaryAction = useReportPrimaryAction(reportIDProp);
	const shouldShowBackButton = shouldDisplayBackButton || shouldUseNarrowLayout;
	const isMobileSelectionModeEnabled = useMobileSelectionMode();
	useEffect(() => {
	return () => {
	turnOffMobileSelectionMode();
	};
	}, []);
	if (isMobileSelectionModeEnabled && shouldUseNarrowLayout) {
	// If mobile selection mode is enabled but only one or no transactions remain, turn it off
	const visibleTransactions = transactions.filter((t) => t.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE || isOffline);
	if (visibleTransactions.length <= 1) {
	turnOffMobileSelectionMode();
	}
	return (
	<HeaderWithBackButton
	title={translate('common.selectMultiple')}
	onBackButtonPress={() => {
	clearSelectedTransactions(true);
	turnOffMobileSelectionMode();
	}}
	/>
	);
	}
	return (
	<View style={[styles.pt0, styles.borderBottom]}>
	<HeaderWithBackButton
	shouldShowReportAvatarWithDisplay
	shouldDisplayStatus
	shouldShowPinButton={false}
	report={moneyRequestReport}
	shouldShowBackButton={shouldShowBackButton}
	shouldDisplaySearchRouter={shouldDisplaySearchRouter}
	shouldDisplayHelpButton={!(isReportInRHP && shouldUseNarrowLayout)}
	onBackButtonPress={onBackButtonPress}
	shouldShowBorderBottom={false}
	shouldEnableDetailPageNavigation
	openParentReportInCurrentTab
	>
	{shouldShowHeaderButtonsInHeaderRow && (
	<MoneyReportHeaderActions
	reportID={reportIDProp}
	primaryAction={primaryAction}
	isReportInSearch={isReportInSearch}
	backTo={backTo}
	/>
	)}
	</HeaderWithBackButton>
	{!shouldShowHeaderButtonsInHeaderRow && (
	<MoneyReportHeaderActions
	reportID={reportIDProp}
	primaryAction={primaryAction}
	isReportInSearch={isReportInSearch}
	backTo={backTo}
	/>

App/src/hooks/useReportPrimaryAction.ts

Lines 52 to 69 in 09ce5e0

	const nonPendingDeleteTransactions = Object.values(reportTransactions).filter((t) => !isTransactionPendingDelete(t));
	return getReportPrimaryAction({
	currentUserLogin: currentUserLogin ?? '',
	currentUserAccountID: accountID,
	report: moneyRequestReport,
	chatReport,
	reportTransactions: nonPendingDeleteTransactions,
	violations,
	bankAccountList,
	policy,
	reportNameValuePairs,
	reportActions,
	reportMetadata,
	isChatReportArchived,
	invoiceReceiverPolicy,
	ownerLogin,
	});

getReportPrimaryAction only returns Submit when isSubmitAction succeeds. That predicate currently classifies a report as having no submittable transaction when every transaction is scanning, so a newly created report containing only the in-flight receipt returns no primary action. Once SmartScan changes the transaction out of the scanning state, the condition becomes false and Submit appears, matching the recording.

App/src/libs/ReportPrimaryActionUtils.ts

Lines 113 to 164 in 09ce5e0

	function isSubmitAction(
	report: Report,
	reportTransactions: Transaction[],
	reportMetadata: OnyxEntry<ReportMetadata>,
	ownerLogin: string | undefined,
	policy?: Policy,
	reportNameValuePairs?: ReportNameValuePairs,
	violations?: OnyxCollection<TransactionViolation[]>,
	currentUserEmail?: string,
	currentUserAccountID?: number,
	) {
	if (isArchivedReport(reportNameValuePairs)) {
	return false;
	}
	const isExpenseReport = isExpenseReportUtils(report);
	const isReportSubmitter = isCurrentUserSubmitter(report);
	const isOpenReport = isOpenReportUtils(report);
	if (hasPendingDEWSubmit(reportMetadata, hasDynamicExternalWorkflow(policy))) {
	return false;
	}
	if (!isGroupPolicy(policy)) {
	return false;
	}
	const reportTransactionsList = reportTransactions ?? [];
	const hasNoSubmittableTransaction =
	reportTransactionsList.length > 0 &&
	reportTransactionsList.every(
	(transaction) => isScanning(transaction) || (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
	);
	if (hasNoSubmittableTransaction) {
	return false;
	}
	if (violations && currentUserEmail && currentUserAccountID !== undefined) {
	if (reportTransactions.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, ownerLogin, policy))) {
	return false;
	}
	}
	const submitToAccountID = getSubmitToAccountID(policy, report, ownerLogin);
	if (submitToAccountID === report.ownerAccountID && policy?.preventSelfApproval && !isReportSubmitter) {
	return false;
	}
	return isExpenseReport && isReportSubmitter && isOpenReport && reportTransactions.length !== 0;
	}

App/src/libs/ReportPrimaryActionUtils.ts

Lines 528 to 540 in 09ce5e0

	}
	if (isRemoveHoldAction(report, chatReport, reportTransactions) || (isPayActionWithAllExpensesHeld && expensesToHold.length)) {
	return CONST.REPORT.PRIMARY_ACTIONS.REMOVE_HOLD;
	}
	if (isPrimaryMarkAsResolvedAction(currentUserLogin, currentUserAccountID, report, ownerLogin, reportTransactions, violations, policy)) {
	return CONST.REPORT.PRIMARY_ACTIONS.MARK_AS_RESOLVED;
	}
	if (isSubmitAction(report, reportTransactions, reportMetadata, ownerLogin, policy, reportNameValuePairs, violations, currentUserLogin, currentUserAccountID) && !allExpensesHeld) {
	return CONST.REPORT.PRIMARY_ACTIONS.SUBMIT;
	}

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

In ReportPrimaryActionUtils.isSubmitAction, stop treating an actively scanning receipt as inherently non-submittable. Keep the existing blockers for pending Expensify Card transactions, SmartScan failures with missing fields, submission-blocking violations, archived reports, and the other report/policy checks. Leave the separate scanning guard in isApproveAction unchanged so an approver still cannot act on a submitted report before its receipt finishes scanning.

App/src/libs/ReportPrimaryActionUtils.ts

Lines 140 to 175 in 09ce5e0

	const reportTransactionsList = reportTransactions ?? [];
	const hasNoSubmittableTransaction =
	reportTransactionsList.length > 0 &&
	reportTransactionsList.every(
	(transaction) => isScanning(transaction) || (isExpensifyCardTransaction(transaction) && isPending(transaction)) || hasSmartScanFailedWithMissingFields([transaction], report),
	);
	if (hasNoSubmittableTransaction) {
	return false;
	}
	if (violations && currentUserEmail && currentUserAccountID !== undefined) {
	if (reportTransactions.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, ownerLogin, policy))) {
	return false;
	}
	}
	const submitToAccountID = getSubmitToAccountID(policy, report, ownerLogin);
	if (submitToAccountID === report.ownerAccountID && policy?.preventSelfApproval && !isReportSubmitter) {
	return false;
	}
	return isExpenseReport && isReportSubmitter && isOpenReport && reportTransactions.length !== 0;
	}
	function isApproveAction(report: Report, reportTransactions: Transaction[], currentUserAccountID: number, reportMetadata: OnyxEntry<ReportMetadata>, policy?: Policy) {
	if (isSubmitterApproveBlockedOnSubmitWorkspace(policy, report.ownerAccountID, currentUserAccountID)) {
	return false;
	}
	const isAnyReceiptBeingScanned = reportTransactions?.some((transaction) => isScanning(transaction));
	if (isAnyReceiptBeingScanned) {
	return false;
	}

Apply the same change to ReportWorkflow.canSubmitReport, which repeats the same "no submittable transaction" test for report capabilities used outside the header. Updating both predicates keeps the report header and search/to-do surfaces consistent while preserving every non-scanning blocker.

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

Lines 265 to 303 in 09ce5e0

	function canSubmitReport(
	report: OnyxEntry<OnyxTypes.Report>,
	reportOwnerLogin: string | undefined,
	policy: OnyxEntry<OnyxTypes.Policy>,
	transactions: OnyxTypes.Transaction[],
	allViolations: OnyxCollection<OnyxTypes.TransactionViolations> | undefined,
	isReportArchived: boolean,
	currentUserEmailParam: string,
	currentUserAccountID: number,
	) {
	const isOpenExpenseReport = isOpenExpenseReportReportUtils(report);
	const isAdmin = policy?.role === CONST.POLICY.ROLE.ADMIN;
	const hasAllPendingRTERViolations = allHavePendingRTERViolation(transactions, allViolations, currentUserEmailParam, currentUserAccountID, report, reportOwnerLogin, policy);
	const hasTransactionWithoutRTERViolation = hasAnyTransactionWithoutRTERViolation(
	transactions,
	allViolations,
	currentUserEmailParam,
	currentUserAccountID,
	report,
	reportOwnerLogin,
	policy,
	);
	const hasNoSubmittableTransaction =
	transactions.length > 0 && transactions.every((t) => isScanningTransaction(t) || (isExpensifyCardTransaction(t) && isPending(t)) || hasSmartScanFailedWithMissingFields([t], report));
	const hasAnySubmissionBlockingViolations = transactions.some((transaction) =>
	hasSubmissionBlockingViolations(transaction, allViolations, currentUserEmailParam, currentUserAccountID, report, reportOwnerLogin, policy),
	);
	return (
	isOpenExpenseReport &&
	(report?.ownerAccountID === currentUserAccountID || report?.managerID === currentUserAccountID || isAdmin) &&
	!hasNoSubmittableTransaction &&
	!hasAllPendingRTERViolations &&
	hasTransactionWithoutRTERViolation &&
	!isReportArchived &&
	!hasAnySubmissionBlockingViolations &&
	transactions.length > 0
	);
	}

Test coverage:

• Add a ReportPrimaryActionUtils unit case for an open expense report whose only transaction is SCANNING, and assert that its primary action is Submit.
• Add a canSubmitReport unit case for the same scanning-only draft and assert that it is eligible for submission.
• Retain or extend cases showing that pending-card-only and SmartScan-failed-with-missing-fields reports remain ineligible, and that a submitted report with a scanning receipt still does not expose Approve.
• Manually repeat the issue flow on web and native: create the scanned expense before SmartScan completes, verify Submit is immediately present on the report, submit it, and confirm the report updates normally when scan results arrive.

What alternative solutions did you explore? (Optional)

I considered changing the confirmation-page loader or footer. The recording rules that out: the confirmation page already displays its Create expense button, and the missing Submit action occurs only after navigation to the expense report. Changing that page would not affect the report-header predicate that removes Submit.

I also considered changing only ReportPrimaryActionUtils, because that directly controls the visible header button. However, ReportWorkflow.canSubmitReport contains the same scanning exclusion and feeds other report-capability consumers, so a header-only change would leave inconsistent submission eligibility elsewhere.