[$175] Hold - Approve modal displays same amount full report and pending expense

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.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 BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/75702454/folder/13176872/41237335/1798269621?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+workspaceapprover2207@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: windows 10/chrome
App Component: Other

Action Performed:

Precondition:
Owner invite approver and employee to the workspace

1. As employee submit two expenses in workspace chat
2. As employee click View button
   3 As employee open one of the expenses and put it on Hold
3. As approver click on Approve button

Expected Result:

Approve modal should display amount for pending expense and total amount for full report

Actual Result:

Approve modal displays total amount for both pending expense and full report

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7269497_1790353272470.Recording__1734.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022103555129237584541
• Upwork Job ID: 2103555129237584541
• Last Price Increase: 2026-09-25

[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/4e847f2a253fb9b17e2fbe16d41937da05e410a7b1c85c855da85848d72bb5e6

[MelvinBot]

Proposal

What is the root cause of that problem?

The Approve options get both amounts from report-level totals that the server sends. They don't use the report's transactions. getNonHeldAndFullAmount reads:

• "Approve only X" from report.unheldTotal
• "Approve Y" from reimbursableTotal + nonReimbursableTotal

The transactions are used for only one thing: to check whether any expense is held.

The employee who places the hold gets updated unheldTotal values right away, from optimistic data in putOnHold. The approver doesn't. The approver does receive the transaction's hold, which is why the "Approve only" option appears. But their copy of the report still has unheldTotal equal to the full total, so both options show the same amount.

Supporting details

• All Approve surfaces use the same function. These are the report preview and header dropdown (ExpenseHeaderApprovalButton.tsx:86) and the Spend > Reports hold modal (ExpenseReportListItem.tsx:276-299).
• The App's math here hasn't changed recently. Clarify Approval Options When Held Expenses Exist And Fix Regressions (merged 2026-09-08) turned the modal into a dropdown, but it kept the same inputs. Use freshly computed report totals from backend instead of potentially stale stored total made the App rely on backend-computed unheld totals. So the stale value most likely comes from the report data the approver receives after the hold. That part needs internal confirmation. I couldn't check production logs in this run.
• The Pay flow has the same exposure. "Pay only" reads unheldReimbursableTotal in the same function.
• The partial-approve amount the App submits also comes from report fields (ReportWorkflow.ts:514-520, PayMoneyRequest.ts:260-262). If those fields are stale, the optimistic amount is wrong too.

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

In getNonHeldAndFullAmount, calculate the held amount from allReportTransactions. Every caller already passes these, and the approver has them.

1. Add up the amounts of held transactions in the report currency. Convert when a transaction's currency differs from the report's.
2. For the pay branch, count only reimbursable held transactions.
3. Set the non-held amount to the full total minus the held amount.
4. Use the same helper for the partial approve and partial pay amounts, so the amount shown matches the amount submitted.
5. Add a unit test. Use a report whose unheldTotal equals total and one held transaction, and check that the non-held amount excludes the held transaction.

Separately, an internal engineer should check whether the backend sends updated unheld totals to other report participants after a hold.

What alternative solutions did you explore? (Optional)

Keep the report fields, but switch to the transaction-based amount only when a held expense exists and unheldTotal equals the total. This change is smaller, but it misses cases where the report fields are only partly stale.

Possibly related: Spend - Approve modal inconsistency when approved form Spend and report. It involves the same approve-with-hold amounts, but a different trigger ($0 held expense).

---

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

---

view run

[melvin-bot]

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

[melvin-bot]

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

[ashusatyarthi-wq]

Proposal

What is the root cause of that problem?

In src/libs/ReportUtils.ts within getNonHeldAndFullAmount:

function getNonHeldAndFullAmount(
    iouReport: OnyxEntry<Report>,
    shouldExcludeNonReimbursables: boolean,
    allReportTransactions: Transaction[],
    convertToDisplayString: CurrencyListActionsContextType['convertToDisplayString'],
): NonHeldAndFullAmount {
    ...
    const reimbursableTotal = getReimbursableTotal(iouReport);
    const unheldReimbursableTotal = getUnheldReimbursableTotal(iouReport);

    let total: number;
    let unheldTotal: number;
    if (shouldExcludeNonReimbursables) {
        total = reimbursableTotal;
        unheldTotal = unheldReimbursableTotal;
    } else {
        total = reimbursableTotal + (iouReport?.nonReimbursableTotal ?? 0);
        unheldTotal = iouReport?.unheldTotal ?? unheldReimbursableTotal + (iouReport?.unheldNonReimbursableTotal ?? 0);
    }

1. When a user puts an expense on hold, the hold status is immediately saved on the transaction object (transaction.comment.hold = true).
2. In ExpenseHeaderApprovalButton.tsx, allReportTransactions is passed into getNonHeldAndFullAmount. hasHeldExpenses(allReportTransactions) detects the hold and causes the dropdown menu to appear.
3. However, getNonHeldAndFullAmount computes unheldTotal strictly from iouReport?.unheldTotal or iouReport?.unheldReimbursableTotal. Because iouReport stored totals in Onyx are not yet updated with the new unheld split until the report re-computes on the backend, iouReport?.unheldTotal remains undefined or equal to the full total.
4. As a result, unheldTotal defaults to the full report total, causing both dropdown options ("Approve only <amount>" and "Approve <amount>") in getApprovalDropdownOptions to display the identical full report amount.

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

In src/libs/ReportUtils.ts inside getNonHeldAndFullAmount:
When allReportTransactions contains held expenses, compute the unheld amounts directly from allReportTransactions (filtering transactions where !isHold(transaction)) as an optimistic fallback when iouReport?.unheldTotal is missing or equal to the full total:

• Calculate unheldTransactionTotal from allReportTransactions.filter(t => !isHold(t)) (separating reimbursable vs non-reimbursable amounts).
• Use this derived amount for unheldTotal and unheldReimbursableTotal when report-level unheld fields have not yet synced from the backend.

This ensures the partial approval dropdown immediately displays the true pending (non-held) amount in sync with the user's optimistic hold actions.

What alternative solutions did you explore? (Optional)

We could also update iouReport.unheldTotal optimistically in the putOnHold action, but calculating the client fallback inside getNonHeldAndFullAmount using the already-provided allReportTransactions is cleaner, self-contained, and guarantees accurate display across all report types and viewers.

Test Plan:

1. As an employee, submit two expenses (e.g. $50 and $50) in a workspace report.
2. Open one of the expenses and put it on Hold.
3. As an approver, navigate to the report and click on the "Approve" button.
4. Verify the dropdown displays:
   • "Approve only $50" (for the unheld pending expense).
   • "Approve $100" (for the full report total).
5. Confirm clicking "Approve only" approves only the non-held amount.

[ashusatyarthi-wq]

Contributor details
Your Expensify account email: ashusatyarthi@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010e53044b5828fe60

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[hgreco85]

Proposal

What is the root cause of that problem?

getNonHeldAndFullAmount builds the Approve dropdown amounts from report-level unheld* totals.

The problem is that after an expense is put on hold, the approver can already receive the held state on the transaction, so the partial-approve option appears, while their copy of the report may still have stale unheldTotal / unheldReimbursableTotal values equal to the full total.

That makes both options display the same amount.

The same stale report fields are also used by the partial approve/pay paths, so this can affect not only the label shown to the user, but also the optimistic amount submitted.

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

Keep preferring backend-computed unheld* fields when they are consistent, but add a fallback when held transactions prove those fields are stale.

Instead of summing unheld transactions, derive the non-held amount as:

full report total - sum(held transaction amounts in report currency)

This is safer because some callers may have only a partial transaction list; summing the visible unheld transactions could therefore undercount the real pending amount.

I would:

1. Add a small shared numeric helper near getNonHeldAndFullAmount.
2. Use the transaction-derived fallback only when:
   • held transactions exist, and
   • the report-level unheld value is missing or still equal to the full total.
3. For held transactions:
   • use the report-currency amount / converted amount when needed;
   • for the Pay branch, subtract only reimbursable held transactions.
4. Reuse the same helper in:
   • getNonHeldAndFullAmount
   • the partial approve path in ReportWorkflow
   • the partial pay path in PayMoneyRequest

This keeps the displayed amount and submitted amount consistent without broadly replacing the backend totals logic.

What alternative solutions did you explore?

Always recalculating the unheld amount from all unheld transactions would be broader and can be incorrect when a caller has an incomplete transaction list.

Updating only the optimistic unheld* fields in putOnHold also would not fully solve this case, because that optimistic update runs on the client that places the hold, not necessarily on the approver's client.

Test Plan

Add focused unit coverage for:

1. Stale approver case: unheldTotal === fullTotal with one held and one unheld transaction → partial amount excludes the held expense.
2. Backend already correct: existing reduced unheldTotal is preserved.
3. Reimbursable vs non-reimbursable held transactions for the Pay path.
4. Mixed-currency held transaction using its report-currency converted amount.
5. All-held case keeps the partial option suppressed.

Also verify that the same calculated partial amount is used by the approve/pay submission paths.

Manual repro:

• Employee submits two expenses and holds one.
• Approver opens the Approve menu.
• "Approve only X" shows the non-held amount and differs from "Approve Y".
• Choosing the partial action submits that same amount.