[Due for payment 2026-05-11] [$250] Expense - Tax amount does not update after bulk editing amount offline

[lanitochka17]

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.60-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
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): sdsodijnosdjoij@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:

Precondition:

• Enable Taxes in workspace settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses with 5% tax rate.
4. Open the report.
5. Go offline.
6. Select both expenses via checkbox.
7. Click More > Edit multiple.
8. Click Amount.
9. Enter amount > Save.
10. Click Save.
11. Open any edited expense.

Expected Result:

Tax amount will update after bulk editing amount offline. (It will update tax amount when editing single expense offline).

Actual Result:

Tax amount does not update after bulk editing amount offline.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7133136_1776533823088.5.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022045580697783873631
• Upwork Job ID: 2045580697783873631
• Last Price Increase: 2026-04-18

[MelvinBot]

Proposal

What is the root cause of that problem?

In BulkEdit.ts:183, the tax amount recalculation is gated behind if (changes.taxCode ...) — it only runs when the tax code itself is being changed. When bulk-editing only the amount, this condition is false, so taxAmount is never recalculated and stays stale.

The single-edit path in IOURequestStepAmount.tsx:417-419 does not have this problem — it unconditionally recalculates taxAmount whenever the amount changes.

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

In BulkEdit.ts, after setting transactionChanges.amount (line 168-170), add tax recalculation logic when the amount changes but taxCode was not explicitly changed. Specifically, when changes.amount is defined and the transaction has taxes enabled, recalculate taxAmount using the transaction's existing taxCode and the new amount — mirroring the pattern already used inside the if (changes.taxCode ...) block at lines 183-191.

The existing taxCode block (line 183) should remain as-is for when the user explicitly changes the tax rate.

What alternative solutions did you explore? (Optional)

An alternative would be to handle this in the getUpdatedTransaction utility or the API command itself, but the most consistent fix is at the bulk-edit call site since that's where the single-edit path already handles it (at the call site in IOURequestStepAmount.tsx).

---

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.

[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/~022045580697783873631

[wildan-m]

Proposal

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

When two expenses with a tax rate are bulk-edited offline to a new amount, each transaction's taxAmount is not recalculated — it stays at the value computed from the old amount. Opening a single edited expense then shows a stale tax value that no longer matches the new base amount. The single-expense edit flow recalculates taxAmount correctly, so the inconsistency appears specifically when using "Edit multiple → Amount".

What is the root cause of that problem?

Bulk edit is handled by updateMultipleMoneyRequests in src/libs/actions/IOU/BulkEdit.ts. For each selected transaction, it builds a transactionChanges object field-by-field. The amount field is handled here:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 168 to 170 in 03023c1

	if (changes.amount !== undefined && canEditField(CONST.EDIT_REQUEST_FIELD.AMOUNT)) {
	transactionChanges.amount = changes.amount;
	}

Tax recalculation, however, is hard-gated behind the changes.taxCode branch — it only runs if the user is also changing the tax rate:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 183 to 191 in 03023c1

	if (changes.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
	transactionChanges.taxCode = changes.taxCode;
	const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
	transactionChanges.taxValue = taxValue;
	const decimals = getCurrencyDecimals(getCurrency(transaction));
	const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
	const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
	transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
	}

When the user edits only the amount (the reported flow), changes.taxCode is undefined, that block is skipped entirely, and neither transactionChanges.taxAmount nor updates.taxAmount is populated. The API call at API.write(WRITE_COMMANDS.UPDATE_MONEY_REQUEST, ...) then sends only {amount}, so the stored taxAmount is never refreshed.

getUpdatedTransaction in TransactionUtils does not plug this gap either — for an amount change it updates modifiedAmount but does not recompute taxAmount, it only does so when taxCode changes via getCategoryTaxCodeAndAmount:

App/src/libs/TransactionUtils/index.ts

Lines 709 to 712 in 03023c1

	if (Object.hasOwn(transactionChanges, 'amount') && typeof transactionChanges.amount === 'number') {
	updatedTransaction.modifiedAmount = isFromExpenseReport || isUnReportedExpense ? -transactionChanges.amount : transactionChanges.amount;
	shouldStopSmartscan = true;
	}

Contrast this with the single-expense amount edit in IOURequestStepAmount.tsx, which always recomputes taxAmount from the current taxCode and new amount before dispatching the update:

App/src/pages/iou/request/step/IOURequestStepAmount.tsx

Lines 415 to 419 in 03023c1

	const transactionTaxCode = getTransactionDetails(currentTransaction)?.taxCode;
	const defaultTaxCode = getDefaultTaxCode(policy, currentTransaction, selectedCurrency) ?? '';
	const taxCode = (selectedCurrency !== transactionCurrency ? defaultTaxCode : transactionTaxCode) ?? defaultTaxCode;
	const taxPercentage = getTaxValue(policy, currentTransaction, taxCode) ?? '';
	const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, newAmount, decimals));

