[$250] Tax-Tax rate is not updated on the confirmation page after changing currency

[applause-bot]

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.4.9-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/folder/13176868/test-cases/41237330
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 26.5 Chrome, iPhone 15 iOS 26.5
App Component: Money Requests

Action Performed:

1. Sign in to ND
2. Create a collect workspace, enable Taxes
3. Create a new tax, set the name to the Foreign and the value to 10%
4. Change the 5% tax rate name to Default
5. Set the Default rate for Workspace currency default and the Foreign for Foreign currency default in Tax settings
6. Start creating a manual expense in the workspace chat
7. Enter an amount, ensuring the initial currency is the workspace's default
8. Click "Next"
9. Scroll down and Verify that the Default rate is applied
10. Click the back button
11. Change the currency, click "Next"
12. Verify that the tax rate is changed to the Foreign

Expected Result:

The Tax rate and the amount are changed according to a new currency

Actual Result:

The default workspace currency tax rate is still displayed on the confirmation page and on the expense details after changing the expense currency

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7182979_1781659649206.foreign_tax_not_updated.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7182979

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067140356654241995
• Upwork Job ID: 2067140356654241995
• Last Price Increase: 2026-06-24

Issue Owner

Current Issue Owner: @lakchote

[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/69b89277d3d4067f919752e8b1a85a7e7cc390705bca89e608a5ca382060e94c

[MelvinBot]

Proposal

What is the root cause of that problem?

When you change the expense currency on the Amount page and tap Next, the confirmation step (IOURequestStepConfirmation) is a separate route that unmounts when you go Back and remounts when you come forward again. On that fresh mount, the confirmation list incorrectly decides to keep your old tax rate instead of applying the new currency's default.

The faulty decision lives in useTaxAmount.ts:58-59:

const previousDefaultTaxCode = getDefaultTaxCode(policy, transaction, previousTransactionCurrency);
const shouldKeepCurrentTaxSelection = hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode;

previousTransactionCurrency comes from usePrevious(transaction?.currency). But usePrevious seeds its ref with the current value on the first render (useRef<T>(value)), so on a fresh mount previousTransactionCurrency equals the new (foreign) currency — not the actual prior currency.

That makes the heuristic misfire:

• previousDefaultTaxCode resolves to the foreign default (Foreign/10%) instead of the prior Default/5%.
• The transaction still carries taxCode = Default (set on the first visit), and hasTaxRateWithMatchingValue is true.
• So Default !== Foreign → shouldKeepCurrentTaxSelection = true.

With shouldKeepCurrentTaxSelection true, TaxController.tsx:39-41 returns early and never calls setMoneyRequestTaxRateValues, so the stale Default (5%) tax rate remains on the confirmation page and on the expense details.

Why the heuristic exists & why it breaks here

shouldKeepCurrentTaxSelection is meant to preserve a tax rate the user manually picked across a currency change (detected by taxCode differing from the previous currency's default). It infers "manual override" by comparing the current taxCode to the previous-currency default. On a genuine in-place currency change this works, because usePrevious returns the real prior currency. But because the confirmation page is a distinct route that remounts on Back→Next, usePrevious returns the current currency on first render, so the comparison is made against the wrong baseline and an auto-applied default is mistaken for a manual selection.

Note that the non-editing create path in IOURequestStepAmount.tsx:473-479 returns early without recomputing tax, so it relies entirely on the confirmation page's TaxController to apply the correct default — which the above bug suppresses.

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

Make the "keep the user's tax selection" decision robust to a confirmation-list remount, so a fresh mount after a currency change applies the new currency's default rate.

Concretely, in useTaxAmount.ts: only treat the selection as "manually kept" when there is a real previous currency that differs from the current one. When previousTransactionCurrency is unavailable or equals the current currency (i.e. a fresh mount, where no in-session change can be detected), do not set shouldKeepCurrentTaxSelection — let TaxController apply defaultTaxCode for the current currency.

This keeps the intended behavior (preserving a genuinely user-chosen tax rate during an in-place currency change) while fixing the remount case so the foreign default is correctly applied.

What alternative solutions did you explore? (Optional)

• Persist an explicit "user manually selected tax" flag on the transaction and gate shouldKeepCurrentTaxSelection on it, rather than inferring intent from currency diffs across renders. More robust but larger in scope.
• Recompute and apply the currency-based default tax in the create path of IOURequestStepAmount (mirroring the existing track-expense branch at IOURequestStepAmount.tsx:238-246) so it doesn't rely solely on the confirmation page.

Confidence: Medium-High — root cause is supported by specific code evidence and the mechanism is deterministic (the confirmation step is a separate route that remounts, and usePrevious seeds with the current value on first render). Not yet verified with a live repro.

---

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

[ahmdshrif]

Proposal

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

On the expense confirmation page, changing the transaction's currency does not update the displayed Tax rate. The foreign-currency default tax rate (or the workspace default, when switching back) should be re-applied automatically when the currency changes, but the page keeps showing the previously selected rate.

What is the root cause of that problem?

Tax is recomputed on the confirmation page through useTaxAmount → TaxController. useTaxAmount computes the new default via getDefaultTaxCode(policy, transaction), which resolves to foreignTaxDefault vs defaultExternalID based on the (new) currency:

App/src/libs/TransactionUtils/index.ts

Line 2145 in 257cd2d

return policy?.outputCurrency === (currency ?? getCurrency(transaction)) ? defaultExternalID : foreignTaxDefault;

But the re-apply is gated by shouldKeepCurrentTaxSelection:

App/src/components/MoneyRequestConfirmationList/hooks/useTaxAmount.ts

Lines 56 to 59 in 257cd2d

	const defaultTaxCode = getDefaultTaxCode(policy, transaction) ?? (isMovingTransactionFromTrackExpense ? (getDefaultTaxCode(policyForMovingExpenses, transaction) ?? '') : '');
	const defaultTaxValue = getTaxValue(policy, transaction, defaultTaxCode) ?? null;
	const previousDefaultTaxCode = getDefaultTaxCode(policy, transaction, previousTransactionCurrency);
	const shouldKeepCurrentTaxSelection = hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode;

shouldKeepCurrentTaxSelection = hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode. When the currency changes, the transaction still carries the old taxCode/taxValue, so hasTaxRateWithMatchingValue is true; and because the previous default differs from the (still-old) taxCode only in the cases this guard was meant to catch, the guard evaluates true and TaxController early-returns before applying the new default:

App/src/components/MoneyRequestConfirmationList/TaxController.tsx

Lines 39 to 40 in 257cd2d

	if (shouldKeepCurrentTaxSelection) {
	return;

So the stale tax code is preserved across the currency change instead of being replaced by the currency-appropriate default.

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

The guard should not suppress a re-apply when the currency itself changed. Detect a currency change explicitly and bypass shouldKeepCurrentTaxSelection in that case, so the default tax code for the new currency is applied:

// useTaxAmount.ts
const currencyChanged = !!previousTransactionCurrency && previousTransactionCurrency !== getCurrency(transaction);
const shouldKeepCurrentTaxSelection =
    !currencyChanged && hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode;

This forces TaxController to call setMoneyRequestTaxRateValues with the new defaultTaxCode/defaultTaxValue when the currency flips between the workspace currency and a foreign currency. Regression check: a genuine manual tax selection (no currency change) must still be preserved — verify switching currency back and forth restores each currency's default, and that manually picking a non-default rate without changing currency is untouched.

[mukhrr]

Proposal

What is the root cause of that problem?

The create/manual amount flow updates the draft amount and currency, but does not update the draft tax fields for normal workspace expenses.

In navigateToNextPage(), we save the new amount/currency with setMoneyRequestAmount():

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

Line 236 in 7af4b0e

setMoneyRequestAmount(transactionID, amountInSmallestCurrencyUnits, selectedCurrency || CONST.CURRENCY.USD, shouldKeepUserInput, hasReceipt(transaction));

But setMoneyRequestAmount() only writes amount, currency, shouldShowOriginalAmount, and isAmountSet; it leaves taxCode, taxAmount, and taxValue untouched:

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

Lines 750 to 754 in 7af4b0e

	function setMoneyRequestAmount(transactionID: string, amount: number, currency: string, shouldShowOriginalAmount = false, shouldStopSmartscan = false) {
	// Mark that the user has explicitly set the amount. This is used by the new manual expense flow to distinguish
	// a default amount of 0 (field empty) from a user-entered 0 (valid $0 expense).
	Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`, {amount, currency, shouldShowOriginalAmount, isAmountSet: true});
	setMoneyRequestReceiptState(transactionID, true, shouldStopSmartscan);

There is already tax recalculation in this function, but it only runs for isMovingTransactionFromTrackExpense(action):

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

Lines 238 to 246 in 7af4b0e

	if (isMovingTransactionFromTrackExpense(action)) {
	const taxCode = selectedCurrency !== policy?.outputCurrency ? policy?.taxRates?.foreignTaxDefault : policy?.taxRates?.defaultExternalID;
	if (taxCode) {
	setMoneyRequestTaxRate(transactionID, taxCode);
	const taxPercentage = getTaxValue(policy, transaction, taxCode) ?? '';
	const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, amountInSmallestCurrencyUnits, decimals));
	setMoneyRequestTaxAmount(transactionID, taxAmount);
	}
	}

So the failing path is:

1. Confirmation materializes/displays the workspace default tax.
2. User goes back and changes currency.
3. Amount step updates only currency, leaving the previous taxCode in the draft.
4. Confirmation/details prefer the draft tax fields, so they keep showing the old workspace default.

This is inconsistent with similar existing flows:

• Editing amount/currency already resets tax to the currency default when the currency changes:
  

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

  Lines 489 to 519 in 7af4b0e

  	// If currency has changed, then we get the default tax rate based on currency, otherwise we use the current tax rate selected in transaction, if we have it.
  	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));
  	if (isSplitBill) {
  	setDraftSplitTransaction(transactionID, splitDraftTransaction, {amount: newAmount, currency: selectedCurrency, taxCode, taxAmount});
  	navigateBack();
  	return;
  	}
  	// Reset split shares for non-split-bill edits (split-bill share recalculation is handled by the confirmation list).
  	if (transaction?.splitShares) {
  	resetSplitShares(transaction, newAmount, selectedCurrency, currentUserAccountIDParam, false);
  	}
  	updateMoneyRequestAmountAndCurrency({
  	transactionID,
  	transactionThreadReport: report,
  	parentReport,
  	parentReportNextStep,
  	transactions: duplicateTransactions,
  	transactionViolations: duplicateTransactionViolations,
  	currency: selectedCurrency,
  	amount: newAmount,
  	taxAmount,
  	policy,
  	taxCode,
  	taxValue: taxPercentage,

• Distance rate changes update tax code, amount, and value together:
  

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

  Lines 182 to 197 in 7af4b0e

  	let taxAmount;
  	let taxRateExternalID;
  	let taxValue;
  	if (shouldShowTax) {
  	const policyCustomUnitRate = getDistanceRateCustomUnitRate(policy, customUnitRateID);
  	const defaultTaxCode = getDefaultTaxCode(policy, currentTransaction, undefined, customUnitRateID) ?? '';
  	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
  	taxRateExternalID = policyCustomUnitRate?.attributes?.taxRateExternalID || defaultTaxCode;
  	const taxableAmount = DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, getDistanceInMeters(currentTransaction, currentUnit));
  	taxValue = taxRateExternalID ? getTaxValue(policy, currentTransaction, taxRateExternalID) : undefined;
  	taxAmount = convertToBackendAmount(calculateTaxAmount(taxValue, taxableAmount, getCurrencyDecimals(rates[customUnitRateID].currency)));
  	if (!isEditing || !taxRateExternalID) {
  	setMoneyRequestTaxAmount(transactionID, taxAmount, shouldUseTransactionDraft(action));
  	setMoneyRequestTaxRate(transactionID, taxRateExternalID ?? null, shouldUseTransactionDraft(action));
  	setMoneyRequestTaxValue(transactionID, taxValue ?? null, shouldUseTransactionDraft(action));
  	}

• Manual tax-rate selection also writes tax code, amount, and value together:
  

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

  Lines 112 to 139 in 7af4b0e

  	const taxAmount = getTaxAmount(policy, currentTransaction, taxes.code, getAmount(currentTransaction, false, true), decimals);
  	const taxValue = getTaxValue(policy, currentTransaction, taxes.code) ?? '';
  	if (isEditingSplitBill) {
  	setDraftSplitTransaction(currentTransaction.transactionID, splitDraftTransaction, {
  	taxAmount: convertToBackendAmount(taxAmount ?? 0),
  	taxCode: taxes.code,
  	taxValue,
  	});
  	navigateBack();
  	return;
  	}
  	if (isEditing) {
  	const newTaxCode = taxes.code;
  	updateMoneyRequestTaxRate({...updateTaxRateParams, taxCode: newTaxCode, taxValue, taxAmount: convertToBackendAmount(taxAmount ?? 0)});
  	navigateBack();
  	return;
  	}
  	if (taxAmount === undefined) {
  	navigateBack();
  	return;
  	}
  	const amountInSmallestCurrencyUnits = convertToBackendAmount(taxAmount);
  	setMoneyRequestTaxRateValues(currentTransaction.transactionID, {taxCode: taxes?.code ?? '', taxAmount: amountInSmallestCurrencyUnits, taxValue});

The correct default selector already exists: getDefaultTaxCode() returns defaultExternalID for the workspace currency and foreignTaxDefault for foreign currency:

App/src/libs/TransactionUtils/index.ts

Lines 2129 to 2145 in 7af4b0e

	function getDefaultTaxCode(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, currency?: string | undefined, newCustomUnitRateID?: string): string | undefined {
	if (isDistanceRequest(transaction)) {
	// When editing a distance rate, the draft transaction's customUnitRateID
	// does not reflect the newly selected rate until setMoneyRequestDistanceRate is called, and the draft transaction's is updated.
	// Therefore, to correctly determine the tax code for the selected rate, we must use the newly selected distance rate's customUnitRateID (newCustomUnitRateID)
	// instead of relying on the transaction's current customUnitRateID.
	const customUnitRateID = newCustomUnitRateID ?? getRateID(transaction) ?? '';
	const customUnitRate = getDistanceRateCustomUnitRate(policy, customUnitRateID);
	const customUnit = getDistanceRateCustomUnit(policy);
	if (!customUnitRate?.attributes?.taxRateExternalID && customUnit?.attributes?.taxEnabled) {
	return policy?.taxRates?.defaultExternalID;
	}
	return customUnitRate?.attributes?.taxRateExternalID;
	}
	const defaultExternalID = policy?.taxRates?.defaultExternalID;
	const foreignTaxDefault = policy?.taxRates?.foreignTaxDefault;
	return policy?.outputCurrency === (currency ?? getCurrency(transaction)) ? defaultExternalID : foreignTaxDefault;

I also checked recent history for IOURequestStepAmount.tsx. Recent commits touched P2P amount rules, mount-time perf, and track-expense currency plumbing, but not this tax recalculation path:

• 1095733
• 6949baf
• 4a1cfa1

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

Update navigateToNextPage() for non-edit manual workspace expenses so that when taxes are enabled and the selected currency changes, we recalculate and store taxCode, taxAmount, and taxValue using the same currency-default rule as the edit flow.

Small diff-style sketch:

 setMoneyRequestAmount(transactionID, amountInSmallestCurrencyUnits, selectedCurrency || CONST.CURRENCY.USD, shouldKeepUserInput, hasReceipt(transaction));

-if (isMovingTransactionFromTrackExpense(action)) {
-    const taxCode = selectedCurrency !== policy?.outputCurrency ? policy?.taxRates?.foreignTaxDefault : policy?.taxRates?.defaultExternalID;
+const previousCurrency = getCurrency(transaction);
+const shouldUpdateDefaultTax =
+    policy?.tax?.trackingEnabled &&
+    selectedCurrency !== previousCurrency &&
+    !isDistanceRequest(transaction);
+
+if (isMovingTransactionFromTrackExpense(action) || shouldUpdateDefaultTax) {
+    const taxCode = getDefaultTaxCode(policy, transaction, selectedCurrency);
     if (taxCode) {
         setMoneyRequestTaxRate(transactionID, taxCode);
         const taxPercentage = getTaxValue(policy, transaction, taxCode) ?? '';
         const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, amountInSmallestCurrencyUnits, decimals));
         setMoneyRequestTaxAmount(transactionID, taxAmount);
+        setMoneyRequestTaxValue(transactionID, taxPercentage);
     }
 }

To avoid regressions:

• Only run this for policies with tax tracking enabled.
• Only reset tax when the currency actually changes, matching the edit flow.
• Do not apply it to distance requests, since distance rate selection has its own tax logic.
• Keep the existing moving-from-track-expense behavior.
• Write taxCode, taxAmount, and taxValue together so draft state stays consistent.

QA:

1. Workspace currency default tax = Default; foreign currency default tax = Foreign.
2. Start a manual workspace expense in workspace currency and continue to confirmation.
3. Go back, change currency, continue.
4. Verify confirmation and created expense show Foreign and the recalculated tax amount.
5. Regression check: manually select a tax rate without changing currency and verify it is preserved.
6. Regression check: edit an existing expense amount/currency and verify existing behavior remains unchanged.

What alternative solutions did you explore? (Optional)

We could make confirmation derive the tax from currency at render time, but that only fixes display. The stale taxCode/taxAmount would still be submitted. Updating the draft when currency changes fixes both confirmation and final transaction data.

[dilshodmackbook-sketch]

Proposal

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

When creating a manual expense on a tax-enabled workspace, changing the currency before reaching the confirmation page does not re-apply the new currency's default tax rate. The previous (workspace-currency) default stays on the confirmation page and on the created expense, instead of switching to the foreign-currency default.

What is the root cause of that problem?

There are two layers here, and the create flow relies entirely on the second one, which silently misfires:

1. The create path never persists a currency-appropriate tax code. In navigateToNextPage, tax is recomputed only for the track-expense move case, so a normal currency change just stores the new currency and leaves the stale taxCode/taxAmount on the draft:
   

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

   Lines 232 to 243 in 257cd2d

   	const navigateToNextPage = ({amount, paymentMethod}: AmountParams) => {
   	isSaveButtonPressed.current = true;
   	const amountInSmallestCurrencyUnits = convertToBackendAmount(Number.parseFloat(amount));
   	setMoneyRequestAmount(transactionID, amountInSmallestCurrencyUnits, selectedCurrency || CONST.CURRENCY.USD, shouldKeepUserInput, hasReceipt(transaction));
   	if (isMovingTransactionFromTrackExpense(action)) {
   	const taxCode = selectedCurrency !== policy?.outputCurrency ? policy?.taxRates?.foreignTaxDefault : policy?.taxRates?.defaultExternalID;
   	if (taxCode) {
   	setMoneyRequestTaxRate(transactionID, taxCode);
   	const taxPercentage = getTaxValue(policy, transaction, taxCode) ?? '';
   	const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, amountInSmallestCurrencyUnits, decimals));

2. The confirmation page is supposed to fix this via TaxController, but its shouldKeepCurrentTaxSelection guard wrongly keeps the stale rate. That guard derives the "previous" default from usePrevious(transaction?.currency):
   

   App/src/components/MoneyRequestConfirmationList.tsx

   Line 256 in 257cd2d

   const customUnitRateID = getRateID(transaction);

usePrevious seeds its ref with the current value, so on the confirmation page's fresh mount (it unmounts on Back and remounts on Next) previousTransactionCurrency equals the new currency. That makes previousDefaultTaxCode resolve to the foreign default while the draft still carries the old taxCode, so transaction?.taxCode !== previousDefaultTaxCode is true and the guard is set:

App/src/components/MoneyRequestConfirmationList/hooks/useTaxAmount.ts

Lines 58 to 59 in 257cd2d

	const previousDefaultTaxCode = getDefaultTaxCode(policy, transaction, previousTransactionCurrency);
	const shouldKeepCurrentTaxSelection = hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode;

With the guard true, TaxController early-returns and never applies the new default:

App/src/components/MoneyRequestConfirmationList/TaxController.tsx

Lines 39 to 41 in 257cd2d

	if (shouldKeepCurrentTaxSelection) {
	return;
	}

Because the create path doesn't persist the right tax and the confirmation guard suppresses the correction on remount, the stale rate survives onto the submitted expense.

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

Fix it at the source so the persisted draft is always correct, independent of the confirmation page's render-timing heuristic. In navigateToNextPage, recompute the default tax code for the selected currency (reusing the editing flow's getDefaultTaxCode logic) whenever the currency changed, not only for track-expense moves:

const transactionCurrency = getCurrency(transaction);
if (isMovingTransactionFromTrackExpense(action) || selectedCurrency !== transactionCurrency) {
    const taxCode = getDefaultTaxCode(policy, transaction, selectedCurrency) ?? '';
    if (taxCode) {
        setMoneyRequestTaxRate(transactionID, taxCode);
        const taxPercentage = getTaxValue(policy, transaction, taxCode) ?? '';
        const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, amountInSmallestCurrencyUnits, decimals));
        setMoneyRequestTaxAmount(transactionID, taxAmount);
    }
}

This guarantees both the confirmation page and the final transaction carry the currency-appropriate tax, and the if (taxCode) guard keeps non-tax workspaces unaffected.

Additionally, we should make shouldKeepCurrentTaxSelection robust to a fresh mount so the confirmation page is not the weak link: only treat the selection as "manually kept" when there is a real prior currency that differs from the current one. Note a fix that merely compares previousTransactionCurrency !== currency is not sufficient on its own — on the remount usePrevious returns the current currency, so that comparison is false and the guard would still suppress the correction.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

On a tax-enabled workspace with distinct workspace-currency (defaultExternalID) and foreign-currency (foreignTaxDefault) defaults: start a manual expense in the workspace currency, go to confirmation, go Back, change the currency to a foreign one, press Next, and assert the draft transaction's taxCode/taxAmount equal the foreign default (and switching back restores the workspace default). Also assert a manually-picked non-default rate is preserved when the currency does not change.

What alternative solutions did you explore? (Optional)

Persist an explicit "user manually selected tax" flag on the transaction and gate shouldKeepCurrentTaxSelection on it rather than inferring intent by comparing currency defaults across renders. More robust, but larger in scope; the create-path persistence above is the lower-risk fix that also corrects the submitted data, not just the displayed rate.

[yusufdeveloper2903]

Proposal

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

When creating a manual expense (not a track-expense move and not an edit), the tax rate shown on the confirmation page is not updated after the currency is changed. If you open the confirmation page with the workspace's default currency (so the Default tax rate is applied), go back, change the currency to a foreign one, and continue, the confirmation page still shows the workspace-default tax rate instead of the Foreign tax rate that should apply to the new currency.

What is the root cause of that problem?

There are two layers that are supposed to keep the tax rate in sync with the currency, and for the plain "create manual expense" flow neither of them fires:

1. The amount step never recomputes the tax code for the regular create flow.

In navigateToNextPage (the "Next" button on the amount step), the tax code is only recomputed when moving a transaction from track expense:

// src/pages/iou/request/step/IOURequestStepAmount.tsx:238-246
if (isMovingTransactionFromTrackExpense(action)) {
    const taxCode = selectedCurrency !== policy?.outputCurrency ? policy?.taxRates?.foreignTaxDefault : policy?.taxRates?.defaultExternalID;
    if (taxCode) {
        setMoneyRequestTaxRate(transactionID, taxCode);
        ...
    }
}

For a regular manual expense this block is skipped, so transaction.taxCode keeps the stale value (the workspace-default tax) even though the currency changed. Note that the edit flow in the same file does handle this correctly (IOURequestStepAmount.tsx:489-492), which is why editing an expense works and only creation is broken.

2. The confirmation page's fallback (TaxController + useTaxAmount) is suppressed by a stale previousTransactionCurrency.

The confirmation page is supposed to recover from this via TaxController, which writes defaultTaxCode unless shouldKeepCurrentTaxSelection is true:

// src/components/MoneyRequestConfirmationList/hooks/useTaxAmount.ts:58-59
const previousDefaultTaxCode = getDefaultTaxCode(policy, transaction, previousTransactionCurrency);
const shouldKeepCurrentTaxSelection = hasTaxRateWithMatchingValue(policy, transaction) && transaction?.taxCode !== previousDefaultTaxCode;

previousTransactionCurrency comes from usePrevious(transaction?.currency) (MoneyRequestConfirmationList.tsx:255). When the user goes back to the amount step and returns, the confirmation list is unmounted and remounted, so usePrevious re-initializes and returns the new currency, not the old one. The consequence:

• defaultTaxCode = getDefaultTaxCode(policy, transaction[EUR]) → foreignTaxDefault ✅ (correct value we want)
• previousDefaultTaxCode = getDefaultTaxCode(policy, transaction, EUR) → foreignTaxDefault
• transaction.taxCode is still the stale defaultExternalID
• shouldKeepCurrentTaxSelection = true && (defaultExternalID !== foreignTaxDefault) = true

So TaxController early-returns (TaxController.tsx:39-41), wrongly treating the stale auto-default as a deliberate user selection, and the tax rate is never updated → bug.

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

Fix it at the source — recompute the tax code when the currency changes in the create flow's navigateToNextPage, mirroring the logic already used by the edit flow (IOURequestStepAmount.tsx:489-492) and the track-expense branch.

In src/pages/iou/request/step/IOURequestStepAmount.tsx, inside navigateToNextPage, generalize the current track-expense-only block:

const navigateToNextPage = ({amount, paymentMethod}: AmountParams) => {
    isSaveButtonPressed.current = true;
    const amountInSmallestCurrencyUnits = convertToBackendAmount(Number.parseFloat(amount));

    const previousCurrency = getCurrency(transaction);

    setMoneyRequestAmount(transactionID, amountInSmallestCurrencyUnits, selectedCurrency || CONST.CURRENCY.USD, shouldKeepUserInput, hasReceipt(transaction));

    // Recompute the default tax rate whenever the currency changed (or when moving from a track expense),
    // so the confirmation page shows the correct currency-based default (e.g. foreign default for a foreign currency).
    if (isMovingTransactionFromTrackExpense(action) || selectedCurrency !== previousCurrency) {
        const taxCode = getDefaultTaxCode(policy, transaction, selectedCurrency);
        if (taxCode) {
            setMoneyRequestTaxRate(transactionID, taxCode);
            const taxPercentage = getTaxValue(policy, transaction, taxCode) ?? '';
            const taxAmount = convertToBackendAmount(calculateTaxAmount(taxPercentage, amountInSmallestCurrencyUnits, decimals));
            setMoneyRequestTaxAmount(transactionID, taxAmount);
        }
    }

    // ...rest unchanged
};

Notes:

• Using getDefaultTaxCode(policy, transaction, selectedCurrency) instead of the inline outputCurrency check makes it consistent with the rest of the codebase (it also handles distance correctly).
• Gating on selectedCurrency !== previousCurrency preserves a user's manual tax-rate selection when they go back and change only the amount (currency unchanged → tax not reset).
• With transaction.taxCode now correctly set to the foreign default before navigation, the confirmation page's shouldKeepCurrentTaxSelection evaluates to false (foreignTaxDefault === foreignTaxDefault), so TaxController no longer fights the change. This fixes the bug end-to-end.

All helpers used (getDefaultTaxCode, getTaxValue, calculateTaxAmount, setMoneyRequestTaxRate, setMoneyRequestTaxAmount, getCurrency) are already imported in this file.

What alternative solutions did you explore? (Optional)

Fix the confirmation page instead — make shouldKeepCurrentTaxSelection robust to the remount so it doesn't rely on usePrevious across mount boundaries (e.g. persist the "user manually selected a tax rate" intent on the draft transaction, or compute previousDefaultTaxCode from the persisted currency rather than the React usePrevious value). This would also fix it, but it's a larger change to shared confirmation logic and risks regressions in the track-expense/edit flows, whereas the amount-step fix is localized and mirrors patterns already proven in the same file.

[melvin-bot]

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

[melvin-bot]

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