[CFI] [$250] Allow any workspace admin to pay reports

[joekaufmanexpensify]

Coming from this Slack thread, @sakluger flagged a classic/NewDot parity gap regarding payments.

Details

• When no bank account is connected to a workspace, any workspace already sees the option to pay/mark as paid in NewDot. This part works correctly today and needs no changes.
• The gap: when a bank account is connected to a workspace, NewDot only shows the pay button to the admin set as the workspace payer. Classic shows it to any workspace admin.
• Proposal: any workspace admin should see the option to pay (via any VBA they have access to) or manually mark as paid, regardless of whether a bank account is connected to the workspace.
  • In the event the workspace doesn't have a VBA, they should be prompted to add one in situ when they try to pay via business account (the existing payment button logic).
• An admin adding/paying with a bank account that's not the current workspace bank account shouldn't change the workspace bank account, same as now.
• We should not actively prompt admins that aren't the workspace payer to pay via badges/GBRs. That stays as-is (per https://github.com/Expensify/Expensify/issues/637864).
• One note: an admin that isn't the workspace payer who tries to pay a report via ACH in Classic sees an error, despite being able to mark as paid. I don't think we should go this direction in NewDot, since we already allow the admin set as the workspace payer to select the bank account to use at the time of payment in both NewDot and Classic. It feels more consistent to also allow the non-payer admin to select the bank account they want to use or mark as paid. Curious if anyone disagrees?
• I don't think this issue should require any backend changes. Let me know if anyone feels differently.
• This issue is only about who can see and use the pay button. It shouldn't change which options appear or how it behaves for a given report (e.g., non-reimbursable-only reports showing "Mark as Paid" only in the report detail view, not the report preview or the Spend page).

Non-payer workspace admin view when workspace has bank account - NewDot

Non-payer workspace admin view when workspace has bank account - OldDot

Non-payer workspace admin view when workspace has no bank account - NewDot

Non-payer workspace admin view when workspace has no bank account - OldDot

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075307768398315166
• Upwork Job ID: 2075307768398315166
• Last Price Increase: 2026-07-09

Issue Owner

Current Issue Owner: @lorretheboy

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dannymcclain (NewFeature)

[joekaufmanexpensify]

@dannymcclain I don't think we need any mocks here. We're just showing the existing pay button to a broader group of admins. Let me know if you feel differently. Going ahead with soliciting proposals for now. 👍

[joekaufmanexpensify]

@MelvinBot please submit a proposal for this issue following Expensify's normal proposal guidelines.

[MelvinBot]

Proposal

What is the root cause of that problem?

The pay button is gated on being the single designated workspace payer, not on being an admin.

In isPayer, once a workspace has a designated reimburser — which is exactly the case when a bank account is connected (policy.achAccount.reimburser) — only that reimburser is treated as a payer. Other admins qualify only if they are a sharee of that specific VBA (auto reimbursement) or not at all (manual):

The designated-payer gate

• reimburserEmail = policy.reimburser ?? policy.achAccount?.reimburser ?? … — ReportUtils.ts:2853
• Auto (REIMBURSEMENT_YES): isReimburser || (isAdmin && hasAccessToBankAccount) — ReportUtils.ts:2864-2869
• Manual (REIMBURSEMENT_MANUAL): isReimburser only — ReportUtils.ts:2873

There is already a "any admin / Payments Admin can pay" fallback layered on top of isPayer, but it is scoped to REIMBURSEMENT_MANUAL only, so it doesn't cover a bank-connected workspace that reimburses automatically:

The fallback is manual-only in all three pay-button surfaces

• canIOUBePaid — isReportPayer || (reimbursementChoice === MANUAL && canMemberWrite(…, WORKFLOWS_PAYMENTS))
• ReportPreviewActionUtils.ts:130-132 — same MANUAL-only condition
• ReportPrimaryActionUtils.ts:228-232 — same, additionally behind a canNonPayerAdminPay flag
• Search/Reports page uses isPolicyPayer, which also returns true only when currentUserLogin === reimburserEmail

Net effect: on a workspace with a bank account connected + automatic reimbursement, a non-payer workspace admin or Payments Admin sees no pay button — the OldDot/NewDot parity gap.

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

Separate "who can pay" (button visibility — should be broad) from "who is the designated payer" (prompting — stays narrow).

