[$250] Expense routing to incorrect approver in New Expensify + inconsistent report state vs Classic

[m-natarajan]

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:
Reproducible in staging?: Needs reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @rairibeiro
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. User A is configured to submit expenses to Approver B in the workflow
2. User A submits an expense report in New Expensify
3. The report is automatically routed to Approver C, without showing any option to select a different approver
4. When opening the same report in Expensify Classic:
   The report appears as “Outstanding”, waiting for second approver approval
5. There is also an “Add Expenses” button visible

Expected Result:

The report should route to the approver configured in the workflow (Approver B).
Once submitted and pending approval:
The report should not allow adding expenses (if submission locks the report per workflow).
Report state should be consistent between New Expensify and Classic.

Actual Result:

The report routes to Approver C instead of the configured approver.
No option is presented to select or override approver.
In Classic:
Report shows as “Outstanding” (awaiting second approval).
“Add Expenses” button is still available despite submission.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots and video for the issue are in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @parasharrajat

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024874023934036656
• Upwork Job ID: 2024874023934036656
• Last Price Increase: 2026-03-09

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[melvin-bot]

Triggered auto assignment to @garrettmknight (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.

[MelvinBot]

Proposal

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

When a user submits an expense report in New Expensify, the report is routed to the wrong approver (Approver C instead of the configured Approver B). Additionally, the report state is inconsistent between New Expensify and Classic — Classic shows the report as "Outstanding" waiting for a second approver, and the "Add Expenses" button remains visible.

What is the root cause of that problem?

The approval routing in New Expensify has multiple code paths that can diverge, combined with a dependency on potentially stale local (Onyx) data for the policy.employeeList submitsTo field. There are several mechanisms that can cause the wrong approver to be selected:

Primary mechanism — Dual code paths for approver computation:

When submitReport() is called (src/libs/actions/IOU/index.ts:11465-11466), it computes the optimistic managerID using getApprovalChain(policy, expenseReport).at(0), but sends getSubmitToAccountID(policy, expenseReport) as the managerAccountID API parameter (line 11672). These two functions use different logic:

• getApprovalChain() (src/libs/ReportUtils.ts:12348-12388) prepends category/tag rule approvers before the submitsTo → forwardsTo chain
• getSubmitToAccountID() (src/libs/PolicyUtils.ts:1035-1047) only checks the first rule approver, then falls back to getManagerAccountID()

Contributing mechanisms:

1. Stale submitsTo data: getManagerAccountID() (PolicyUtils.ts:1014-1030) reads employee.submitsTo from the local Onyx copy of policy.employeeList. When workflows are updated via Onyx MERGE (Workflow.ts:57-65), only changed employees are updated — stale submitsTo values can persist for unchanged employees.

2. Default approver fallback chain: When submitsTo is undefined, the code falls back to policy.approver, and if that's empty, to policy.owner (PolicyUtils.ts:983-986). This can silently route to the policy owner instead of the configured approver.

3. Over-limit forwarding: getForwardsToAccount() (PolicyUtils.ts:1058-1073) routes to overLimitForwardsTo when the report total exceeds approvalLimit, silently changing the approval target.

4. Approval mode transition residue: When toggling to OPTIONAL mode, setWorkspaceApprovalMode() (Policy.ts:835-853) resets all submitsTo fields to policy.owner rather than the configured approver.

The Classic inconsistency is explained by isAwaitingFirstLevelApproval() (ReportUtils.ts:2034-2044), which compares getSubmitToAccountID() with report.managerID. When the backend sets a different managerID than what the client computes, this check returns incorrect results, which directly controls the "Add Expenses" button visibility via canAddOrDeleteTransactions() (ReportUtils.ts:2829-2831).

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

Note: This issue is currently marked "Needs Reproduction." Given the multiple possible root causes identified above, reproduction with specific data (policyID, the policy's employeeList contents, approvalMode, category/tag rules, and report total) is critical before determining the right fix. Different root causes require different fixes.

Once reproduced, the fix should address whichever mechanism is confirmed:

1. If stale submitsTo / fallback issue: Ensure getManagerAccountID() validates the submitsTo email against the current approval workflow rather than blindly trusting potentially stale Onyx data.

2. If dual code path divergence: Unify the approver computation so that submitReport() uses the same logic for both the optimistic managerID and the API managerAccountID parameter.

3. If category/tag rule approvers: Ensure getApprovalChain() and getSubmitToAccountID() produce consistent first-approver results when rule approvers are present.

Multiple annotations in the code reference Expensify/Expensify#507850 as a known issue with how getPolicy() data is fetched for approval chain computation, suggesting this may be part of a broader data freshness problem.

What alternative solutions did you explore? (Optional)

The alternative is that this is primarily a backend issue — the backend's approval routing may differ from what the client computes, especially for DEW (DYNAMIC_EXTERNAL) approval mode policies where NE explicitly skips optimistic updates (IOU/index.ts:11497-11509). If the affected policy uses DEW, the fix would need to be in the backend routing logic rather than the App client code.

Detailed Investigation

Evidence Chain

Submission flow:

1. User clicks Submit → submitReport() in IOU/index.ts:11407
2. Optimistic managerID computed from getApprovalChain(policy, expenseReport).at(0) (line 11465-11466)
3. getApprovalChain() in ReportUtils.ts:12348 builds: rule approvers (category/tag) first → then submitsTo → forwardsTo chain
4. API receives managerAccountID = getSubmitToAccountID() (line 11672) — a different code path
5. Report set to stateNum=1/statusNum=1 (Outstanding/Processing)

Approver resolution:

• getManagerAccountID() (PolicyUtils.ts:1014-1030): BASIC mode → default approver; ADVANCED mode → employee.submitsTo ?? defaultApprover
• getDefaultApprover() (PolicyUtils.ts:983-986): policy.approver || policy.owner || ''
• getForwardsToAccount() (PolicyUtils.ts:1058-1073): overLimitForwardsTo if report total > approvalLimit

Classic inconsistency:

• isAwaitingFirstLevelApproval() (ReportUtils.ts:2034-2044): compares getSubmitToAccountID() with report.managerID
• canAddOrDeleteTransactions() (ReportUtils.ts:2829-2831): gates "Add Expenses" button on isAwaitingFirstLevelApproval()
• isApproveAction() (ReportPrimaryActionUtils.ts:139-168): shows Approve button only when managerID === currentUserAccountID

Relevant Code

• src/libs/actions/IOU/index.ts:11407-11672 — submitReport function with dual approver computation
• src/libs/ReportUtils.ts:12348-12388 — getApprovalChain builds full chain with rule approvers
• src/libs/PolicyUtils.ts:975-1073 — getApprovalWorkflow, getManagerAccountID, getSubmitToAccountID, getForwardsToAccount
• src/libs/actions/Workflow.ts:57-65 — Onyx MERGE for employeeList updates
• src/libs/actions/Policy/Policy.ts:819-966 — setWorkspaceApprovalMode with submitsTo reset
• src/libs/ReportUtils.ts:2034-2044 — isAwaitingFirstLevelApproval comparison
• src/libs/ReportPrimaryActionUtils.ts:139-168 — isApproveAction managerID check

Open Questions

• What is the approvalMode for the affected policy? (BASIC, ADVANCED, or DYNAMIC_EXTERNAL?)
• Does the policy have category or tag approval rules configured?
• Has the user recently changed approval workflows or toggled approval modes?
• What is the report total relative to any configured approvalLimit?
• Is the policy.employeeList in the user's Onyx store consistent with the backend?

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[justin-oleary]

Proposal

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

When a user submits an expense report, it routes to the wrong approver. Additionally, New Expensify and Classic show inconsistent report state — Classic shows the report as Outstanding with the Add Expenses button visible while New Expensify shows a different state.

What is the root cause of that problem?

Both symptoms share the same root cause: submitReport() in IOU/index.ts uses two different functions to compute the approver.

At line 11465-11466, the optimistic managerID written to the local report is derived from getApprovalChain(policy, expenseReport).at(0). But at line 11672, the managerAccountID sent to the API is getSubmitToAccountID(policy, expenseReport). These two functions use different logic: getApprovalChain() prepends category/tag rule approvers before the submitsTo chain, while getSubmitToAccountID() goes through getManagerAccountID() which only checks submitsTo directly. When a policy has rule-based approvers configured, the two diverge — the client shows one approver optimistically while routing to another.

The Classic inconsistency is a direct symptom of the same divergence. isAwaitingFirstLevelApproval() in ReportUtils.ts:2034-2044 compares getSubmitToAccountID() against report.managerID. When the backend sets managerID from getSubmitToAccountID() but the client wrote a different value optimistically via getApprovalChain(), that comparison produces the wrong result — which controls the Add Expenses button via canAddOrDeleteTransactions() and the Approve button via isApproveAction().

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

In submitReport() at IOU/index.ts:11465-11466, replace the optimistic managerID computation with getSubmitToAccountID(policy, expenseReport) to match the value sent to the API on line 11672. This unifies the two code paths so the client's optimistic state is consistent with what the backend receives and sets.

This single change fixes both the routing display and the Classic state inconsistency, since isAwaitingFirstLevelApproval() will then compare two values computed by the same function.

What alternative solutions did you explore? (Optional)

An alternative is to change getSubmitToAccountID() to also factor in category/tag rule approvers (making it consistent with getApprovalChain()). But that risks changing API behavior and is a wider blast radius. Fixing the optimistic update to match the already-correct API value is the narrower, safer change.