[Due for payment 2026-05-12] [Due for payment 2026-05-11] Expense - Admin receives error when submit expense created by employee for previous approver

[jponikarchuk]

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.3.65-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: https://test-management.browserstack.com/projects/2219752/folder/13176703/test-cases/41236818
Email or phone of affected tester (no customers): fischer9966+043026adm@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacOS 26.4.1 / Safari, Chrome. iPhone 17 Pro / 26.4.2. Google Pixel 5 / Android 14
App Component: Money Requests

Action Performed:

1. Create Admin account with Gmail
2. Create Collect workspace, set Workflows to enabled
3. Invite Employee and Approver with Gmail accounts to this workspace
4. Enable Workflows > Delay submissions and set it to Manually
5. Enable Approvals in Workflows and set Approver account as Approver
6. Login as the employee and create new expense report. Don't submit it.
7. Login as Admin and change approver to Admin
8. Go to Workspace chat and submit report created by employee

Expected Result:

An admin can successfully submit a report created by an employee for the previous approver.

Actual Result:

If Admin changes the approver to themselves after an employee has created a report then admin get unexpected error after submit this report on behalf an employee.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #88708 - "Fix submit report approver selection from stale policy data" by @lakchote (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #88708 introduced a regression in the approver selection logic when submitting a report. The fix can be cleanly reverted.

Assigned: @lakchote (PR author), @Krishna2323 (approving reviewer), @mollfpr (approving reviewer)
Labels: DeployBlockerCash kept (Frontend bug — App PR caused the regression). DeployBlocker not present.

📋 Detailed Analysis

Evidence

PR #88708 introduced getSubmitReportManagerAccountID() in src/libs/PolicyUtils.ts and wired it into submitReport() in src/libs/actions/IOU/ReportWorkflow.ts. The function contains the following logic:

if (existingManagerID > CONST.DEFAULT_NUMBER_ID && existingManagerID !== ownerAccountID) {
    // Existing reports may already have a server-computed or manually changed approver.
    return existingManagerID;
}

This logic always preserves the existing report.managerID as long as it differs from the report owner. The intent was to prevent stale policy cache from overwriting a correctly-set approver. However, it also prevents the newly-changed workspace approver from being applied at submission time.

The bug reproduces on staging only (not production), which confirms it was introduced by a PR in the current staging deploy.

Verification

The affected files are src/libs/PolicyUtils.ts and src/libs/actions/IOU/ReportWorkflow.ts. PR #88708 modifies both of these files and specifically changes how managerAccountID is computed in submitReport().

Before PR #88708:

const submitToAccountID = getSubmitToAccountID(policy, expenseReport);
const managerID =
  submitToAccountID > 0 ? submitToAccountID : expenseReport.managerID;

After PR #88708 (via getSubmitReportManagerAccountID):

if (
  existingManagerID > CONST.DEFAULT_NUMBER_ID &&
  existingManagerID !== ownerAccountID
) {
  return existingManagerID; // always preserves stale report.managerID
}

• Affected files confirmed: src/libs/PolicyUtils.ts, src/libs/actions/IOU/ReportWorkflow.ts
• PR [Payment due @Krishna2323] Fix submit report approver selection from stale policy data #88708 modifies both files
• PR was merged on 2026-04-28, before version 9.3.65-0 entered staging

Root Cause

When the workspace admin changes the approver to themselves after the employee has already created a report:

1. The employee's existing expense report has managerID = the old approver's accountID (set when the report was created)
2. The admin changes the workspace approver to their own account
3. When the admin submits the report on behalf of the employee, getSubmitReportManagerAccountID is called
4. Because existingManagerID (old approver) is nonzero and differs from ownerAccountID (employee), the function returns the old approver's accountID unchanged
5. The API call sends the old approver's accountID as managerAccountID, which is no longer the configured approver
6. The backend rejects the submission with an error

The PR's goal was correct (preserve a valid server-assigned manager), but the check does not account for the case where the workspace admin has explicitly changed the approver after the report was created. The report's managerID becomes stale relative to the current policy configuration, and the new logic locks in that stale value.

[MelvinBot]

Proposal

What is the root cause of that problem?

When the employee creates an expense report, report.managerID is set to the current approver from the policy. When the admin later changes the approver, the policy's employeeList[employee].submitsTo is updated, but the existing report's managerID is not.

At submission time, getSubmitReportManagerAccountID checks if the report already has a managerID that differs from the owner — if so, it returns the stale value without recomputing from the current policy:

if (existingManagerID > CONST.DEFAULT_NUMBER_ID && existingManagerID !== ownerAccountID) {
    return existingManagerID; // Returns the OLD approver
}

The stale managerAccountID (old approver who is no longer in the approval chain) is sent to the SubmitReport API, the backend rejects it, and the user sees "Unexpected error. Please try again later." via the generic iou.error.other failure handler.

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

In getSubmitReportManagerAccountID, always prefer the current policy's approver over the stale report.managerID for open (unsubmitted) reports. The function should call getSubmitToAccountID(policy, expenseReport) first and only fall back to the existing managerID if the policy lookup fails or returns no result.

This ensures that when an admin changes the approval workflow, any unsubmitted report will pick up the correct current approver at submission time, rather than using the stale value baked in at report creation.

What alternative solutions did you explore? (Optional)

1. Update all open reports' managerID when the approval workflow changes (in Workflow.ts) — this would be more invasive and harder to get right for all edge cases.
2. Add a specific error message when the backend rejects a stale approver — this would only improve the UX but not fix the underlying problem.

Investigation details

Data flow:

1. Employee creates report → managerID = old approver (set via getSubmitToAccountID in buildOptimisticExpenseReport)
2. Admin changes approval workflow → policy.employeeList[employee].submitsTo updated to admin's email; report.managerID untouched
3. Admin submits report → getSubmitReportManagerAccountID sees existingManagerID (old approver) != ownerAccountID (employee) → returns stale old approver
4. SubmitReport API called with managerAccountID = old approver (no longer valid)
5. Backend rejects → generic "Unexpected error" shown

Key files:

• PolicyUtils.ts:1247-1258 — getSubmitReportManagerAccountID (root cause)
• ReportWorkflow.ts:1302 — submitReport uses the stale value
• ReportUtils.ts:6867-6871 — where managerID is initially set at report creation

Possibly related issue: Expensify/App#89012 — different symptom (submitter sees editable fields on a forwarded report after workflow change) but shares the same underlying theme of stale managerID vs. live policy state.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[Krishna2323]

The getSubmitReportManagerAccountID function always preserves report.managerID when it's valid and non-self, even when the admin has since changed the approver. The stale managerID (old approver) gets sent to the API, which rejects it.

Regarding MelvinBot's proposal — simply reversing the priority (always prefer policy-computed over existing) would re-introduce the original bug that #88708 was fixing: when employeeList is stale/empty, the policy computation falls back to the wrong default approver and overwrites a correct server-set report.managerID.

A better fix: check whether policy.employeeList actually has data for the submitter before deciding which source to trust. If it does, trust the policy (admin may have changed the workflow). If it doesn't (stale/empty), preserve the existing report.managerID.

@MelvinBot can you investigate more on this?

cc: @lakchote