[Bulk Edit] [$250] Multiple edit-0% Tax rate is displayed after selecting a Tax rate in multiple edit

[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.51-1
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: #84756
Email or phone of affected tester (no customers): applausetester+dk29@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com/
2. Create new workspace
3. Enable Taxes field
4. Create 2 expenses in the workspace chat
5. Go to Reports > Expense
6. Go offline
7. Select 2 created expenses
8. Click on dropdown and select 'Multiple edit'
9. Select '5% tax rate'
10. Click on 'Save'
11. Open any expense

Expected Result:

Test 31: tax amount and tax rate should update appropriately

Actual Result:

Tax rate is displayed as '0%'

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7118740_1775028633399.Tax_rate_0__is_dispalyed_instead_of_selected_one.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039275047371975790
• Upwork Job ID: 2039275047371975790
• Last Price Increase: 2026-04-01

[MelvinBot]

Proposal

What is the root cause of that problem?

When bulk-editing the tax rate of multiple expenses, the taxValue field (the percentage string like "5%") is never included in the transactionChanges object. In updateMultipleMoneyRequests at src/libs/actions/IOU/index.ts:13388-13395, the code retrieves the tax percentage via getTaxValue() and uses it to calculate taxAmount, but only assigns taxCode and taxAmount to transactionChanges — the taxValue string is discarded:

if (changes.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
    transactionChanges.taxCode = changes.taxCode;
    const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
    // ...
    transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
    // BUG: transactionChanges.taxValue is never set
}

This means getUpdatedTransaction in src/libs/TransactionUtils/index.ts:818-820 skips updating taxValue on the optimistic transaction (it checks Object.hasOwn(transactionChanges, 'taxValue'), which is false). The optimistic transaction retains the old taxValue (e.g., "0%" from the default "Tax exempt" rate).

Then in MoneyRequestView at src/components/ReportActionItem/MoneyRequestView.tsx:635, the display logic detects a mismatch between the policy's rate value for the new taxCode and the stale taxValue, causing hasTaxValueChanged = true, which makes it display the old taxValue string ("0%") instead of looking up the correct rate name.

For comparison, the single-expense tax rate update (updateMoneyRequestTaxRate at line 5273-5277) correctly includes taxValue in transactionChanges.

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

In updateMultipleMoneyRequests at src/libs/actions/IOU/index.ts, add transactionChanges.taxValue = taxValue; inside the taxCode processing block (after line 13390), so the optimistic transaction gets the correct tax percentage string. This mirrors what the single-expense edit path already does.

Additionally, the updates object (sent to the API) should include taxValue when present, similar to how taxCode and taxAmount are already included. This ensures the backend also persists the correct taxValue.

What alternative solutions did you explore? (Optional)

An alternative would be to fix the display logic in MoneyRequestView to always resolve the tax name from taxCode via the policy lookup rather than using the stale taxValue field. However, this would only mask the symptom — the underlying data inconsistency (optimistic transaction having wrong taxValue) would still exist and could cause issues elsewhere. The correct fix is to include taxValue in the bulk edit data flow, consistent with the single-edit path.

---

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.