[Due for payment 2026-09-16] [$250] Expense - No approval options when expense with 0.00 amount is held

[mitarachim]

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.25-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: #70825
Email or phone of affected tester (no customers): jsodjsodnjoisjdosij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense with 0.00 amount.
4. Create another expense with negative amount.
5. Open the expense report.
6. Hold the expense with 0.00 amount.
7. Go back to workspace chat.
8. Click Submit.
9. Click Approve button.

Expected Result:

Approve dropdown button will give options to approve pending amount or full amount.

Actual Result:

The expenses are approved without any option.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7086421_1771884483458.2.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ahmedGaber93

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022026071436582467634
• Upwork Job ID: 2026071436582467634
• Last Price Increase: 2026-02-23

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #70825

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

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

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

[MelvinBot]

Proposal

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

When an expense report contains a $0.00 held expense alongside a negative-amount expense, clicking the Approve button auto-approves the full report without showing any approval options (partial vs full). The expected behavior is a dropdown presenting "Approve only $X" (non-held amount) and "Approve $Y" (full amount) options.

What is the root cause of that problem?

PR #70825 introduced ExpenseHeaderApprovalButton, which replaced the old ProcessMoneyReportHoldMenu (DecisionModal) for approval confirmations. The new component builds a dropdown with partial/full options via getApprovalDropdownOptions, but only renders the dropdown when approvalOptions.length > 1. When there's only 1 option, it falls through to a plain Button that calls onApprove(true) (full approval) immediately.

The issue is in how hasValidNonHeldAmount is computed in getNonHeldAndFullAmount (ReportUtils.ts:10618-10623):

hasValidNonHeldAmount =
    hasHeldExpensesLocal &&
    (adjustedUnheldTotal >= 0 ||
        (isExpenseReport && abs(adjustedUnheldTotal) > 0
         && abs(adjustedUnheldTotal) !== abs(adjustedTotal)));

When a $0.00 expense is held, holding it does not change unheldTotal (since transactionAmount = 0), so unheldTotal === total. This means Math.abs(adjustedUnheldTotal) === Math.abs(adjustedTotal), causing the fallback condition to fail. If adjustedUnheldTotal is also negative (which it is for expense reports with negative amounts), the first condition (>= 0) also fails. Result: hasValidNonHeldAmount = false.

With hasValidNonHeldAmount = false, getApprovalDropdownOptions (ExpenseHeaderApprovalButton.tsx:73) skips the partial-approve option, producing only 1 option. The check at line 122 (approvalOptions.length > 1) fails, and the component renders a plain Button that auto-approves without any confirmation.

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

In ExpenseHeaderApprovalButton.tsx, when shouldShowDropdown is true (held expenses exist) but only 1 approval option is generated (e.g., the $0 held edge case), the component should still show a confirmation UI rather than silently auto-approving. Two approaches:

1. Show the dropdown even with 1 option when shouldShowDropdown is true: Change the condition at line 122 from approvalOptions.length > 1 to just check shouldShowDropdown, and always use the ButtonWithDropdownMenu (which already has shouldAlwaysShowDropdownMenu=true). This ensures the user sees a confirmation before approving held expenses.

2. Fix the hasValidNonHeldAmount calculation to handle the case where unheldTotal === total (held amount is $0) by recognizing that there ARE held expenses even when the amounts are identical. This would produce 2 options and the dropdown would render naturally.

Option 1 is the safer, more minimal fix since it addresses the symptom directly: any time held expenses exist, the user should see a confirmation before approving.

What alternative solutions did you explore? (Optional)

• Fixing the !!expenseReport.unheldTotal truthiness check in approveMoneyRequest (IOU/index.ts:10548) — this has the same falsy-zero bug but is a secondary issue since the UI already skips showing options.
• Restoring the old ProcessMoneyReportHoldMenu flow for approvals — this was intentionally replaced by PR Clarify Approval Options When Held Expenses Exist #70825, so reverting would undo the intended UX improvement.

Detailed Investigation

Evidence Chain

1. Holding a $0 expense doesn't change unheldTotal (Hold.ts:115): transactionAmount = 0 * coefficient = 0, so unheldTotal = total - 0 = total.

2. hasValidNonHeldAmount evaluates to false (ReportUtils.ts:10618-10623): Since unheldTotal === total, the absolute values are equal, and for expense reports with negative adjustedUnheldTotal, both conditions fail.

3. Only 1 dropdown option is generated (ExpenseHeaderApprovalButton.tsx:73-81): The partial-approve option requires nonHeldAmount && hasValidNonHeldAmount && !hasOnlyHeldExpenses. With hasValidNonHeldAmount = false, the partial option is skipped.

4. Dropdown doesn't render (ExpenseHeaderApprovalButton.tsx:122): approvalOptions.length > 1 is false, so ButtonWithDropdownMenu is not used.

5. Plain Button auto-approves (ExpenseHeaderApprovalButton.tsx:139-147): Falls through to onApprove(true) which calls approveMoneyRequest with full approval.

Relevant Code

• src/components/ExpenseHeaderApprovalButton.tsx:59-147 - Core approval button logic with the bug
• src/libs/ReportUtils.ts:10599-10630 - getNonHeldAndFullAmount with hasValidNonHeldAmount calculation
• src/libs/actions/IOU/Hold.ts:107-118 - Hold action that doesn't change unheldTotal for $0
• src/libs/actions/IOU/index.ts:10545-10550 - Secondary !!unheldTotal truthiness bug
• src/components/MoneyReportHeader.tsx:1019-1025 - onApprove handler that bypasses confirmation

Implementation Notes

• The shouldAlwaysShowDropdownMenu prop is already passed to ButtonWithDropdownMenu in the dropdown path, so using it with 1 option should work
• The secondary actions menu (3-dot menu) has its own approval submenu logic that may also need the same fix
• The !!expenseReport.unheldTotal check in approveMoneyRequest should be changed to a proper comparison (e.g., expenseReport.unheldTotal !== undefined && expenseReport.unheldTotal !== null) as a separate fix

---

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