[$250] Tax - Tax name is missing and tax is no longer selected after changing tax code

[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.24-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #71244
Email or phone of affected tester (no customers): sdjoisjdosnijjsondijdso@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:

• Taxes are enabled.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense with 0% tax rate.
4. Create another expense with 5% tax rate.
5. Open any expense.
6. Click Tax field.
   → Tax field show tax rate name and it is selected in the list.
7. Go to workspace settings > Taxes.
8. Click 0% rate > Tax code.
9. Upgrade the workspace.
10. Edit tax code and save it.
11. Repeat Step 8 and 10 with 5% rate.
12. Open any expense from Step 3 or 4.
13. Click Tax field.
    → Tax field is not showing tax rate name. Tax is no longer selected in the list.
14. Go back to expense report.
15. Select both expenses via checkbox > click dropdown button > Merge.
    → Tax rate section is also missing tax rate name and it is showing only tax percentage.

Expected Result:

In Step 13 and 15, after editing tax code, Tax name will not disappear and tax will remain selected.

Actual Result:

After changing tax code,

• in Step 13, Tax field is not showing tax rate name. Tax is no longer selected in the list.
• in Step 15, Tax rate section is also missing tax rate name and it is showing only tax percentage.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7083791_1771614728935.7.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @marufsharifi

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024978932059523878
• Upwork Job ID: 2024978932059523878
• Last Price Increase: 2026-03-02

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

[MelvinBot]

Proposal

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

After editing a tax code in workspace settings (Workspace > Taxes > select a tax rate > Tax code > edit and save), the tax name disappears from existing expenses that used that tax rate. When opening the expense's tax field, no tax rate is selected in the list. Additionally, when merging expenses, the tax rate section shows only the tax percentage instead of the tax name.

What is the root cause of that problem?

Transactions store a taxCode field that corresponds to a key in policy.taxRates.taxes. When an admin edits a tax code via workspace settings, setPolicyTaxCode() at src/libs/actions/TaxRate.ts:577-578 deletes the old key ([oldTaxCode]: null) and creates a new key ([newTaxCode]: {...}). However, existing transactions still reference the old key via transaction.taxCode.

When the app tries to display the tax name, getTaxName() at src/libs/TransactionUtils/index.ts:2129 searches for a tax rate where rate.code === transaction.taxCode. Since the old key was deleted from the policy, .find() returns undefined, so the tax name is empty and no tax appears selected in the picker.

Notably, a function called getCurrentTaxID() at src/libs/PolicyUtils.ts:1596-1598 already handles this exact scenario by checking the previousTaxCode field (which setPolicyTaxCode sets on the renamed tax rate at TaxRate.ts:584). However, getCurrentTaxID() is only used in WorkspaceEditTaxPage for navigation -- it is not used in the transaction display path (getTaxName, getTaxValue, transformedTaxRates, or TaxPicker).

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

Modify transformedTaxRates() in src/libs/TransactionUtils/index.ts:2093-2108 to also include entries keyed by previousTaxCode when it exists. This way, when getTaxName() searches for rate.code === transaction.taxCode (where transaction.taxCode is the old/renamed code), it will find a match via the previousTaxCode mapping.

Specifically, in the .map() call inside transformedTaxRates(), for each tax rate that has a previousTaxCode, add an additional entry in the resulting dictionary keyed by previousTaxCode pointing to the same tax rate data (with code set to previousTaxCode). This ensures both the new and old tax codes resolve to the same tax rate.

This approach is clean because:

1. It uses the existing previousTaxCode field that setPolicyTaxCode() already sets
2. It fixes the display path (getTaxName), the value lookup (getTaxValue), the merge view (MergeTransactionUtils.ts:525), and the selection state in TaxPicker all at once, since they all go through transformedTaxRates()
3. It follows the same pattern already established by getCurrentTaxID() in PolicyUtils.ts

What alternative solutions did you explore? (Optional)

1. Modifying getTaxName() directly to call getCurrentTaxID() before doing the lookup. This would fix the name display but would require similar changes in getTaxValue(), getWorkspaceTaxesSettingsName(), TaxPicker, and MergeTransactionUtils -- more scattered changes.

2. Updating transactions' taxCode when the policy tax code changes (in the optimistic data of setPolicyTaxCode). This would be the most thorough fix but requires knowing all affected transaction IDs at the time of the policy change, which may not be feasible on the frontend. It would also require corresponding backend changes.

Detailed Investigation

Evidence Chain

1. Transaction stores taxCode as a plain string (src/types/onyx/Transaction.ts:453) -- this is the key into policy.taxRates.taxes
2. setPolicyTaxCode() deletes old key, creates new key (src/libs/actions/TaxRate.ts:577-585) -- sets [oldTaxCode]: null and [newTaxCode]: {...originalTaxRate, previousTaxCode: oldTaxCode}
3. No transaction Onyx data is updated -- the optimistic/success/failure data only touches policy and distance custom units
4. getTaxName() fails to find the tax (src/libs/TransactionUtils/index.ts:2129) -- .find((rate) => rate.code === transaction.taxCode) returns undefined
5. Tax name display shows empty -- MoneyRequestView.tsx:605 falls through the chain transaction.taxName ?? taxRateTitle ?? fallbackTaxRateTitle to show only the percentage
6. TaxPicker shows nothing selected -- TaxPicker.tsx:71-79 passes empty selectedOptions when selectedTaxRate is undefined
7. Merge view also affected -- MergeTransactionUtils.ts:525 uses getTaxName() with the same failure path

Relevant Code

• src/libs/TransactionUtils/index.ts:2093-2108 - transformedTaxRates() -- where the fix should go
• src/libs/TransactionUtils/index.ts:2127-2138 - getTaxName() -- the failing lookup
• src/libs/actions/TaxRate.ts:539-647 - setPolicyTaxCode() -- where the rename happens
• src/libs/PolicyUtils.ts:1596-1598 - getCurrentTaxID() -- existing resolution logic (only used for navigation)
• src/components/TaxPicker.tsx:71-89 - Tax picker selection matching
• src/libs/MergeTransactionUtils.ts:525 - Merge view tax name resolution

---

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

[melvin-bot]

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

[melvin-bot]

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

[abbasifaizan70]

Proposal

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

After editing a tax code in Workspace settings, the Tax field no longer shows the tax rate name or selection. The merge Tax rate section shows only the percentage, not the rate name.

What is the root cause of that problem?

Policy tax rates are keyed by tax code in policy.taxRates.taxes. When a code is edited (e.g. id_TAX_EXEMPT → GST-EXEMPT), setPolicyTaxCode removes the old key and adds the new one, so the rate exists only under the new code. Transactions still store the old code in transaction.taxCode. getTaxName

App/src/libs/TransactionUtils/index.ts

Lines 2130 to 2145 in eed56d0

	function transformedTaxRates(policy: OnyxEntry<Policy> | undefined, transaction?: OnyxEntry<Transaction>): Record<string, TaxRate> {
	const taxRates = policy?.taxRates;
	const defaultExternalID = taxRates?.defaultExternalID;
	const defaultTaxCode = () => {
	if (!transaction) {
	return defaultExternalID;
	}
	return policy && getDefaultTaxCode(policy, transaction);
	};
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const getModifiedName = (data: TaxRate, code: string) => `${data.name} (${data.value})${defaultTaxCode() === code ? ` ${CONST.DOT_SEPARATOR} ${translateLocal('common.default')}` : ''}`;
	const taxes = Object.fromEntries(Object.entries(taxRates?.taxes ?? {}).map(([code, data]) => [code, {...data, code, modifiedName: getModifiedName(data, code), name: data.name}]));
	return taxes;
	}

in TransactionUtils/index.ts looks up the label by matching transaction?.taxCode || defaultTaxCode to a rate’s code; there is no fallback when that code no longer exists (e.g. after a rename).

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

Update getTaxName in App/src/libs/TransactionUtils/index.ts (around line 2124) to use a three-step lookup so the tax name and selection stay correct after a code rename, without changing how transactions or the policy are stored:

1. Match by current code — Same as today: find the rate whose code equals transaction?.taxCode || defaultTaxCode.
2. Fallback: match by previousTaxCode — If no rate is found and the transaction has a tax code, find the rate whose previousTaxCode equals that code. (setPolicyTaxCode in TaxRate.ts sets this when a code is renamed.)
3. Fallback: match by value — If still not found and transaction.taxValue is set, use the rate’s name only when exactly one rate has value === transaction.taxValue.

Keep the existing shouldFallbackToValue logic and return taxRate?.modifiedName unchanged. Add a short JSDoc note that we fall back to previousTaxCode or tax value when the code was renamed.

suggested code

function getTaxName(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, shouldFallbackToValue = false) {
    const defaultTaxCode = getDefaultTaxCode(policy, transaction);
    const rates = Object.values(transformedTaxRates(policy, transaction));
    const transactionTaxCode = transaction?.taxCode || defaultTaxCode;

    let taxRate = rates.find((rate) => rate.code === transactionTaxCode);
    if (!taxRate && transaction?.taxCode) {
        taxRate = rates.find((rate) => rate.previousTaxCode === transaction.taxCode);
    }
    if (!taxRate && transaction?.taxValue !== undefined) {
        const ratesByValue = rates.filter((rate) => rate.value === transaction.taxValue);
        if (ratesByValue.length === 1) {
            taxRate = ratesByValue.at(0);
        }
    }

    if (shouldFallbackToValue && transaction?.taxValue !== undefined && taxRate?.value !== transaction?.taxValue) {
        return transaction?.taxValue;
    }
    return taxRate?.modifiedName;
}

[mobile84developer-ctrl]

Proposal

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

When a workspace tax code is updated, existing transactions that still reference the old tax code no longer resolve to a valid tax rate. As a result, the tax label and value disappear in expense views, merge flows, and the tax picker.

What is the root cause of that problem?

setPolicyTaxCode() removes the old tax key and creates a new one while storing previousTaxCode. However, tax resolution logic in getTaxName() and getTaxValue() only matches against rate.code. Since transactions retain the old taxCode, the lookup fails even though the new rate contains previousTaxCode.

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

Update tax resolution logic to also match against previousTaxCode when no direct match is found.

In src/libs/TransactionUtils/index.ts

1. Update getTaxName()

Replace

App/src/libs/TransactionUtils/index.ts

Line 2132 in a3a3d53

const taxRate = Object.values(transformedTaxRates(policy, transaction)).find((rate) => rate.code === (transaction?.taxCode || defaultTaxCode));

with

const rates = Object.values(transformedTaxRates(policy, transaction));
let taxRate = rates.find((rate) => rate.code === (transaction?.taxCode || defaultTaxCode));
if (!taxRate && transaction?.taxCode) {
    taxRate = rates.find((rate) => rate.previousTaxCode === transaction.taxCode);
}

2. Update getTaxValue()

Replace

App/src/libs/TransactionUtils/index.ts

Line 2114 in a3a3d53

return Object.values(transformedTaxRates(policy, transaction)).find((taxRate) => taxRate.code === taxCode)?.value;

With

const rates = Object.values(transformedTaxRates(policy, transaction));
let taxRate = rates.find((rate) => rate.code === taxCode);
if (!taxRate) {
    taxRate = rates.find((rate) => rate.previousTaxCode === taxCode);
}
return taxRate?.value;

What alternative solutions did you explore? (Optional)

N/A

[annaweber830]

Proposal

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

After a workspace tax code is edited, existing expenses that still store the old tax code lose their tax name in the UI, the tax is no longer selected in the tax picker, and merge preview can show only the tax percentage.

What is the root cause of that problem?

When a tax code is renamed, the old key is removed and a new key is created in policy.taxRates.taxes, while transactions still keep the previous code string in transaction.taxCode.

App/src/libs/actions/TaxRate.ts

Lines 577 to 585 in a8f2d3a

	taxes: {
	[oldTaxCode]: null,
	[newTaxCode]: {
	...originalTaxRate,
	pendingFields: {...originalTaxRate.pendingFields, code: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE},
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	errorFields: {code: null},
	previousTaxCode: oldTaxCode,
	},

taxRates: {
    taxes: {
        [oldTaxCode]: null,
        [newTaxCode]: {
            ...originalTaxRate,
            previousTaxCode: oldTaxCode,
        },
    },
},

Then tax display/selection logic resolves by direct code equality only (rate.code === transaction.taxCode), so old transaction codes no longer match and the lookup returns undefined. This causes the name to disappear and the picker to have no selected option.

App/src/libs/TransactionUtils/index.ts

Lines 2113 to 2138 in a8f2d3a

	function getTaxValue(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, taxCode: string) {
	return Object.values(transformedTaxRates(policy, transaction)).find((taxRate) => taxRate.code === taxCode)?.value;
	}
	/**
	* Gets the tax name for Workspace Taxes Settings
	*/
	function getWorkspaceTaxesSettingsName(policy: OnyxEntry<Policy>, taxCode: string) {
	return Object.values(transformedTaxRates(policy)).find((taxRate) => taxRate.code === taxCode)?.modifiedName;
	}
	/**
	* Gets the name corresponding to the taxCode that is displayed to the user
	*/
	function getTaxName(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, shouldFallbackToValue = false) {
	const defaultTaxCode = getDefaultTaxCode(policy, transaction);
	// transaction?.taxCode may be an empty string
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const taxRate = Object.values(transformedTaxRates(policy, transaction)).find((rate) => rate.code === (transaction?.taxCode || defaultTaxCode));
	if (shouldFallbackToValue && transaction?.taxValue !== undefined && taxRate?.value !== transaction?.taxValue) {
	return transaction?.taxValue;
	}
	return taxRate?.modifiedName;

function getTaxValue(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, taxCode: string) {
    return Object.values(transformedTaxRates(policy, transaction)).find((taxRate) => taxRate.code === taxCode)?.value;
}

function getTaxName(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, shouldFallbackToValue = false) {
    const defaultTaxCode = getDefaultTaxCode(policy, transaction);
    const taxRate = Object.values(transformedTaxRates(policy, transaction)).find((rate) => rate.code === (transaction?.taxCode || defaultTaxCode));
    return taxRate?.modifiedName;
}

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

Use the existing tax-code remap helper (getCurrentTaxID) in TransactionUtils before reading tax values/names, so old transaction tax codes are resolved to the currently valid policy tax code.

App/src/libs/TransactionUtils/index.ts

Lines 23 to 33 in a8f2d3a

	import {
	getCommaSeparatedTagNameWithSanitizedColons,
	getDistanceRateCustomUnit,
	getDistanceRateCustomUnitRate,
	getPolicy,
	getTaxByID,
	isInstantSubmitEnabled,
	isMultiLevelTags as isMultiLevelTagsPolicyUtils,
	isPolicyAdmin,
	isPolicyMember as isPolicyMemberPolicyUtils,
	} from '@libs/PolicyUtils';

App/src/libs/PolicyUtils.ts

Lines 1596 to 1598 in a8f2d3a

	function getCurrentTaxID(policy: OnyxEntry<Policy>, taxID: string): string | undefined {
	return Object.keys(policy?.taxRates?.taxes ?? {}).find((taxIDKey) => policy?.taxRates?.taxes?.[taxIDKey].previousTaxCode === taxID || taxIDKey === taxID);
	}

Current code:

import {
    getCommaSeparatedTagNameWithSanitizedColons,
    getDistanceRateCustomUnit,
    getDistanceRateCustomUnitRate,
    getPolicy,
    getTaxByID,
    isInstantSubmitEnabled,
} from '@libs/PolicyUtils';

function getTaxValue(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, taxCode: string) {
    return Object.values(transformedTaxRates(policy, transaction)).find((taxRate) => taxRate.code === taxCode)?.value;
}

function getTaxName(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, shouldFallbackToValue = false) {
    const defaultTaxCode = getDefaultTaxCode(policy, transaction);
    const taxRate = Object.values(transformedTaxRates(policy, transaction)).find((rate) => rate.code === (transaction?.taxCode || defaultTaxCode));

    if (shouldFallbackToValue && transaction?.taxValue !== undefined && taxRate?.value !== transaction?.taxValue) {
        return transaction?.taxValue;
    }

    return taxRate?.modifiedName;
}

Updated code:

import {
    getCommaSeparatedTagNameWithSanitizedColons,
    getCurrentTaxID,
    getDistanceRateCustomUnit,
    getDistanceRateCustomUnitRate,
    getPolicy,
    getTaxByID,
    isInstantSubmitEnabled,
} from '@libs/PolicyUtils';

function getTaxValue(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, taxCode: string) {
    const resolvedTaxCode = getCurrentTaxID(policy, taxCode) ?? taxCode;
    return Object.values(transformedTaxRates(policy, transaction)).find((taxRate) => taxRate.code === resolvedTaxCode)?.value;
}

function getTaxName(policy: OnyxEntry<Policy>, transaction: OnyxEntry<Transaction>, shouldFallbackToValue = false) {
    const defaultTaxCode = getDefaultTaxCode(policy, transaction);

    // transaction?.taxCode may be an empty string
    // eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
    const requestedTaxCode = transaction?.taxCode || defaultTaxCode;
    const resolvedTaxCode = getCurrentTaxID(policy, requestedTaxCode) ?? requestedTaxCode;
    const taxRate = Object.values(transformedTaxRates(policy, transaction)).find((rate) => rate.code === resolvedTaxCode);

    if (shouldFallbackToValue && transaction?.taxValue !== undefined && taxRate?.value !== transaction?.taxValue) {
        return transaction?.taxValue;
    }

    return taxRate?.modifiedName;
}

This keeps logic centralized, reuses an existing helper already designed for tax-code renames, and fixes the display + selection paths that depend on getTaxName / getTaxValue (including merge tax name rendering).

What alternative solutions did you explore? (Optional)

1. Add fallback matching by previousTaxCode directly inside getTaxName/getTaxValue. I did not choose this because we already have getCurrentTaxID() in PolicyUtils, and duplicating the remap logic in multiple places is harder to maintain.
2. Rewrite transformedTaxRates() to duplicate entries under old and new codes. I did not choose this because it can increase ambiguity (two keys for one rate) and makes default-label behavior more complex than resolving code once before lookup.