[$250] Paid report remains under the Approved filter in New Expensify and only shows “View,” while Classic still allows a workspace admin to mark it as paid

[izarutskaya]

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

---

Version Number:
Reproducible in staging?: Needs Reproduction (unable to check customer's account)
Reproducible in production?: Needs Reproduction (unable to check customer's account)
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @Leeckhart
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Log in as workspace admin
2. Go to Spend > Reports in New Expensify.
3. Filter by workspace Workspace 1 and status Approved.
4. Locate Report 1
5. Observe that the report appears in the Approved list, but the only available action is View.
6. Compare it with Report 2, which shows the expected Pay / Mark as paid option.
7. Open the same report in Expensify Classic and confirm that the workspace admin has the option to mark it as paid.
8. While the issue was being investigated, the approver, X, successfully marked the report as paid.

Expected Result:

If the report is still Approved and the workspace admin has permission to mark reports as paid, New Expensify should display the Pay / Mark as paid action.
If the report has already been marked as paid, it should no longer appear when filtering reports by Approved status.
The available status and actions should also be consistent between New Expensify and Classic.

Actual Result:

The report appeared under the Approved status filter in New Expensify, but the workspace admin only saw View and could not mark it as paid.
Expensify Classic still displayed the option to mark the report as paid.
Logs later confirmed that the report had been marked as paid by X and was in a reimbursed/manual-paid state, but it continued appearing under the Approved filter. This made the report state and available actions misleading.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

For the customer's details check please the OP

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022084973008107477512
• Upwork Job ID: 2084973008107477512
• Last Price Increase: 2026-08-12

[exfy-zapier]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

There are two distinct bugs here. The stale‑filter symptom is a confirmed client‑side issue; the "View only" symptom is a payer‑permission divergence from Classic.

What is the root cause of that problem?

1. Paid report still appears under the "Approved" filter — stale Search snapshot (high confidence).

In the Reports (group‑by‑report) view, a report's status is classified client‑side from the copy of the report stored inside the backend Search snapshot, not from the live report. APPROVED and PAID are mutually exclusive by statusNum:

• SearchUIUtils.ts:417‑427 — APPROVED requires statusNum === APPROVED; PAID requires statusNum === REIMBURSED.
• SearchUIUtils.ts:2940‑2976 — report rows and their status are built from data[report_<id>] (the snapshot's stored report).

When the report is paid, the optimistic update writes statusNum: REIMBURSED only to the live report_<id> Onyx key — it never touches the snapshot:

• PayMoneyRequest.ts:329‑348.

The snapshot‑fan‑out helper that does keep snapshots in sync (getSearchOnyxUpdate) is only called by expense‑creation flows (TrackExpense / MoneyRequestBuilder / SendInvoice), never by the pay flow. And regular status searches render the raw snapshot — only "to‑do" searches merge live data (SearchResultsProvider.tsx:46‑72). So the snapshot keeps saying APPROVED and the paid report stays under the Approved filter until a fresh Search re‑fetch overwrites it.

2. Only "View" (no Pay / Mark as paid) for an Approved report (medium confidence).

The row action is also computed client‑side. PAY is only offered if canIOUBePaid() → isPayer() passes; otherwise getActions() collapses to VIEW (SearchUIUtils.ts:2438‑2573). On a manual‑reimbursement workspace, isPayer returns true only for the designated reimburser — a different workspace admin gets false → PAY dropped → "View" only. This matches the report: the approver X (not the observing admin) is who ultimately paid it. Classic lets any admin mark‑as‑paid, so the two clients legitimately disagree. Other branches that can also collapse to View: policy data missing type/achAccount/reimburser in the snapshot, reimbursementChoice === no, reimbursableSpend <= 0, or isAutoReimbursable.

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

• For bug 1 (the clear one): have the pay flow keep loaded Search snapshots in sync with the report status change — i.e. route the pay optimistic/success/failure data through the same getSearchOnyxUpdate fan‑out that expense creation uses, so the snapshot's report_<id>.statusNum moves to REIMBURSED. That both removes it from the Approved filter and (via the settled early‑return) flips its row action to "Paid". Extending the shouldUseLiveData live‑merge to status searches would also fix it but is broader.
• For bug 2: first confirm the intended rule. If any workspace admin should be able to mark‑as‑paid (to match Classic), the fix is in isPayer's manual‑reimbursement branch. Because the source‑of‑truth for payability lives partly on the backend and Classic computes it server‑side, this part likely needs an internal engineer to confirm the intended behavior before changing client rules.

What alternative solutions did you explore? (Optional)

Triggering an automatic Search re‑fetch after a pay while the user stays on the Reports page would clear the stale row, but it's a heavier network‑driven fix than syncing the snapshot optimistically.

Reproduction & confidence notes

• Bug 1 reproduces without special data: on the Reports view with status:approved, pay/mark‑as‑paid a report and it lingers under Approved until the search is re‑run. High confidence, code‑level.
• Bug 2 depends on the workspace's reimbursement config (manual vs auto) and whether the observing admin is the designated reimburser / a bank‑account sharee — which isn't in the report, hence medium confidence on the exact branch. Confirming with the affected policyID's reimbursement settings and the admin's role would pin it.
• This maps to the Bug label; the fix for bug 1 is entirely within Expensify/App.

Related open issues: none of the current open Pay/Mark‑as‑paid issues (Expensify/App#93699, #95832, #94712) cover the stale‑Approved‑filter symptom — they're about bulk‑pay button behavior, so this appears distinct.

---

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

[melvin-bot]

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

[mukhrr]

@eh2077 I can reproduce this, fyi..

[eh2077]

@mukhrr thanks for your comment. Can you share reproduction video and post a proposal to fix the issue?

🆘 C+ Help Wanted

[ahmdshrif]

Proposal

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

A workspace admin filters Spend > Reports by status: Approved. A report already marked as paid (stateNum: APPROVED, statusNum: REIMBURSED) still appears in that Approved list with View as its only action. It should have dropped out of the Approved filter once it was paid.

What is the root cause of that problem?

The Reports tab never re-applies the status filter to its rows. The client-side "does this row still belong under the active status filter?" re-check is hard-gated to one data type, and the Reports tab is a different one.

1. Spend > Reports is the REPORTS suggested search: query type EXPENSE_REPORT ('expense-report'), not EXPENSE —

   App/src/libs/SearchUIUtils.ts

   Lines 776 to 781 in 0a0e504

   	[CONST.SEARCH.SEARCH_KEYS.REPORTS]: {
   	key: CONST.SEARCH.SEARCH_KEYS.REPORTS,
   	translationPath: 'search.tabs.reports',
   	type: CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT,
   	icon: 'Document',
   	searchQuery: buildCannedSearchQuery({type: CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT}),

   — and getSections routes that type to getReportSections —

   App/src/libs/SearchUIUtils.ts

   Lines 3749 to 3750 in 0a0e504

   	if (type === CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT) {
   	return getReportSections({

2. In getReportSections, the per-row visibility line calls isEligibleForStatus only when the query type is EXPENSE. Substituting this repro, 'expense-report' === 'expense' is false, so the ternary falls to : true and shouldShow is unconditionally true — the status filter never runs on this tab:

   App/src/libs/SearchUIUtils.ts

   Lines 2947 to 2948 in 0a0e504

   	const isActionLoading = !!isActionLoadingSet?.has(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportItem.reportID}`);
   	const shouldShow = !isActionLoading && currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE ? isEligibleForStatus(currentQueryJSON, reportItem) : true;

3. The predicate that would have removed the row is already correct — Approved requires statusNum === APPROVED (3) and a paid report is REIMBURSED (4), so it returns false. It is simply never called:

   App/src/libs/SearchUIUtils.ts

   Line 421 in 0a0e504

   [CONST.SEARCH.STATUS.EXPENSE.APPROVED]: (expenseReport) => expenseReport?.stateNum === CONST.REPORT.STATE_NUM.APPROVED && expenseReport.statusNum === CONST.REPORT.STATUS_NUM.APPROVED,

4. The row's report data is already current, so this is a filtering bug, not stale data: getActions returns PAID for a settled report (isSettled = statusNum === REIMBURSED) —

   App/src/libs/SearchUIUtils.ts

   Lines 2475 to 2477 in 0a0e504

   	if (isSettled(report) && !isExportAvailable) {
   	return [CONST.SEARCH.ACTION_TYPES.PAID];
   	}

   — and ActionCell renders PAID with the View label —

   App/src/components/Search/SearchList/ListItem/ActionCell/index.tsx

   Lines 61 to 64 in 0a0e504

   	const shouldUseViewAction = action === CONST.SEARCH.ACTION_TYPES.VIEW || action === CONST.SEARCH.ACTION_TYPES.PAID || action === CONST.SEARCH.ACTION_TYPES.DONE;
   	if (shouldUseViewAction || (isChildListItem && action !== CONST.SEARCH.ACTION_TYPES.UNDELETE)) {
   	const text = translate(actionTranslationsMap[CONST.SEARCH.ACTION_TYPES.VIEW]);

   . That is exactly the reported "only shows View": the app knows the report is paid, it just failed to drop it from the Approved bucket.
5. The sibling path proves the divergence: getTransactionsSections (Expenses tab) runs the same check behind the same === EXPENSE gate, which is why Expenses is unaffected —

   App/src/libs/SearchUIUtils.ts

   Lines 2209 to 2213 in 0a0e504

   	shouldShow = false;
   	} else if (!isActionLoading && currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE) {
   	const skipStatusFilterForOptimisticItem = isTrackedOptimisticItem && canOptimisticExpenseMatchStatusFilter(currentQueryJSON);
   	if (!skipStatusFilterForOptimisticItem) {
   	shouldShow = isEligibleForStatus(currentQueryJSON, report, transactionItem.reportID);

6. The write side already treats expense-report as status-filterable: shouldOptimisticallyUpdateSearch accepts EXPENSE_REPORT queries and runs isEligibleForStatus —

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

   Lines 52 to 72 in 0a0e504

   	) {
   	if (
   	currentSearchQueryJSON.type !== CONST.SEARCH.DATA_TYPES.INVOICE &&
   	currentSearchQueryJSON.type !== CONST.SEARCH.DATA_TYPES.EXPENSE &&
   	currentSearchQueryJSON.type !== CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT
   	) {
   	return false;
   	}
   	const currentSearchPolicyIDs = getFilterFromQuery(currentSearchQueryJSON, CONST.SEARCH.SYNTAX_FILTER_KEYS.POLICY_ID);
   	if (currentSearchPolicyIDs.value?.length && iouReport?.policyID) {
   	if (!currentSearchPolicyIDs.isNegated && !currentSearchPolicyIDs.value.includes(iouReport.policyID)) {
   	return false;
   	}
   	if (currentSearchPolicyIDs.isNegated && currentSearchPolicyIDs.value.includes(iouReport.policyID)) {
   	return false;
   	}
   	}
   	const shouldOptimisticallyUpdateByStatus = isEligibleForStatus(currentSearchQueryJSON, iouReport, transaction?.reportID);

   . The producer filters by status for this type; the renderer does not. That asymmetry is the bug.

Affected paths: getReportSections for every Reports-tab status (a done/paid report lingers under approved the same way); narrow and wide layouts and all platforms alike, since the gate sits in the shared data layer above ListItem (no .native variant); the same gate leaves type: invoice unfiltered on the transaction path.

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

Make the status re-check cover the Reports tab, in getReportSections:

App/src/libs/SearchUIUtils.ts

Lines 2947 to 2948 in 0a0e504

	const isActionLoading = !!isActionLoadingSet?.has(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportItem.reportID}`);
	const shouldShow = !isActionLoading && currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE ? isEligibleForStatus(currentQueryJSON, reportItem) : true;

:

const isStatusFilterableType =
    currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE || currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE_REPORT;
const shouldShow = !isActionLoading && isStatusFilterableType ? isEligibleForStatus(currentQueryJSON, reportItem) : true;

Regression safety: isEligibleForStatus returns true when the query carries no status filter (

App/src/libs/SearchUIUtils.ts

Lines 2114 to 2117 in 0a0e504

	const status = getFilterFromQuery(currentQueryJSON, CONST.SEARCH.SYNTAX_FILTER_KEYS.STATUS);
	if (!status.value) {
	return true;
	}

), and every value in CONST.SEARCH.STATUS.EXPENSE_REPORT (drafts/outstanding/approved/done/paid) is already a key of expenseStatusActionMapping, so no Reports-tab status can be wrongly rejected. I would add a getSections case to tests/unit/SearchUIUtilsTest.ts covering a REIMBURSED report under type:expense-report status:approved.

Why the obvious spot fixes do not work:

• Changing the Approved predicate is a no-op — it already returns false for statusNum: REIMBURSED; the type gate in step 2 short-circuits before it ever runs.
• The existing snapshot-removal path in getSearchActionOnyxData only fires when currentSearchKey is in snapshotRemovalKeys (PAY / APPROVE) —

  App/src/libs/actions/Search.ts

  Lines 470 to 476 in 0a0e504

  	if (currentSearchKey && snapshotRemovalKeys?.includes(currentSearchKey)) {
  	successData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.SNAPSHOT}${hash}`,
  	value: {data: {[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]: null}},
  	});
  	}

  . Here the approver paid from a different surface, so no local optimistic update ran at all. Only a render-time re-filter fixes a row whose status changed out of band.

What alternative solutions did you explore? (Optional)

1. Refetch the search on every statusNum change. Heavy: a round-trip per Pusher update, and the wrong row shows until it returns. The data needed is already local.
2. Hide View-only rows under an actionable status filter. A symptom patch at the wrong layer: it would also hide legitimately Approved reports this user just cannot pay, and the row count stays wrong.
3. Lift the gate into getSections for every type. Cleaner long-term, but chat/task/trip use status vocabularies absent from expenseStatusActionMapping, so it risks blanking those tabs. I kept the change scoped to expense-report; invoice can follow in the same shape.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-06 14:33:44 UTC.

Proposal

What is the root cause of that problem?

Following the clarified scope (non-reimbursable reports missing the "mark it as paid" option on the report detail page), I traced and live-tested all three configurations, because current main behaves differently in each:

1. Designated payer, payments configured — already works on latest main. I verified this live on dev: an approved report containing only a non-reimbursable expense shows the "Mark as paid" primary button, both on the report page and when opened from Search. canIOUBePaid explicitly admits only-non-reimbursable reports on the pay-elsewhere path, and isPrimaryPayAction has the matching clause:

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

Lines 250 to 252 in 29ced8e

	const isIOU = isIOUReport(iouReport);
	const canShowMarkedAsPaidForNegativeAmount = onlyShowPayElsewhere && reimbursableSpend < 0;
	const isOnlyNonReimbursablePayElsewhere = onlyShowPayElsewhere && nonReimbursableSpend !== 0 && hasOnlyNonReimbursableTransactions(iouReport?.reportID, transactions);

App/src/libs/ReportPrimaryActionUtils.ts

Lines 244 to 252 in 29ced8e

	if (
	canPayReport &&
	isExpenseReport &&
	arePaymentsEnabled &&
	isReportFinished &&
	(reimbursableSpend !== 0 || (nonReimbursableSpend !== 0 && hasOnlyNonReimbursableTransactions(report?.reportID, reportTransactions)))
	) {
	return isSecondaryAction ?? !didExportFail;
	}

2. Admin who is not the designated payer — excluded today, fix already in flight. isPayer only admits the designated reimburser on manual-reimbursement policies (and on pay-with-Expensify policies, the reimburser or an admin the bank account is shared with), so a plain workspace admin gets no pay action at all — the "No further action required!" state:

App/src/libs/ReportUtils.ts

Lines 2854 to 2886 in 29ced8e

	// Pay-elsewhere / mark-paid flows for disabled reimbursement still allow any admin to act.
	if (onlyShowPayElsewhere && reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO) {
	return isAdmin;
	}
	const isAutoReimbursement = reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES;
	const isManualReimbursement = reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL;
	// Reimbursement is disabled for this workspace.
	if (!isAutoReimbursement && !isManualReimbursement) {
	return false;
	}
	const reimburserEmail = policy?.reimburser ?? policy?.achAccount?.reimburser ?? (isManualReimbursement ? policy?.owner : '');
	// No designated reimburser means any workspace admin can pay.
	if (!reimburserEmail) {
	return isAdmin;
	}
	const canPayOnPolicy = isAdmin || (!!currentUserEmailParam && canMemberWritePolicyUtils(policy, currentUserEmailParam, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));
	const isReimburser = currentUserEmailParam === reimburserEmail && canPayOnPolicy;
	// If using auto reimbursement, then the reimburser can pay, or an admin with access to the business bank account.
	if (isAutoReimbursement) {
	const bankAccountID = policy?.achAccount?.bankAccountID;
	const bankAccount = bankAccountID ? bankAccountList?.[bankAccountID] : null;
	const hasAccessToBankAccount = currentUserEmailParam && bankAccount?.accountData?.sharees ? bankAccount.accountData.sharees.includes(currentUserEmailParam) : false;
	return isReimburser || (isAdmin && hasAccessToBankAccount);
	}
	// If using manual reimbursement, only the designated reimburser can pay.

This is what open PR #95925 ("Allow any workspace admin to pay reports", issue #95750) addresses through a new canAdminPayReport() in canIOUBePaid — it already carries a test named "allows admins to mark report with only non-reimbursable expenses as paid (onlyShowPayElsewhere=true)". I would not duplicate that work here.

3. Payments-disabled/unconfigured workspace — nobody can mark a finished report paid, and this is the gap this issue can own. canIOUBePaid has a pay-elsewhere carve-out for REIMBURSEMENT_NO policies, but it only admits SUBMITTED reports, so an approved report is rejected immediately:

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

Lines 217 to 224 in 29ced8e

	if (policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO) {
	if (!onlyShowPayElsewhere) {
	return false;
	}
	if (iouReport?.statusNum !== CONST.REPORT.STATUS_NUM.SUBMITTED) {
	return false;
	}
	}

And even for submitted reports that carve-out is currently unreachable for expense reports, because the final condition requires arePaymentsEnabled (which is reimbursementChoice !== reimburseNo):

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

Lines 264 to 273 in 29ced8e

	return (
	canPay &&
	isReportFinished &&
	!iouSettled &&
	(reimbursableSpend > 0 || canShowMarkedAsPaidForNegativeAmount || isOnlyNonReimbursablePayElsewhere) &&
	!isChatReportArchived &&
	!isAutoReimbursable &&
	!isPayAtEndExpenseReport &&
	(!isExpenseReport(iouReport) || arePaymentsEnabled(policy as OnyxEntry<OnyxTypes.Policy>))
	);

isPrimaryPayAction requires arePaymentsEnabled too, so neither the primary button nor the secondary menu ever offers it:

App/src/libs/ReportPrimaryActionUtils.ts

Lines 225 to 252 in 29ced8e

	const canPayReport =
	isReportPayer ||
	(canNonPayerAdminPay &&
	policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL &&
	canMemberWrite(policy, currentUserLogin, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));
	const arePaymentsEnabled = arePaymentsEnabledUtils(policy);
	const isReportApproved = isReportApprovedUtils({report});
	const isReportClosed = isClosedReportUtils(report);
	const isProcessingReport = isProcessingReportUtils(report);
	const isExported = isExportedUtil(reportActions, report);
	const hasExportError = hasExportErrorUtil(reportActions, report);
	const didExportFail = !isExported && hasExportError;
	const isApprovalEnabled = policy ? policy.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const isSubmittedWithoutApprovalsEnabled = !isApprovalEnabled && isProcessingReport;
	const isReportFinished = (isReportApproved && !report.isWaitingOnBankAccount) || isSubmittedWithoutApprovalsEnabled || isReportClosed;
	const {reimbursableSpend, nonReimbursableSpend} = getMoneyRequestSpendBreakdown(report);
	if (
	canPayReport &&
	isExpenseReport &&
	arePaymentsEnabled &&
	isReportFinished &&
	(reimbursableSpend !== 0 || (nonReimbursableSpend !== 0 && hasOnlyNonReimbursableTransactions(report?.reportID, reportTransactions)))
	) {
	return isSecondaryAction ?? !didExportFail;
	}

So on a workspace whose payments were never configured in NewDot (common for policies managed from Classic), an approved report shows "No further action required!" with no way to record the manual payment, while Classic still lets the admin mark it as paid. isPayer already intends to allow this ("Pay-elsewhere / mark-paid flows for disabled reimbursement still allow any admin to act"), but the downstream guards make it unreachable.

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

Complementing PR #95925 (which handles the non-payer-admin case on payments-configured workspaces), I would make the mark-as-paid path reachable for finished reports on unconfigured-payments workspaces.

In canIOUBePaid, accept finished reports on the pay-elsewhere carve-out and exempt that path from the payments-enabled requirement:

     if (policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO) {
         if (!onlyShowPayElsewhere) {
             return false;
         }
-        if (iouReport?.statusNum !== CONST.REPORT.STATUS_NUM.SUBMITTED) {
+        if (iouReport?.statusNum !== CONST.REPORT.STATUS_NUM.SUBMITTED && !isReportApproved({report: iouReport}) && !isClosedReportUtil(iouReport)) {
             return false;
         }
     }
     ...
-        (!isExpenseReport(iouReport) || arePaymentsEnabled(policy as OnyxEntry<OnyxTypes.Policy>))
+        (!isExpenseReport(iouReport) || arePaymentsEnabled(policy as OnyxEntry<OnyxTypes.Policy>) || onlyShowPayElsewhere)

isPayer already returns isAdmin on this path, so any workspace admin qualifies, matching Classic. Then surface it in the header: in isPrimaryPayAction, allow the PAY action when only the elsewhere path qualifies (mirroring the canIOUBePaid(..., onlyShowPayElsewhere=true) result) instead of unconditionally requiring arePaymentsEnabled. The header already renders the reduced "Mark as paid" button on its own, because the settlement options collapse to pay-elsewhere-only whenever canIOUBePaid(false) fails but canIOUBePaid(true) passes — the same mechanism I verified live in case 1.

I would add regression tests around canIOUBePaid: an approved non-reimbursable-only report on a REIMBURSEMENT_NO policy must return true for onlyShowPayElsewhere (currently false), and the existing configured-payments cases must stay unchanged. One thing to confirm with internal: Auth must accept the pay-elsewhere PayMoneyRequest on such policies from an admin. Classic already permits the equivalent, so this should be a no-op server-side.

What alternative solutions did you explore? (Optional)

The stale Approved-filter row (my original proposal on this issue), which I reproduced and fixed locally. The OP also reports the paid report continuing to appear under the Approved filter with only "View". That is a separate, real defect in the Reports search: getReportSections only re-validates a row against the selected status when the query type is expense, but Spend > Reports issues an expense-report query, so the gate never passes and stale rows survive:

App/src/libs/SearchUIUtils.ts

Lines 2950 to 2952 in 29ced8e

	const isActionLoading = !!isActionLoadingSet?.has(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportItem.reportID}`);
	const shouldShow = !isActionLoading && currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE ? isEligibleForStatus(currentQueryJSON, reportItem) : true;

The report data itself does update, because Onyx mirrors report-field changes into loaded Search snapshots, and the existing predicate already distinguishes Approved from Paid:

App/src/libs/SearchUIUtils.ts

Lines 421 to 427 in 29ced8e

	const expenseStatusActionMapping: Record<string, ExpenseStatusPredicate> = {
	[CONST.SEARCH.STATUS.EXPENSE.DRAFTS]: (expenseReport) => expenseReport?.stateNum === CONST.REPORT.STATE_NUM.OPEN && expenseReport.statusNum === CONST.REPORT.STATUS_NUM.OPEN,
	[CONST.SEARCH.STATUS.EXPENSE.OUTSTANDING]: (expenseReport) =>
	expenseReport?.stateNum === CONST.REPORT.STATE_NUM.SUBMITTED && expenseReport.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED,
	[CONST.SEARCH.STATUS.EXPENSE.APPROVED]: (expenseReport) => expenseReport?.stateNum === CONST.REPORT.STATE_NUM.APPROVED && expenseReport.statusNum === CONST.REPORT.STATUS_NUM.APPROVED,
	[CONST.SEARCH.STATUS.EXPENSE.PAID]: (expenseReport) =>
	(expenseReport?.stateNum ?? 0) >= CONST.REPORT.STATE_NUM.APPROVED && expenseReport?.statusNum === CONST.REPORT.STATUS_NUM.REIMBURSED,

Which is why the row's action flips to PAID (rendered as "View") while the row stays under Approved:

App/src/libs/SearchUIUtils.ts

Lines 2479 to 2481 in 29ced8e

	if (isSettled(report) && !isExportAvailable) {
	return [CONST.SEARCH.ACTION_TYPES.PAID];
	}

App/src/components/Search/SearchList/ListItem/ActionCell/index.tsx

Lines 61 to 63 in 29ced8e

	const shouldUseViewAction = action === CONST.SEARCH.ACTION_TYPES.VIEW || action === CONST.SEARCH.ACTION_TYPES.PAID || action === CONST.SEARCH.ACTION_TYPES.DONE;
	if (shouldUseViewAction || (isChildListItem && action !== CONST.SEARCH.ACTION_TYPES.UNDELETE)) {

I reproduced this end to end on dev web with two approved reports and a second signed-in session marking one as paid: before the fix the paid report stayed under status:approved showing "View" while the other kept Pay; after the fix it left the list immediately and the other was unaffected. The fix is a one-liner, since getReportSections has only the expense-report call site and isEligibleForStatus already returns true when no status filter is set:

-const shouldShow = !isActionLoading && currentQueryJSON?.type === CONST.SEARCH.DATA_TYPES.EXPENSE ? isEligibleForStatus(currentQueryJSON, reportItem) : true;
+const shouldShow = !isActionLoading ? isEligibleForStatus(currentQueryJSON, reportItem) : true;

Extending #95925's canAdminPayReport() to also cover REIMBURSEMENT_NO policies would collapse cases 2 and 3 into one change, but that helper deliberately mirrors isPolicyPayer's "reimbursement must be explicitly configured" rule, and widening an open PR's scope would block both fixes on one review. Keeping this issue's change on the onlyShowPayElsewhere path keeps them orthogonal.