1. Broaden the non-payer-admin fallback in the three pay-button surfaces (canIOUBePaid, ReportPreviewActionUtils, ReportPrimaryActionUtils) so it applies whenever payments are enabled, not just manual reimbursement — i.e. gate on arePaymentsEnabled(policy) instead of reimbursementChoice === REIMBURSEMENT_MANUAL. Any workspace admin or Payments Admin (canMemberWrite(policy, login, WORKFLOWS_PAYMENTS)) then sees the pay button regardless of being the designated payer or a VBA sharee.
2. Mirror the same broadening in isPolicyPayer so the Search/Reports-page pay button matches.
3. Leave isPayer itself unchanged. It also feeds the PAY badge (getBadgeFromIOUReport) and next-step/GBR messaging (NextStepUtils). Keeping it gated on the designated payer ensures non-payer admins still see the button but are not actively prompted via badges/GBRs — matching the issue requirement and Expensify/Expensify#637864.

No backend changes needed. A non-payer admin without a VBA who taps "pay via business account" hits the existing add-bank-account flow in situ; "mark as paid" already works via the pay-elsewhere path.

What alternative solutions did you explore? (Optional)

Broadening isPayer directly (one edit) — rejected, because it is shared by the badge/GBR/next-step logic, so it would start actively prompting non-payer admins to pay, which the issue explicitly rules out.

---

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

[joekaufmanexpensify]

Opening up to other proposals now so C+ can decide between Melvin and others.

[aswin-s]

Proposal

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

