Bulk “Mark as Paid” action fails when selected reports include non-reimbursable expenses

[m-natarajan]

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

---

Version Number: v9.4.44-6
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to the Reports page.
2. Select multiple reports.
3. Ensure that some of the selected reports contain only non-reimbursable expenses.
4. Select the bulk Mark as Paid action.
5. Attempt to confirm the action.

Expected Result:

All selected reports should be marked as Paid, including reports that contain only non-reimbursable expenses.
The system should allow the Paid status to be used as a report-completion status without requiring the report to contain a reimbursable balance.

Actual Result:

The bulk Mark as Paid action does not complete successfully, and the selected reports remain unchanged.
The issue appears to occur when the bulk selection includes reports containing only non-reimbursable expenses.

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

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082468187653521924
• Upwork Job ID: 2082468187653521924
• Last Price Increase: 2026-07-29

[MelvinBot]

Proposal

ℹ️ Confidence: Medium. The code inconsistency below is confirmed from source, but the issue is marked "Unable to reproduce" with no logs, so I could not confirm this is the exact path the reporter hit. Treat this as a strong lead to verify, not a settled conclusion.

What is the root cause of that problem?

A report that contains only non-reimbursable expenses has a reimbursable balance of 0, so it is only ever considered payable through the "pay elsewhere" (Mark as paid) branch of canIOUBePaid. That branch depends on hasOnlyNonReimbursableTransactions(reportID, transactions) returning true — which it only does when the report's transactions are actually passed in.

The two places that decide the bulk "Mark as Paid" flow disagree on whether they pass those transactions:

• When deciding whether to show the option, getSections passes the snapshot transactions (allReportTransactions) into canIOUBePaid. So a non-reimbursable-only report is correctly recognized as pay-elsewhere-eligible and the bulk Pay/Mark-as-Paid option appears.
• When deciding how to pay (which sub-option, and whether to actually mark-as-paid), the onlyShowPayElsewhere memo in useSearchBulkActions calls canIOUBePaid with transactions = undefined.

With undefined, hasOnlyNonReimbursableTransactions falls back to reading transactions from live Onyx via getReportTransactions. On the Search/Reports page the report's transactions can live only in the search snapshot, so this returns an empty list → false. The result is that the "mark as paid" eligibility that was granted when the option was shown is silently lost when the action is executed, so the affected reports never get marked as Paid — matching "the action does not complete and the selected reports remain unchanged."

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

Make useSearchBulkActions pass the same snapshot transactions to canIOUBePaid that getSections already uses, instead of undefined, so the "which sub-option / execute" logic sees the report as non-reimbursable-only just like the "should we show the option" logic does. The transactions for each selected report are available in currentSearchResults.data and can be resolved per reportID inside the onlyShowPayElsewhere memo before the two canIOUBePaid calls.

Supporting evidence & alternatives considered

• canIOUBePaid non-reimbursable branch: ReportWorkflow.ts:251, ReportWorkflow.ts:263-272 — for reimbursableSpend === 0, only isOnlyNonReimbursablePayElsewhere can make it payable, and that requires onlyShowPayElsewhere === true and the transactions argument.
• Correct call (with snapshot transactions): SearchUIUtils.ts:2440-2452.
• Inconsistent call (with undefined): useSearchBulkActions.ts:505-546.
• getReimbursableTotal returns 0 for non-reimbursable-only reports (ReportUtils.ts:4598-4603), and the request builder payMoneyRequest has no zero-amount guard — so the defect is in the eligibility/routing layer, not the request builder.

Alternative explanation considered (not App-side): even if the request fires, it would send amount: 0 to PayMoneyRequest. Whether the backend then marks the report Paid or no-ops on a zero amount is an Auth/Web-Expensify question not visible in this repo. If reproduction shows the request is sent for these reports, the root cause is backend and should be escalated to an internal engineer rather than fixed here.

To verify before implementing: reproduce on a dev/web build with a mixed selection (at least one report containing only non-reimbursable expenses) and confirm whether (a) onlyShowPayElsewhere evaluates to false for the non-reimbursable-only report, and (b) the bulk pay loop bails without ever calling payMoneyRequest for it.

Possibly related (not duplicates): #93699 (bulk Pay/Mark-as-Paid options missing for mixed selections — same onlyShowPayElsewhere memo also handles the multi-currency case) and #95832 (bulk pay only offering Mark as Paid). Worth a glance for overlap.

---

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

[melvin-bot]

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

[cretadn22]

I can't reproduce

Screen.Recording.2026-08-02.at.12.20.17.mov