[Due for payment 2025-09-30] [Due for payment 2025-09-26] [$250] Expense - Pay option missing when second admin is set as payer

[vincdargento]

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: v9.1.94-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/folder/13176741/test-cases/41237130
Email or phone of affected tester (no customers): Slottwo1 2@gmail.com
Issue reported by: Applause Internal Team
Device used: Redminote 10s android 13
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Go to workspace settings
3. Enable Delay submissions and Make or track payments. Add approvals remains disabled
4. Add a second admin as the payer to the workspace
   5.As the submitter - Create a manual expense
5. As the second admin - Go to the submitter workspace chat
6. Open expense details page

Expected Result:

When the second admin is set as the payer, the Pay option should be displayed.

Actual Result:

When the second admin is set as the payer, the Pay option is not displayed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021958213586176264765
• Upwork Job ID: 1958213586176264765
• Last Price Increase: 2025-08-27

Issue Owner

Current Issue Owner: @abekkala

[melvin-bot]

Triggered auto assignment to @abekkala (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[FitseTLT]

🚨 Edited by proposal-police: This proposal was edited at 2025-09-01 14:39:45 UTC.

Proposal

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

Expense - Pay option missing when second admin is set as payer

What is the root cause of that problem?

When there is a reimburser in a workspace we only allow them to be a payer if they are a manager or the report is approved

App/src/libs/ReportUtils.ts

Line 2424 in 4a5c601

return isReimburser && (isApproved || isManager);

but in this case the manager is the owner and the report is in a closed status.

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

If there is a reimburser in the policy we should allow pay for the reimburser and to align with the BE logic here

App/src/libs/ReportUtils.ts

Lines 2411 to 2431 in 4a5c601

	if (isPaidGroupPolicy(iouReport)) {
	if (policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES) {
	if (!policy?.achAccount?.reimburser) {
	// If there is a manager assigned, only allow payment if the user is both an admin and the manager.
	// Otherwise, if there is no reimburser and no manager, only allow payment if the user is an admin.
	if (iouReport?.managerID) {
	return isAdmin && isManager;
	}
	return isAdmin;
	}
	// If we are the reimburser and the report is approved or we are the manager then we can pay it.
	const isReimburser = session?.email === policy?.achAccount?.reimburser;
	return isReimburser && (isApproved || isManager);
	}
	if (policy?.reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL || onlyShowPayElsewhere) {
	return isAdmin && (isApproved || isManager);
	}
	return false;
	}
	return isAdmin || (isMoneyRequestReport(iouReport) && isManager);

const reimbursementChoice = policy?.reimbursementChoice;
    if (isPaidGroupPolicy(iouReport) && reimbursementChoice) {
        if (reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES) {
            if (!policy?.achAccount?.reimburser) {
                return isAdmin;
            }

            // If we are the reimburser and the report is approved or we are the manager then we can pay it.
            const isReimburser = session?.email === policy?.achAccount?.reimburser;
            return isReimburser;
        }
        if (reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL) {
            return isAdmin;
        }
        return false;
    }
    return isAdmin || isManager;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can add a test for isPayer that it returns true for the reimburser even if they are not a manager.

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @dominictb (External)

[muhammad-ali-abbasi]

---

Proposal

What’s the issue we’re trying to solve?

Expense - Pay option missing when second admin is set as payer

What’s causing the issue?

The core issue is that the system’s UI only checks a narrow, outdated set of fields to determine if a user is a payer. For example, it currently looks for a single policy.owner or payer field. But the backend can support multiple, more dynamic representations of who can pay. Here’s what’s happening:

• The UI checks the workspace’s policy object and only considers the primary owner or a single payer field to decide if someone can pay.
• If a second admin is assigned as a payer, their identity is stored differently in the backend (either as a separate field or as part of an array). The UI isn’t designed to recognize this, so it doesn’t show them as an authorized payer.
• As a result, the Pay button doesn’t appear for the second admin, even though the backend intended for them to be able to pay.

This mismatch between how the backend and the UI define who can pay is causing the problem.

How can we fix this?

Goal: We need to create a single, reliable way to check if a user is authorized to pay, and ensure that check is used consistently across the platform wherever the Pay button appears.

1) Create a unified check for payer authorization

• We’ll add a function in the policy utility library that determines if the current user is authorized to pay, looking at all possible fields the backend could use. It will check:

  • The policy.payerEmail (legacy field)
  • policy.payerUserID or policy.payerUserIds (single or array)
  • A new policy.authorizedPayers or policy.payerIDs array
  • If no payer is explicitly set, it will fall back to policy.ownerEmail or policy.ownerID

• The function should accept the currentUser as an object (e.g., {accountID, login}) and handle both ID and email, so we don’t have to worry about different formats being passed in.

Why this helps: This way, we centralize the logic for determining who can pay, making it easier to maintain, handle future backend changes, and avoid bugs from missing data checks.

2) Use the unified check everywhere the Pay button is shown

• We’ll update the UI components where the Pay button appears to use this new helper instead of checking locally for a payer. The components we need to update include:

  • MoneyReportView.tsx — where the Pay CTA is displayed in the money actions section
  • ReportDetailsPage.tsx — the report details page
  • Any other components, like chat previews or action items, that show the Pay button

• These components should always pull the most up-to-date policy from Onyx (or its existing prop) and the current user from the app’s session/store, and then call isUserAuthorizedPayer(policy, currentUser) every time they render.

Why this helps: It ensures that no matter where the Pay button appears, it will be governed by the same logic, so if a user is set as the payer, the button will appear for them consistently.

3) Ensure the check is reactive and doesn’t rely on caching

• The payer eligibility check should run every time the UI renders, and only be cached when the policy or currentUser changes. This ensures that the Pay button will update immediately when the backend sends a new policy update.

4) Document the new helper and include migration notes

• We’ll add comments in the new helper function to describe the fields it checks and why. This will make it easier for future developers to understand and update the logic if the backend data structure changes. If the backend eventually standardizes on a single field for the payer, we’ll only need to update it in one place.

---