So the asymmetry is: single-edit recomputes taxAmount at the call site; bulk-edit only recomputes it when taxCode itself changes. Offline, the stale bulk-edit value surfaces in the UI because there's no server round-trip to correct it.

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

In src/libs/actions/IOU/BulkEdit.ts, extend the "amount" branch so that whenever a new amount is being written AND the transaction already has a tax rate configured AND the user has not also changed taxCode in this bulk-edit, we recompute taxAmount using the transaction's existing taxCode. The recomputation reuses the same three helpers already used in the changes.taxCode branch — getTaxValue, calculateTaxAmount, convertToBackendAmount — with the same currency-decimals lookup via getCurrencyDecimals(getCurrency(transaction)). The new taxAmount is written into transactionChanges.taxAmount so it flows through the existing plumbing: removeUnchangedBulkEditFields at L200, the updates.taxAmount block at L227-L229, the optimistic transaction MERGE at L319-L329, and the buildOptimisticModifiedExpenseReportAction call at L380.

Three guards matter:

1. Gate on transaction.taxCode being non-empty. Otherwise for transactions with no tax enabled, getTaxValue returns undefined, calculateTaxAmount short-circuits to 0, and we'd clobber a null/absent taxAmount with a literal 0 — injecting an empty tax into a non-tax expense.
2. Keep supportsExpenseFields and canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE) as preconditions, mirroring the existing changes.taxCode branch, so we don't attempt tax recalculation on plain IOU transactions or when the user lacks permission.
3. Leave the existing changes.taxCode branch untouched and running AFTER the amount branch. That branch already handles the simultaneous amount+taxCode case via transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction)) at L188, so it correctly overrides our amount-only taxAmount when the user did change the tax rate.

Because transactionChanges.taxAmount now flows into getUpdatedTransaction → the optimistic MERGE, the offline UI will show the recomputed tax immediately. When the client comes back online, API.write will include the correct taxAmount in the updates payload, keeping the server consistent.

No additional Onyx plumbing, no new helper, no change to the pending-fields pipeline — getClearedPendingFields at L269 already picks up taxAmount from the transactionChanges keys automatically.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88262-bulk-edit-tax-amount-stale?expand=1

What alternative solutions did you explore? (Optional)

A more intrusive alternative would be to move tax recomputation into getUpdatedTransaction itself so every caller benefits. The objection is scope creep — the single-edit path already precomputes taxAmount at the call site and passes it in via transactionChanges.taxAmount, so moving the logic down would require auditing every caller to avoid double-computation. It would also entangle TransactionUtils with policy/tax-value lookups, which it currently avoids: getUpdatedTransaction never reaches into policy.taxRates except through the narrow getCategoryTaxCodeAndAmount helper.

A second alternative would be to drop the tax-code gate entirely and always recompute taxAmount for any amount change, matching the single-edit path which does so unconditionally. This simplifies the condition but risks storing taxAmount: 0 on transactions that never had tax enabled, potentially causing downstream views that check taxAmount != null (rather than taxAmount > 0) to treat them as tax-enabled. The transaction-has-taxCode gate is the safer default.