On NewDot Web, when a workspace has a connected business bank account, the pay/mark-as-paid button is only shown to the admin designated as the workspace payer (reimburser). Classic shows it to any workspace admin — and now, with the newly added Payments Admin role (PR #94018), any Payments Admin should also see it. Expected: any workspace admin or payments admin can see and use the pay button (choosing a VBA they have access to, being prompted to add one, or marking as paid), regardless of whether the workspace has a bank account connected.

What is the root cause of that problem?

isPayer in src/libs/ReportUtils.ts:2820 defines isAdmin as policy?.role === CONST.POLICY.ROLE.ADMIN (line 2835), which excludes the new PAYMENTS_ADMIN role added in PR #94018. Additionally, in the auto-reimbursement branch (lines 2864–2869), the function returns isReimburser || (isAdmin && hasAccessToBankAccount) — so a non-reimburser workspace/payments admin who isn't on the connected bank account's sharees list returns false, hiding the pay button. Classic instead lets any admin see the button and pick a VBA (or be prompted to add one) at pay time.

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

1. src/libs/ReportUtils.ts:2835 — broaden isAdmin to also treat CONST.POLICY.ROLE.PAYMENTS_ADMIN as an admin for payment authorization (e.g. [ROLE.ADMIN, ROLE.PAYMENTS_ADMIN].includes(policy?.role) when policy type isn't PERSONAL).
2. src/libs/ReportUtils.ts:2864-2869 (auto-reimbursement branch) — allow any workspace/payments admin to see the button even without bank-account sharee access; drop the hasAccessToBankAccount gate here so the return becomes isReimburser || isAdmin. The in-situ VBA prompt / bank-picker at pay time handles the "no access to current VBA" case per the issue.
3. src/libs/ReportUtils.ts:2872-2873 (manual-reimbursement branch) — same relaxation: return true for isAdmin in addition to isReimburser, so any admin can mark-as-paid or pay through their accessible VBA.
4. Verify downstream consumers (PayPrimaryAction.tsx, PayActionButton.tsx, PayActionCell.tsx, MoneyReportHeaderSecondaryActions.tsx, MoneyReportHeaderSelectionDropdown.tsx, SearchUIUtils.ts, useSearchBulkActions.ts, useSelectionModeReportActions.ts, AnimatedSettlementButton.tsx, MoneyReportHeaderModals.tsx, actions/IOU/ReportWorkflow.ts) pass the current user's policy through isPayer unchanged — no per-call-site changes needed since the gate lives in one function.
5. Keep GBR/badge prompting logic untouched (issue explicitly excludes it) — this change only affects who sees/uses the pay button, matching Classic parity.

What alternative solutions did you explore? (Optional)

[lorretheboy]

Proposal

What is the root cause of that problem?

The pay-button gates already have an escape that lets any admin/payments admin pay when they aren't the designated payer, but it's hard-coded to manual reimbursement only. Connecting a bank account flips the policy's reimbursementChoice to reimburseYes and sets achAccount.reimburser (the workspace payer), which kills both paths at once:

1. isPayer in its auto-reimbursement branch only returns true for the designated reimburser, or an admin who is a sharee of the workspace's exact bank account:

App/src/libs/ReportUtils.ts

Lines 2863 to 2873 in b794ad3

	// 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.
	return isReimburser;

2. The non-payer-admin escape in canIOUBePaid requires reimbursementChoice === REIMBURSEMENT_MANUAL, which is no longer true once a bank account is connected:

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

Lines 223 to 226 in b794ad3

	const isReportPayer = isPayerReportUtils(currentUserAccountID, currentUserLogin, iouReport, bankAccountList, policy, onlyShowPayElsewhere);
	const canPay =
	isReportPayer ||
	(policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL && canMemberWrite(policy, currentUserLogin, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));

The same manual-only escape is duplicated in the primary-action and report-preview gates:

App/src/libs/ReportPrimaryActionUtils.ts

Lines 227 to 232 in b794ad3

	const isReportPayer = isPayer(currentUserAccountID, currentUserLogin, report, bankAccountList, policy, false);
	const canPayReport =
	isReportPayer ||
	(canNonPayerAdminPay &&
	policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL &&
	canMemberWrite(policy, currentUserLogin, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));

App/src/libs/ReportPreviewActionUtils.ts

Lines 129 to 132 in b794ad3

	const isReportPayer = isPayer(currentUserAccountID, currentUserLogin, report, bankAccountList, policy, false);
	const canPayReport =
	isReportPayer ||
	(policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL && canMemberWrite(policy, currentUserLogin, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS));

So: bank account connected → choice becomes reimburseYes → the manual-only escape stops applying → only isPayer gates the button → only the workspace payer (or a bank-account sharee) sees Pay. Classic shows it to any workspace/payments admin. Note this isn't a regression from PR #94018 — that PR only added the Payments Admin role/UI; the manual-only restriction predates it, and payments admins already satisfy the escape's canMemberWrite(..., WORKFLOWS_PAYMENTS) check via their permission bundle.

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

Broaden the non-payer-admin escape so it applies whenever reimbursement is enabled (manual or direct), instead of manual only. Since the identical expression is duplicated in three places, extract it into a shared helper in PolicyUtils (next to isPolicyPayer), roughly:

function canAdminPayReport(policy, currentUserLogin) {
    const isReimbursementEnabled =
        policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL ||
        policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES;
    return isReimbursementEnabled && canMemberWrite(policy, currentUserLogin, CONST.POLICY.POLICY_FEATURE.WORKFLOWS_PAYMENTS);
}

and use it in the three gates above (canIOUBePaid, isPrimaryPayAction, and the report-preview canPay) in place of the inline manual-only check. canMemberWrite(..., WORKFLOWS_PAYMENTS) is write-all for admins and explicitly granted to payments admins, so both roles are covered.

Deliberately do not change isPayer (or isPolicyPayer). Those still drive the LHN Pay badge, GBR (hasOutstandingChildRequest), next-step copy, and Search pay suggestions — e.g. the badge separately requires isReportPayer before calling canIOUBePaid:

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

Lines 303 to 306 in b794ad3

	const isReportPayer = isPayerReportUtils(currentUserAccountID, currentUserLogin, iouReport, undefined, policy, false);
	const canBePaidNow =
	(isInvoiceReportReportUtils(iouReport) || isReportPayer) &&
	canIOUBePaid(iouReport, chatReport, policy, undefined, currentUserLogin, currentUserAccountID, undefined, undefined, undefined, invoiceReceiverPolicy);

so non-payer admins get the button but are not actively prompted via badges/GBRs, as the issue requires. Payment itself needs no changes: the settlement button already lists only bank accounts the user has access to, prompts them to add a VBA (KYC wall) if they have none, and paying from a different VBA doesn't change the workspace bank account.

What alternative solutions did you explore? (Optional)

Making isPayer's auto-reimbursement branch return true for any admin/payments admin (canPayOnPolicy). Rejected because isPayer also feeds badges, GBRs, and next-step messaging, which must stay payer-only per the issue.