Search page shows Pay action for expense reports on personal/deleted policies

[luacmartins]

Problem

The Search page surfaces a Pay button for closed expense reports on personal policies and deleted policies, even though paying such reports always fails server-side with a 406 Unsupported policy type for this action error.

Auth's guard at PayMoneyRequest.cpp:254 correctly rejects these payments because:

• Policy type is not corporate or team (personal policy), OR
• Policy has been deleted (NVP renamed to private_expensify_DELETED_policy{ID}), causing Policy::getType() to return an empty string

This means users can initiate a batch-pay from Search (PayMoneyRequestOnSearch) that silently fails, with the error embedded in the Onyx snapshot update rather than surfaced as a clear UI message.

Root Cause

canIOUBePaid contains an isPaidGroupPolicy check, but there appears to be a stale-snapshot path through the negative-amount "Mark as paid Elsewhere" flow in Search that bypasses this gate and still renders the Pay action.

Related server-side issue: Expensify/Expensify#619510

Expected Behavior

The Pay action should not be shown in Search for expense reports on:

• Personal policies
• Deleted policies

Actual Behavior

The Pay button is shown and when tapped it results in a silent failure (406 from server), giving users no clear feedback about why the action cannot be completed.

Version

Reproduced on 9.3.78-1 (latest as of May 2026)

[godzillaxbox19982014-lgtm]

Proposal

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

Search can show the Pay / Mark as paid action for expense reports that belong to a personal policy or a deleted policy. When the user clicks it, Search sends PayMoneyRequestOnSearch, but Auth rejects it with 406 Unsupported policy type for this action.

What is the root cause of that problem?

Search is using canIOUBePaid() as the gate for whether to show the Pay action, but canIOUBePaid() does not first reject non-paid-group expense reports.

There are two Search paths using that helper:

• src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx:L45-L47 checks both normal pay and the onlyShowPayElsewhere=true path, then passes onlyShowPayElsewhere into SettlementButton at L91.
• src/libs/SearchUIUtils.ts:L2359-L2377 also adds the PAY action when either canBePaid or shouldOnlyShowElsewhere is true.

The problem is inside src/libs/actions/IOU/ReportWorkflow.ts:L199-L227. That code checks payer/report status/spend, but it never has a clear "expense reports must be on a paid group policy" guard. The final check is only arePaymentsEnabled(policy), and src/libs/PolicyUtils.ts:L1075-L1076 only checks that the reimbursement choice is not REIMBURSEMENT_NO; it does not prove the policy is team or corporate.

So on the negative-amount / "mark as paid elsewhere" path, canShowMarkedAsPaidForNegativeAmount can make canIOUBePaid(..., true) pass. For deleted/stale policies, ReportUtils.isPayer() can still fall through the admin/manager checks around src/libs/ReportUtils.ts:L2682-L2708, and for personal expense reports the manager path can also pass. Search then renders Pay even though the backend only allows this command for paid group policies.

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

I would fix it centrally in canIOUBePaid() rather than only hiding the Search button.

After the invoice-report branch and before calculating isPayer, add a guard for expense reports:

if (isExpenseReport(iouReport) && !isPaidGroupPolicy(policy)) {
    return false;
}

isPaidGroupPolicy(policy) is already imported from PolicyUtils, and it only returns true for team or corporate policies (src/libs/PolicyUtils.ts:L941-L942). That means personal policies, missing/deleted policy data, or stale policies with no valid paid type will not show Pay / Mark as paid from Search.

This should fix both the row action and bulk Search action because both paths go through canIOUBePaid().

I would also add regression coverage in tests/actions/IOUTest/ReportWorkflowTest.ts for:

• a submitted/closed negative-amount expense report on a personal policy where onlyShowPayElsewhere=true still returns false
• a report with missing/deleted policy data or a policy without a valid paid group type, also returning false
• an existing team/corporate policy case staying true so we do not break legitimate Mark as paid flows

What alternative solutions did you explore? (Optional)

We could add an extra isPaidGroupPolicy(policy) check in SearchUIUtils and PayActionCell, but that would only patch Search. Since canIOUBePaid() is the shared helper that creates the bad Pay eligibility, fixing it there keeps Search, bulk actions, and report-level payment UI consistent.

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Eep! 4 days overdue now. Issues have feelings too...