Expense - Pay button is not shown in More button when Export primary button is present

[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.29-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92787
Email or phone of affected tester (no customers): jsodijsodjnosdjsiodnj2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Workspace is connected to Sage Intacct.
• Invite User B as workspace admin.
• Invite User C as member.
• Disable Approvals in Workflows.

1. Go to staging.new.expensify.com
2. [User C] Create an expense in workspace chat and click Submit.
3. [User B] Open User C's report.
4. [User B] Wait until Export primary button appears.
5. [User B] Click More.
   → Pay button is missing.
6. [User B] Go to Spend > Reports.
   → Pay button is shown.

Expected Result:

In Step 5, Pay button should be shown in More button when Export primary button is present.

Actual Result:

In Step 5, Pay button is not shown in More button when Export primary button is present.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7202963

Issue Owner

Current Issue Owner: @dmkt9

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

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92787

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

Confidence: Medium-High (code-evidenced). The didExportFail premise is inferred from "Export primary button appears" — see the note at the end.

What is the root cause of that problem?

PR #92787 let a non‑payer workspace admin pay reports on manual‑reimbursement workspaces, but rolled that authorization out inconsistently across the three surfaces that decide whether to show a Pay button. In the reporter's scenario the report is submitted with approvals off, is finished, and its export to Sage Intacct has errored — so the Export action is primary (didExportFail === true). For User B (an admin who is not the designated payer, so isPayer returns false):

• Spend > Reports uses canIOUBePaid. Its expense‑report return has no export‑failure guard, so it returns true → Pay is shown. ✅
• Report header "More" is built by getSecondaryReportActions, which calls isPrimaryPayAction({… isSecondaryAction: true}) without passing canNonPayerAdminPay: true (the primary path does pass it). So canPayReport collapses to just isReportPayer (= false for a non‑payer admin) → Pay is omitted from More. ❌

This is the asymmetry in the report: Pay in Spend > Reports, no Pay in More.

The header primary action is also blocked from becoming Pay because isPrimaryPayAction returns isSecondaryAction ?? !didExportFail → false when the export failed, so Export wins the primary slot. canIOUBePaid never applies that same !didExportFail rule, hence the two disagree.

Investigation details & evidence

• isPayer manual branch now treats only the designated reimburser (owner fallback) as payer, so a non-payer admin gets isReportPayer = false: ReportUtils.ts:2839-2866.
• The non-payer-admin branch (canNonPayerAdminPay && reimbursementChoice === MANUAL && canMemberWrite(…WORKFLOWS_PAYMENTS)) lives in ReportPrimaryActionUtils.ts:227-254. All three surfaces use canMemberWrite(…WORKFLOWS_PAYMENTS), which for a full admin equals isPolicyAdmin — so that check is not the divergence.
• Report-preview path ReportPreviewActionUtils.ts:130-156 matches the header (also returns !didExportFail), not the search path.
• Alternatives ruled out: payments are enabled for MANUAL, and isReportFinished is satisfied identically (approvals-off submitted counts as finished) in all three functions. The only distinguishing factors are (1) the didExportFail guard present in the header paths but absent from canIOUBePaid, and (2) the missing canNonPayerAdminPay in the secondary path.

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

Make the three surfaces agree. Two independent fixes:

1. Pass canNonPayerAdminPay: true in the secondary PAY block in getSecondaryReportActions (ReportSecondaryActionUtils.ts:956-968), so a non‑payer manual admin can see Pay in "More", matching the primary path. This alone is a clear bug.

2. Decide and apply one consistent rule for "can pay while an export is failing" across canIOUBePaid, canPay (preview), and isPrimaryPayAction. Either add a !didExportFail guard to canIOUBePaid (so Spend > Reports stops offering Pay during a failed export), or relax the !didExportFail return in the header/preview paths (so Pay stays available there). The product intent should drive which way — but all surfaces must match.

What alternative solutions did you explore? (Optional)

Because this is a deploy blocker attributed to a single PR, reverting #92787 is the safest immediate option if a consistent forward fix can't be landed quickly.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95626) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

Note to confirm the premise: This analysis assumes the report is in the "export errored" state (didExportFail === true), which is the only state consistent with the Export primary button being shown for a connected integration. Confirming from the report's export report-actions (an export-error action present, no successful export action) would lock this in; if the report were actually already exported, the analysis would differ.