A related gap worth flagging but out of scope for this specific bug: the bulk-edit currency branch at L171-173 has the same shape — editing currency alone doesn't recompute taxAmount or taxCode even though single-edit's IOURequestStepAmount switches to defaultTaxCode for a new currency at L417. That's a separate scenario not in the reported repro and could ship as a follow-up.

[Tony-MK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @Tony-MK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[emkhalid]

Proposal

What is the root cause of that problem?

Bulk edit applies each edited field in updateMultipleMoneyRequests() in src/libs/actions/IOU/BulkEdit.ts. The amount branch only writes the new amount:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 168 to 170 in 03023c1

	if (changes.amount !== undefined && canEditField(CONST.EDIT_REQUEST_FIELD.AMOUNT)) {
	transactionChanges.amount = changes.amount;
	}

The tax amount recalculation is in the later tax-code branch in the same file. That branch only runs when changes.taxCode is present:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 183 to 190 in 03023c1

	if (changes.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
	transactionChanges.taxCode = changes.taxCode;
	const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
	transactionChanges.taxValue = taxValue;
	const decimals = getCurrencyDecimals(getCurrency(transaction));
	const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
	const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
	transactionChanges.taxAmount = convertToBackendAmount(taxAmount);

When the user bulk edits only the amount, changes.amount is defined but changes.taxCode is undefined. Because of that, the tax-code branch is skipped, so transactionChanges.taxAmount is never set.

The API payload is then built from transactionChanges. Since taxAmount was never added, updates.taxAmount is omitted and only the amount is sent:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 227 to 231 in 03023c1

	if (transactionChanges.taxAmount !== undefined) {
	updates.taxAmount = transactionChanges.taxAmount;
	}
	if (transactionChanges.amount !== undefined) {
	updates.amount = transactionChanges.amount;

Offline, the optimistic transaction update uses those same transactionChanges, so the amount changes immediately but the old tax amount remains visible.

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

In src/libs/actions/IOU/BulkEdit.ts, the original code calculates tax inside the changes.taxCode branch only:

App/src/libs/actions/IOU/BulkEdit.ts

Lines 183 to 190 in 03023c1

	if (changes.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
	transactionChanges.taxCode = changes.taxCode;
	const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
	transactionChanges.taxValue = taxValue;
	const decimals = getCurrencyDecimals(getCurrency(transaction));
	const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
	const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
	transactionChanges.taxAmount = convertToBackendAmount(taxAmount);

Replace that branch-specific calculation with one derived-tax step that runs after all direct bulk-edit fields are collected and before unchanged fields are filtered. This keeps tax derivation in one place and calculates taxAmount from the final effective amount and tax code.

diff --git a/src/libs/actions/IOU/BulkEdit.ts b/src/libs/actions/IOU/BulkEdit.ts
@@
         if (changes.taxCode && supportsExpenseFields && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
             transactionChanges.taxCode = changes.taxCode;
-            const taxValue = getTaxValue(transactionPolicy, transaction, changes.taxCode);
-            transactionChanges.taxValue = taxValue;
-            const decimals = getCurrencyDecimals(getCurrency(transaction));
-            const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
-            const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
-            transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
         }
@@
         if (changes.reimbursable !== undefined && canEditField(CONST.EDIT_REQUEST_FIELD.REIMBURSABLE)) {
             transactionChanges.reimbursable = changes.reimbursable;
         }
+
+        const didAmountChange = Object.hasOwn(transactionChanges, 'amount');
+        const didTaxCodeChange = Object.hasOwn(transactionChanges, 'taxCode');
+        if (supportsExpenseFields && (didAmountChange || didTaxCodeChange) && canEditField(CONST.EDIT_REQUEST_FIELD.TAX_RATE)) {
+            const effectiveTaxCode = didTaxCodeChange ? transactionChanges.taxCode : transaction.taxCode;
+            if (effectiveTaxCode) {
+                const taxValue = getTaxValue(transactionPolicy, transaction, effectiveTaxCode);
+                const decimals = getCurrencyDecimals(getCurrency(transaction));
+                const effectiveAmount = transactionChanges.amount !== undefined ? Math.abs(transactionChanges.amount) : Math.abs(getAmount(transaction));
+                const taxAmount = calculateTaxAmount(taxValue, effectiveAmount, decimals);
+
+                if (didTaxCodeChange) {
+                    transactionChanges.taxValue = taxValue;
+                }
+                transactionChanges.taxAmount = convertToBackendAmount(taxAmount);
+            }
+        }
 
         transactionChanges = removeUnchangedBulkEditFields(transactionChanges, transaction, baseIouReport, transactionPolicy);

This derived-tax block does three things:

1. It runs only when amount or tax code changed, expense fields are supported, and tax-rate editing is allowed.
2. It uses the edited tax code when the user changed tax rate, otherwise it uses the transaction's existing tax code.
3. It calculates taxAmount from the effective amount and effective tax code before the updates object is built.

This fixes the offline bulk-edit case because transactionChanges.taxAmount is now present for amount-only edits on taxable expenses. That value flows into the optimistic transaction update and into updates.taxAmount, so both the local UI and queued API request use the recalculated tax amount.

What alternative solutions did you explore? (Optional)

One alternative is to add a second tax recalculation block directly inside the amount branch. That is smaller, but it duplicates the tax calculation that already exists for tax-code edits and makes amount+tax-code behavior depend on branch ordering.

Another alternative is to extract the derived-tax logic into a new helper function. That is clean structurally, but it adds more lines to a narrow fix. Keeping the logic inline produces a smaller diff while still deriving tax from the final effective values in one place.

Another alternative is to move tax recalculation into getUpdatedTransaction(). That would update optimistic UI state, but it would not automatically add taxAmount to the updates payload built in BulkEdit.ts, so the queued API request could still omit the corrected tax amount.

Another alternative is to calculate the tax amount in SearchEditMultipleAmountPage.tsx when saving the bulk amount draft. That page does not have the correct per-transaction tax code and policy context for every selected expense, so the calculation belongs in updateMultipleMoneyRequests() where each transaction is processed individually.

Tax.Amount.webm

[Daddaabdelghafour]

Proposal

Root cause

When bulk editing expenses, the code in updateMultipleMoneyRequests()
inside src/libs/actions/IOU/BulkEdit.ts handles amount changes and tax
code changes in two completely separate branches. The problem is that tax
amount recalculation only happens inside the tax code branch — so when a
user edits only the amount, the tax branch never runs, and taxAmount
is never recalculated or added to transactionChanges.

Since the API payload and the optimistic Onyx update are both built from
transactionChanges, the new amount goes through but the old tax amount
stays unchanged — both in the UI and in the queued offline request.

This doesn't happen on single expense edits because that flow recalculates
tax locally regardless of what changed.

Proposed fix

Move the tax recalculation outside of the tax code branch entirely. After
all direct field changes are collected, add a derived-tax step that runs
whenever amount or taxCode changed, supportsExpenseFields is true,
and tax rate editing is allowed.

Inside this step:

• Use the new tax code if it was edited, otherwise fall back to the
  existing transaction.taxCode
• Recalculate taxAmount using the effective amount and effective tax code
• Only update taxValue when the tax code itself was changed

This way, transactionChanges.taxAmount is always present for amount-only
edits on taxable expenses, and it flows correctly into both the optimistic
UI update and the queued API request — fixing the offline case completely.

Testing plan

• Enable taxes in workspace, create 2+ expenses with a tax rate
• Go offline → bulk edit amount → verify tax amount updates on all expenses
• Confirm single expense offline editing still works (no regression)
• Confirm online bulk editing still works correctly
• Test on iOS, Android, and Web with screenshots before PR submission

Contributor details
Expensify account email: abroud498@gmail.com
Upwork Profile Link : https://www.upwork.com/freelancers/abdelghafourd2