Expense - Report does not appear for payments admin when payments admin is set as the payer

[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?: N/A - new feature, doesn't exist in prod
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): joinsdjosjnodsjdiosjo1@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:

• Create a Control workspace.
• Invite user as payments admin to the workspace.
• Change Payer to payments admin in workspace settings > Workflows > Payer.

1. Go to staging.new.expensify.com
2. [Owner] Create an expense in workspace chat.
3. [Owner] Open the report.
4. [Owner] Click Submit and Approve.
   → Next step message shows waiting for payments admin to pay expenses.
5. [Payments admin] Look for owner's report.

Expected Result:

Owner's report should appear for payments admin because payments admin is set as the payer.

Actual Result:

Owner's report does not appear for payments admin when payments admin is set as the payer.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7202189_1783451140407.4.mp4

View all open jobs on GitHub

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

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/323cc64246e8d69c8f69a4519b5fb27f1207f613ea791a4785a610edc6e323f2

[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.

[melvin-bot]

📣 @wovumegore! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[MelvinBot]

Issue Analysis

⚠️ Security note: The comment above from wovumegore linking a fix_payer_sync.zip and asking to "run a quick script that forces the state refresh" is not a legitimate fix — Expensify does not fix bugs by having people download and run zipped scripts. This matches a common malware / social-engineering pattern on public deploy-blocker issues. Do not download or run it. It should be reported and hidden.

Root Cause: PR #92787 added an isPayer(...) gate to hasOutstandingChildRequest at ReportUtils.ts:3071, so a report only surfaces (LHN GBR, Home "For you", Spend "Ready to Pay") for the designated payer. But isPayer resolves the payer for a manual/indirect workspace as policy.achAccount?.reimburser ?? policy.owner (ReportUtils.ts:2864, mirrored in isPolicyPayer at PolicyUtils.ts:684). For a manual workspace with no bank account, achAccount.reimburser is absent, so the payer silently falls back to policy.owner. A payments admin who is not the owner therefore fails the equality check → isPayer returns false → the report never appears for them. This is exactly the reported scenario.

Recommended Fix: In manual-reimbursement mode, resolve the payer from the top-level policy.reimburser (the field setWorkspacePayer actually persists — see Policy.ts:1053-1054), not achAccount.reimburser (which is bank-account-scoped and empty for indirect payments). Update both isPayer and isPolicyPayer to read policy.reimburser ?? policy.achAccount?.reimburser and only fall back to policy.owner when neither is set.

Given this is a deploy blocker for a new feature, reverting #92787 is the safest immediate unblock if a verified fix can't land quickly.

Investigation details & evidence chain

Mechanism

1. Owner submits + approves an expense on a manual/indirect (reimburseManual) Control workspace whose Payer is set to a payments admin (≠ owner).
2. For the report to surface for a viewer, hasOutstandingChildRequest(...) must be true — post-PR that now requires isPayer(currentUser, ...) (ReportUtils.ts:3071).
3. isPayer computes reimburserEmail = policy?.achAccount?.reimburser ?? (isManualReimbursement ? policy?.owner : '') (ReportUtils.ts:2864).
4. Manual workspace → no achAccount → reimburserEmail = policy.owner.
5. Payments-admin payer's email ≠ policy.owner → isPayer = false → no GBR / no "For you" / no "Ready to Pay" → report hidden from the actual payer.

Note: the report-preview Pay option is intentionally not gated on being the payer (any manual-mode admin sees it), which is why the workaround of opening the report directly still allows payment — but the report never surfaces on its own.

Alternative considered: If the backend returned achAccount.reimburser as an empty string rather than absent, isPayer would return isAdmin (any admin sees it) and the bug would not reproduce. Since it does reproduce, achAccount.reimburser is undefined for these workspaces — confirming the owner-fallback path.

Open question (backend): Whether the fix is purely frontend depends on what the policy payload delivers to the payments admin's client for a manual/no-bank-account workspace — top-level policy.reimburser vs achAccount.reimburser. If the backend does not persist a payer for manual workspaces at all, a backend change may also be needed. Web-Expensify (SetWorkspacePayer) is not checked out here, so that should be confirmed by an internal engineer.

Confidence: High on the frontend mechanism (verified against merged code); Medium on whether a backend change is additionally required.

---

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

[NikkiWines]

I think that'll fix part of it, but I think it's the new payer admin role that's going to cause more issues. Will push up a PR to fix this