[$250] Web - Merge - Tax is shown on the merged expense of workspace has tax disabled

[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: undefined
Reproducible in staging?: Yes
Reproducible in production?: (https://github.com/Expensify/Expensify/issues/615476)
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

Precondition:

• Create a workspace with tax enabled
• Create a workspace with tax disabled

1. Open https://staging.new.expensify.com
2. Navigate to the workspace chat with tax enabled
3. Create an expense with a tax rate
4. Navigate to the workspace chat with tax disabled
5. Create an expense no tax
6. Click on this expense > More > Merge
7. Select the expense at step 3 > Continue
8. Select Amount, merchant, category, and report of the expense no tax > Continue
9. Observe Tax section of Confirm details page
10. Click Merge expenses

Expected Result:

Verify merging these expenses doesn't show tax section and doesn't merge tax rates

Actual Result:

Tax not shown on Select details page as expected but shown in Confirm detail page. After merging, tax is displayed with error on the merged expense of workspace has tax disabled.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7183654_1781713994654.Recording__2249.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077801178053484993
• Upwork Job ID: 2077801178053484993
• Last Price Increase: 2026-07-16

[MelvinBot]

Proposal

What is the root cause of that problem?

When merging expenses, the merge flow copies the source expense's tax fields onto the merged expense without ever checking whether the target/destination workspace has tax tracking enabled. There are two independent points where the destination policy's tax setting is ignored:

1. The merged data unconditionally inherits the source's tax. In getMergeableDataAndConflictFields, when the target expense has an empty tax value the code picks the source transaction and source policy, then getMergeFieldUpdatedValues writes taxCode, taxName, taxPolicyID, and taxAmount into the merged transaction — using the tax‑enabled source policy, never consulting the target policy.

2. The Confirm‑details page shows the Tax section whenever a tax name exists. MoneyRequestView.tsx:573 uses shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert. In the merge flow it bypasses the normal isTaxEnabled check entirely and shows tax purely because step 1 populated taxName.

This is also why the Select‑details page correctly hides tax but Confirm‑details does not: the Select page only renders conflict fields, and since the target's tax value is empty there's no conflict — tax is silently auto‑merged rather than being explicitly excluded. The bad taxCode/taxPolicyID then persists via the MergeTransaction API payload, producing the "tax rate was modified" error on the merged expense in the tax‑disabled workspace.

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

Fix at the merge‑data layer so the bad tax never enters mergeableData (this single fix covers all three symptoms — Confirm display, and the persisted payload):

• Thread the target transaction's policy into getMergeFields (it already receives targetTransactionPolicy at the call site).
• In getMergeFields, when isTaxTrackingEnabled(...) is false for the target policy, add taxValue to excludeFields — mirroring the existing distance‑request exclusion. With taxValue excluded, taxName/taxCode stay empty, so the Confirm page hides the section and the merge payload carries no tax.

Optionally also harden MoneyRequestView.tsx:573 so the merge branch still honors isTaxEnabled, as defense in depth.

Investigation details & related issues

• Data flow traced: getMergeableDataAndConflictFields → getMergeFieldUpdatedValues (taxValue branch) → buildMergedTransactionData → Confirm page MoneyRequestView + mergeTransactionRequest API call.
• Confirm the exact isTaxTrackingEnabled argument order when calling it from MergeTransactionUtils.ts (see its usage at MoneyRequestView.tsx:571).
• Possibly related tax/merge issues (not necessarily duplicates): [$250] Missing Tax rate section when merging expenses when expenses are created without Tax first #83098 (missing Tax rate section when merging expenses created without tax first) and [$250] Expense - Tax field is blank after merging with expense with invalid tax rate #83082 (tax field blank after merging with an invalid tax rate).

What alternative solutions did you explore? (Optional)

Filtering at the UI layer only (MoneyRequestView.tsx) would hide the Tax section but still persist a taxCode to the tax‑disabled expense, leaving the underlying data (and potential violation) intact — so the merge‑data fix is preferred as the root‑cause fix.

---

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When merging expenses, the "Confirm details" page displays and submits tax information taken from the source expense (the one with tax enabled), even when the user selects a target report belonging to a workspace that has tax disabled. The merge confirmation logic doesn't check whether the selected report's policy has tax enabled before displaying/passing tax data.

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

I'd look at the merge expense confirmation page (likely in src/pages/MergeExpensesPage or similar) where the confirm details are assembled. The fix should check if the policy of the selected report has tax disabled, and if so, strip the tax fields before rendering and before submitting.

// In the confirm details assembly / IOU merge action
+ const isPolicyTaxEnabled = PolicyUtils.isTaxTrackingEnabled(policy);

  const confirmDetails = {
    amount: selectedAmount,
    merchant: selectedMerchant,
    category: selectedCategory,
-   taxRate: selectedTaxRate,
-   taxAmount: selectedTaxAmount,
+   taxRate: isPolicyTaxEnabled ? selectedTaxRate : undefined,
+   taxAmount: isPolicyTaxEnabled ? selectedTaxAmount : undefined,
  };

Additionally, the Confirm details UI component should conditionally hide the Tax section row when !isPolicyTaxEnabled, mirroring the behavior already working on the "Select details" page.

What alternative solutions did you explore?

Alternatively, one could clear the tax selection at the point when the user picks the target report (step 8), so tax never propagates forward. But I think filtering at the confirm/submit layer is more robust since it covers cases where report selection might be pre-populated.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 17:04:11 UTC.

Proposal

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

When merging a tax-enabled expense (source) into an expense that lives in a workspace with tax disabled (target), the tax rate is silently carried over. The Select details page correctly hides the tax field, but the Confirm details page shows a tax section, and after merging the resulting expense in the tax-disabled workspace ends up with a tax value plus a violation/error.

What is the root cause of that problem?

The merge flow never checks whether the target (destination) workspace actually supports tax tracking.

Field values are combined in getMergeableDataAndConflictFields. It iterates over the fields returned by getMergeFields, which only excludes taxValue for distance requests:

function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
    const excludeFields: MergeFieldKey[] = [];

    // Distance request's amount/currency/receipt depend on merchant selection
    // Distance request's tax depends on distance rate
    if (isDistanceRequest(targetTransaction)) {
        excludeFields.push('amount', 'taxValue');
    }

    return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
}

In this repro the target (tax-disabled) transaction has an empty taxValue, so the "one side is empty" branch auto-selects the source's value and pulls in taxCode/taxName/taxAmount/taxPolicyID from the tax-enabled source policy:

App/src/libs/MergeTransactionUtils.ts

Lines 307 to 324 in c88326a

	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
	const updatedValues = getMergeFieldUpdatedValues({
	transaction: selectedTransaction,
	field,
	fieldValue: selectedFieldValue as MergeTransaction[typeof field],
	getCurrencyDecimals,
	mergeTransaction: mergeableData as MergeTransaction,
	searchReports,
	policy: selectedPolicy,
	});
	Object.assign(mergeableData, updatedValues);
	} else {
	conflictFields.push(field);
	}
	}

Because the value isn't a conflict, no tax row shows on the Select details page — but the tax data is now baked into the merge transaction. It then surfaces on the Confirm page, where MoneyRequestView shows the tax section for merges whenever taxName is present, ignoring the target policy:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 571 to 573 in c88326a

	const isTaxEnabled = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode && !isTimeRequest && !isPerDiemRequest;
	const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

and the same taxCode/taxPolicyID are sent to the backend in mergeTransactionRequest, producing the tax + error on the merged expense.

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

Treat the target workspace's tax setting the same way we already treat distance requests: if the destination policy has tax tracking disabled, exclude taxValue from the merge entirely. This is the single upstream point that feeds both pages and the API request, so fixing it here means tax is never auto-merged, never shown on either page, and never sent to the backend.

Pass the target policy into getMergeFields and drop taxValue when tax tracking is off:

function getMergeFields(targetTransaction: OnyxEntry<Transaction>, targetTransactionPolicy?: OnyxEntry<Policy>) {
    const excludeFields: MergeFieldKey[] = [];

    // Distance request's amount/currency/receipt depend on merchant selection
    // Distance request's tax depends on distance rate
    if (isDistanceRequest(targetTransaction)) {
        excludeFields.push('amount', 'taxValue');
    }

    // The destination workspace doesn't support tax, so tax must not be merged/shown/sent
    const isTaxEnabled = isTaxTrackingEnabled(true, targetTransactionPolicy, isDistanceRequest(targetTransaction), isPerDiemRequest(targetTransaction), isTimeRequest(targetTransaction));
    if (!isTaxEnabled && !excludeFields.includes('taxValue')) {
        excludeFields.push('taxValue');
    }

    return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
}

Then forward the policy that getMergeableDataAndConflictFields already receives:

for (const field of getMergeFields(targetTransaction, targetTransactionPolicy)) {

isTaxTrackingEnabled is imported from PolicyUtils. With taxValue excluded, the "empty side" branch never copies the source's tax fields into the merge transaction, so buildMergedTransactionData and the API params carry no tax, and MoneyRequestView's merge branch (!!transaction?.taxName) is naturally false — no extra UI change needed.

What alternative solutions did you explore? (Optional)

• Fix only the display: change the merge branch at MoneyRequestView.tsx#L573 to also check the target policy's isTaxTrackingEnabled. This hides the tax section on the Confirm page but leaves the tax data merged and still sends taxCode/taxPolicyID to the backend, so the merged expense would still get tax + error. Rejected as it treats the symptom, not the root cause.
• Strip tax in mergeTransactionRequest/buildMergedTransactionData when the target policy has tax disabled. This works for persistence/display but requires the guard in two separate places and still lets tax briefly live in the merge-transaction Onyx state. Excluding it once in getMergeFields is the minimal, single-source fix consistent with the existing distance-request exclusion.

[MobileMage]

Proposal

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

When merging an expense that has no tax (on a workspace with tax disabled) with an expense that has a tax rate (from a workspace with tax enabled), the tax section is correctly absent on the Select details page but shows up on the Confirm details page. After confirming, the merged expense on the tax-disabled workspace ends up with the foreign tax rate and displays it with an error.

What is the root cause of that problem?

When the merge details step is prepared, getMergeableDataAndConflictFields in src/libs/MergeTransactionUtils.ts iterates over getMergeFields(targetTransaction) (line 235), and that list always contains taxValue for non-distance expenses — it never checks whether the target expense's workspace has tax tracking enabled (getMergeFields, lines 176-186, only excludes taxValue for distance requests). In this repro the target transaction is the no-tax expense on the tax-disabled workspace, so its taxValue is empty while the source's is not. The field therefore falls into the generic auto-resolution branch, which silently adopts the non-empty side instead of flagging a conflict:

App/src/libs/MergeTransactionUtils.ts

Lines 307 to 311 in b570d0e

	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
	const updatedValues = getMergeFieldUpdatedValues({

That branch calls getMergeFieldUpdatedValues with the source transaction and source policy, whose field === 'taxValue' handler (lines 697-704) writes taxValue, taxCode, taxName (resolved against the source policy via getTaxName), taxPolicyID and taxAmount into the mergeable data, which setMergeTransactionKey persists to the MERGE_TRANSACTION Onyx key. Because the field was auto-resolved rather than pushed into conflictFields, the Select details page (DetailsReviewPage) never renders a tax card — which is exactly why that page "behaves correctly" while the wrong tax data is already sitting in Onyx.

On the Confirm page, ConfirmationPage builds the preview via buildMergedTransactionData (lines 397-400 copy taxValue/taxAmount/taxCode/taxName from the merge transaction) and renders it in MoneyRequestView with mergeTransactionID set. MoneyRequestView normally gates the tax row behind isTaxTrackingEnabled(...), but in merge mode it bypasses the policy check entirely and keys off taxName alone, so the row appears even though the tax-disabled targetTransactionPolicy is what's passed as expensePolicy:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 571 to 573 in b570d0e

	const isTaxEnabled = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode && !isTimeRequest && !isPerDiemRequest;
	const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

Finally, mergeTransactionRequest in src/libs/actions/MergeTransaction.ts sends taxCode: mergeTransaction.taxCode and taxPolicyID: mergeTransaction.taxPolicyID to the API (lines 413-414) and applies taxCode/taxAmount optimistically through filteredTransactionChanges (they're in DERIVED_MERGE_FIELDS). The merged expense on the tax-disabled workspace now carries a tax code that belongs to the source policy, so on the expense view shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode fires and the tax is displayed with an error, matching the reported result.

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

Tax should never be part of the merge when the kept (target) expense's workspace doesn't track tax. getMergeFields is only called from getMergeableDataAndConflictFields, which already receives targetTransactionPolicy from both of its callers (DetailsReviewPage and the identical-transactions shortcut in setupMergeTransactionDataAndNavigate), so the fix is fully local: pass the target policy into getMergeFields and exclude taxValue when tax tracking is disabled, using the existing isTaxTrackingEnabled helper from PolicyUtils — the same gate MoneyRequestView uses outside the merge flow.

App/src/libs/MergeTransactionUtils.ts

Lines 176 to 180 in b570d0e

	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
	const excludeFields: MergeFieldKey[] = [];
	// Distance request's amount/currency/receipt depend on merchant selection
	// Distance request's tax depends on distance rate

function getMergeFields(targetTransaction: OnyxEntry<Transaction>, targetTransactionPolicy?: OnyxEntry<Policy>) {
    const excludeFields: MergeFieldKey[] = [];
    if (isDistanceRequest(targetTransaction)) {
        excludeFields.push('amount', 'taxValue');
    } else if (!isTaxTrackingEnabled(true, targetTransactionPolicy, false)) {
        excludeFields.push('taxValue');
    }

and update the call site at line 235 to getMergeFields(targetTransaction, targetTransactionPolicy). Passing true for the first parameter is safe because areTransactionsEligibleForMerge already rejects transactions on IOU reports, so a mergeable target is always on a policy expense chat or unreported — the same condition MoneyRequestView computes as isPolicyExpenseChat || isExpenseUnreported. With taxValue excluded, no tax keys are ever written to the merge transaction, which fixes every downstream symptom at once: buildMergedTransactionData carries no taxName so the Confirm page's shouldShowTax is false and the section disappears, mergeTransactionRequest sends taxCode/taxPolicyID as undefined so no tax rate is merged server-side, and the optimistic filteredTransactionChanges contains no tax fields. It mirrors the existing precedent in the same function (excluding taxValue for distance requests) and changes nothing for merges where the target workspace has tax enabled — the field keeps flowing exactly as today, including the conflict card when both sides have different rates and the taxAmount recalculation when an amount is selected.

What alternative solutions did you explore? (Optional)

Gating only the display in MoneyRequestView (shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName && isTaxEnabled : ...) hides the row on the Confirm page but mergeTransactionRequest would still send the source policy's taxCode/taxPolicyID, reproducing the post-merge error, so it treats the symptom rather than the data. We also considered recomputing the tax fields when the user resolves the reportID conflict so tax would follow the destination report's policy, but tax codes are policy-scoped (a source-policy taxCode is meaningless on another policy), and the expected behavior in this issue is simply that tax is not merged when the kept expense's workspace has tax disabled, so the targeted getMergeFields exclusion is the minimal correct fix.

[abbasifaizan70]

Proposal

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

When merging two expenses where the target expense belongs to a workspace with tax disabled and the source expense has a tax rate, the "Select details" page correctly hides the tax conflict, but the tax rate still silently carries over into the merge. The Confirm details page then shows a Tax section (which it shouldn't, since the target workspace has tax disabled), and after merging, the resulting expense ends up with a tax rate and an error/violation on a workspace that doesn't support tax.

What is the root cause of that problem?

getMergeFields decides which fields are eligible to be merged/auto-resolved between the two transactions. It only excludes taxValue for distance requests — it never checks whether the target transaction's workspace actually has tax tracking enabled:

App/src/libs/MergeTransactionUtils.ts

Lines 176 to 186 in 59a6998

	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
	const excludeFields: MergeFieldKey[] = [];
	// Distance request's amount/currency/receipt depend on merchant selection
	// Distance request's tax depends on distance rate
	if (isDistanceRequest(targetTransaction)) {
	excludeFields.push('amount', 'taxValue');
	}
	return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
	}

Because the target (tax-disabled) expense has an empty taxValue, the generic empty-value fallback in getMergeableDataAndConflictFields auto-selects the source (tax-enabled) expense's tax value without ever flagging it as a conflict — that's why nothing appears on the "Select details" page:

App/src/libs/MergeTransactionUtils.ts

Lines 307 to 320 in 59a6998

	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
	const updatedValues = getMergeFieldUpdatedValues({
	transaction: selectedTransaction,
	field,
	fieldValue: selectedFieldValue as MergeTransaction[typeof field],
	getCurrencyDecimals,
	mergeTransaction: mergeableData as MergeTransaction,
	searchReports,
	policy: selectedPolicy,
	});
	Object.assign(mergeableData, updatedValues);

That auto-resolved taxValue causes getMergeFieldUpdatedValues to populate taxCode/taxName/taxAmount on the merge transaction (using the source's tax-enabled policy), even though the target policy has tax disabled:

App/src/libs/MergeTransactionUtils.ts

Lines 697 to 704 in 59a6998

	if (field === 'taxValue') {
	updatedValues.taxCode = transaction?.taxCode;
	updatedValues.taxName = getTaxName(policy, transaction) ?? transaction?.taxValue ?? '';
	updatedValues.taxPolicyID = policy?.id;
	if (mergeTransaction?.amount) {
	updatedValues.taxAmount = convertToBackendAmount(calculateTaxAmount(transaction?.taxValue, mergeTransaction.amount, getCurrencyDecimals(getCurrency(transaction))));
	}
	}

buildMergedTransactionData then copies those tax fields straight onto the transaction shown on the Confirm page:

App/src/libs/MergeTransactionUtils.ts

Lines 397 to 400 in 59a6998

	taxValue: mergeTransaction.taxValue,
	taxAmount: mergeTransaction.taxAmount,
	taxCode: mergeTransaction.taxCode,
	taxName: mergeTransaction.taxName,

Finally, MoneyRequestView decides whether to render the Tax row for a merge transaction purely by checking if taxName is truthy, completely bypassing the workspace's isTaxEnabled check that's used for every other case:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 573 in 59a6998

const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

So the Tax section renders on the Confirm page, and the merge request is sent to the backend carrying tax data for a transaction whose policy doesn't support tax — producing the post-merge tax/error.

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

Exclude taxValue from the mergeable fields whenever the target transaction's policy doesn't have tax tracking enabled, the same way it's already excluded for distance requests. This stops the tax rate from ever being auto-selected onto the merge transaction, which fixes both the Confirm page display and the post-merge error.

App/src/libs/MergeTransactionUtils.ts

Lines 176 to 186 in 59a6998

	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
	const excludeFields: MergeFieldKey[] = [];
	// Distance request's amount/currency/receipt depend on merchant selection
	// Distance request's tax depends on distance rate
	if (isDistanceRequest(targetTransaction)) {
	excludeFields.push('amount', 'taxValue');
	}
	return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
	}

function getMergeFields(targetTransaction: OnyxEntry<Transaction>, targetTransactionPolicy?: OnyxEntry<Policy>) {
    const excludeFields: MergeFieldKey[] = [];
    const isTargetDistanceRequest = isDistanceRequest(targetTransaction);

    // Distance request's amount/currency/receipt depend on merchant selection
    // Distance request's tax depends on distance rate
    if (isTargetDistanceRequest) {
        excludeFields.push('amount', 'taxValue');
    }

    // Don't let a tax rate merge onto a transaction whose workspace doesn't track tax
    if (!isTargetDistanceRequest && !isTaxTrackingEnabled(true, targetTransactionPolicy, isTargetDistanceRequest)) {
        excludeFields.push('taxValue');
    }

    return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
}

Pass the target policy through at the only call site:

App/src/libs/MergeTransactionUtils.ts

Line 235 in 59a6998

for (const field of getMergeFields(targetTransaction)) {

    for (const field of getMergeFields(targetTransaction, targetTransactionPolicy)) {

Import isTaxTrackingEnabled:

App/src/libs/MergeTransactionUtils.ts

Line 21 in 59a6998

import {getCommaSeparatedTagNameWithSanitizedColons} from './PolicyUtils';

import {getCommaSeparatedTagNameWithSanitizedColons, isTaxTrackingEnabled} from './PolicyUtils';

[aswin-s]

Proposal

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

On Web, when a user merges two expenses where the source (selected) transaction belongs to a workspace with tax enabled and the target (initial) transaction belongs to a workspace with tax disabled, the Confirm details page shows a Tax section and the resulting merged expense displays a tax value (with an error), even though the target workspace has tax tracking off. Expected: the merged expense on a tax-disabled workspace should carry no tax and the Tax section should not appear.

What is the root cause of that problem?

In src/libs/MergeTransactionUtils.ts, getMergeFields (line 176) only excludes taxValue for distance requests — it does not consider whether the target transaction's policy has tax tracking enabled. Because taxValue remains in MERGE_FIELDS (line 49), getMergeableDataAndConflictFields (line 235) iterates over it; the target's tax fields are empty and the source's are populated, so the "one side empty" branch at lines 307–320 auto-selects the source transaction and calls getMergeFieldUpdatedValues for field === 'taxValue' (line 697), copying taxCode/taxName/taxAmount/taxPolicyID from the tax‑enabled source into mergeableData. Those fields then flow through buildMergedTransactionData (lines 397–400) into the merged transaction that lives on the tax‑disabled target policy, producing the visible tax row on Confirm details and the tax‑with‑error on the final merged expense.

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

1. In src/libs/MergeTransactionUtils.ts at getMergeFields (lines 176–186), also exclude taxValue when the target transaction's policy does not have tax tracking enabled. Thread targetTransactionPolicy (already available at the call site in getMergeableDataAndConflictFields, line 220) into getMergeFields and use isTaxTrackingEnabled(...) from PolicyUtils to decide.
2. In getMergeableDataAndConflictFields (line 235), pass targetTransactionPolicy to getMergeFields(targetTransaction, targetTransactionPolicy) so tax is dropped from the merge field set entirely when the destination workspace disallows tax.
3. As a defense-in-depth guard, in buildMergedTransactionData (lines 364–402), when the destination policy (derivable from mergeTransaction.reportID / target transaction) has tax tracking disabled, omit taxValue, taxAmount, taxCode, and taxName from the returned object (and clear any that exist on targetTransaction) so the merged transaction never carries stale tax.
4. Ensure the Confirm details page (src/pages/TransactionMerge/ConfirmationPage.tsx, line 75) receives a merged transaction without tax fields when tax is off on the destination policy, so MoneyRequestView's shouldShowTax (which now honors transaction?.taxName, per PR [Merge] Merging tax rates #71244) does not force the Tax row on.
5. Add a unit test in tests/unit/MergeTransactionUtilsTest covering: target on tax‑disabled policy + source on tax‑enabled policy → resulting mergeableData contains no taxValue/taxCode/taxName/taxAmount, and buildMergedTransactionData output has no tax fields.

What alternative solutions did you explore? (Optional)

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 17:22:45 UTC.

Proposal

What is the root cause of that problem?

This is a destination-policy synchronization problem in the merge state, not just a confirmation-page display problem.

taxValue is processed before reportID because it appears earlier in MERGE_FIELDS. Field order

When one expense has tax and the other does not, the generic empty-value logic automatically selects the taxed expense:

const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;

It then calls getMergeFieldUpdatedValues(), which derives and stores taxValue, taxCode, taxName, taxPolicyID, and taxAmount. Since this is automatic, taxValue is not added to conflictFields, explaining why no Tax section appears on Select details. Auto-selection logic, derived tax fields

Later, selecting the report from the tax-disabled workspace updates only reportID and reportName. It does not invalidate the tax fields that were derived earlier:

if (field === 'reportID') {
    // Only reportName is derived.
    updatedValues.reportName = ...;
}

Report-selection logic

Consequently:

1. buildMergedTransactionData() unconditionally copies the stale tax fields into the confirmation transaction. Preview construction
2. mergeTransactionRequest() sends the stale taxCode and taxPolicyID to the backend. Merge API parameters
3. The violations logic correctly treats tax data in a tax-disabled policy as out of policy, which produces the reported error. Violation logic

History confirming the RCA

Tax merging was introduced in 5957be5. A temporary guard was later added in 2ec38f3 specifically to skip tax merging whenever either workspace had taxes disabled:

if (field === 'taxValue' && (!targetPolicy.tax.trackingEnabled || !sourcePolicy.tax.trackingEnabled)) {
    continue;
}

That guard was subsequently removed by PR #84769. That PR intentionally changed the behavior to retain cross-workspace tax, add a taxOutOfPolicy violation, and ask the user to delete the tax after merging. Its documented test expected tax to remain in the tax-disabled workspace.

The present issue changes that expected merge behavior: the merged expense should immediately conform to the selected destination workspace and should not retain tax. Therefore, restoring the old broad guard would be insufficient because it looks at both source policies rather than the final selected destination and could regress merging into a tax-enabled workspace.

The existing move flow is also intentionally designed to retain tax and let the user resolve it. The fix should therefore remain local to expense merging rather than changing shared MoneyRequestView or violation behavior.

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

Make the selected destination policy authoritative for tax data at two points:

1. When the user selects reportID, clear the merge transaction’s tax fields if that report’s policy does not support taxes.
2. Before building the preview and submitting the request, normalize the tax fields against the final destination policy again. This second check prevents selection-order regressions—for example, selecting the report first and then selecting a taxed distance rate or tax value.

Use the existing isPolicyTaxEnabled() helper instead of checking only policy.tax.trackingEnabled, because accounting integrations can also enable tax support. Tax-enablement helper

A small illustrative change in getMergeFieldUpdatedValues() would be:

 if (field === 'reportID') {
     updatedValues.reportName = reportName.length ? reportName : null;
+
+    if (policy && !isPolicyTaxEnabled(policy)) {
+        updatedValues.taxCode = '';
+        updatedValues.taxValue = '';
+        updatedValues.taxAmount = 0;
+        updatedValues.taxName = '';
+    }
 }

Keep the existing taxPolicyID rather than erasing it. The history explicitly documents that the backend needs this value to remove tax when the selected rate has no tax tracking. Relevant rationale

To protect against field-selection order, centralize the same rule:

+function getMergeTaxDataForDestination(mergeTransaction, destinationPolicy) {
+    if (!destinationPolicy || isPolicyTaxEnabled(destinationPolicy)) {
+        return mergeTransaction;
+    }
+
+    return {
+        ...mergeTransaction,
+        taxCode: '',
+        taxValue: '',
+        taxAmount: 0,
+        taxName: '',
+    };
+}

Use the normalized merge transaction for both buildMergedTransactionData() and mergeTransactionRequest(). Do not merely omit taxCode from the API request: if the surviving target transaction already has tax, omission can preserve it. Sending an empty taxCode explicitly requests removal.

The destination policy must be resolved from mergeTransaction.reportID, not assumed to be targetTransactionPolicy. This matters when the merge is initiated from the taxed expense but the user selects the source expense’s tax-disabled report.

Regression coverage

Add unit tests covering:

• Taxed target + untaxed source → tax-disabled destination clears all tax fields.
• Untaxed target + taxed source → tax-disabled destination clears all tax fields.
• Either direction → tax-enabled destination preserves the selected tax and recalculated amount.
• Selecting the report before selecting another field cannot reintroduce tax at confirmation/submission.
• Accounting-synced policies recognized by isPolicyTaxEnabled() preserve tax.
• Distance expenses continue deriving tax from the selected distance rate when the destination supports taxes.
• Unreported expenses retain their current behavior.
• The general move flow and existing invalid-tax alert remain unchanged because this normalization is limited to the merge flow.

What alternative solutions did you explore? (Optional)

Restoring the old “skip tax if either policy has taxes disabled” guard would fix this reproduction, but it would regress the opposite case: merging into a tax-enabled destination must still preserve the valid tax.

Hiding tax only in MoneyRequestView would fix the confirmation UI but still submit stale tax data.

Changing the shared violation or move behavior would conflict with the intentional behavior introduced by PR #84769. Destination-aware normalization limited to the merge flow fixes this issue without changing how already-existing or moved expenses with invalid tax are handled.

[ahmdshrif]

Proposal

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

Merging an expense that has a tax rate (from a tax-enabled workspace) with an expense on a tax-disabled workspace shows the Tax row on the Confirm details page, and after merging, the kept expense carries the foreign tax rate with an error.

What is the root cause of that problem?

Structural cause: the merge flow treats tax as generic transaction content, when it is policy-scoped configuration. The target expense's tax is empty because its workspace has tax tracking disabled — not because data is missing — but the merge logic never consults the policy, so it can't tell the difference. Tax merging was added intentionally in PR #83587 ("[Merge] Merge tax rates v2") but only the tax-enabled case was handled — this is a missing case, not a regression to revert.

The chain:

1. getMergeFields() picks merge fields purely from transaction type — it excludes taxValue only for distance requests, never checking the policy:
   

   App/src/libs/MergeTransactionUtils.ts

   Lines 176 to 186 in b570d0e

   	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
   	const excludeFields: MergeFieldKey[] = [];
   	// Distance request's amount/currency/receipt depend on merchant selection
   	// Distance request's tax depends on distance rate
   	if (isDistanceRequest(targetTransaction)) {
   	excludeFields.push('amount', 'taxValue');
   	}
   	return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
   	}

2. getMergeableDataAndConflictFields() therefore iterates taxValue like any content field. The target's taxValue is undefined (tax-disabled workspace), so the generic "one side empty → auto-inherit the other" rule fires with no conflict raised:
   

   App/src/libs/MergeTransactionUtils.ts

   Lines 307 to 320 in b570d0e

   	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
   	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
   	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
   	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
   	const updatedValues = getMergeFieldUpdatedValues({
   	transaction: selectedTransaction,
   	field,
   	fieldValue: selectedFieldValue as MergeTransaction[typeof field],
   	getCurrencyDecimals,
   	mergeTransaction: mergeableData as MergeTransaction,
   	searchReports,
   	policy: selectedPolicy,
   	});
   	Object.assign(mergeableData, updatedValues);

3. getMergeFieldUpdatedValues() stamps taxCode, taxName, and taxPolicyID — all resolved from the source workspace's policy — into the merge transaction (and taxAmount is recomputed from the source's rate once the amount is picked):
   

   App/src/libs/MergeTransactionUtils.ts

   Lines 697 to 704 in b570d0e

   	if (field === 'taxValue') {
   	updatedValues.taxCode = transaction?.taxCode;
   	updatedValues.taxName = getTaxName(policy, transaction) ?? transaction?.taxValue ?? '';
   	updatedValues.taxPolicyID = policy?.id;
   	if (mergeTransaction?.amount) {
   	updatedValues.taxAmount = convertToBackendAmount(calculateTaxAmount(transaction?.taxValue, mergeTransaction.amount, getCurrencyDecimals(getCurrency(transaction))));
   	}
   	}

This explains every symptom detail:

• Tax NOT shown on Select details page: taxValue never entered conflictFields (auto-inherited in step 2), so the review page shows no tax row — looks right by accident.
• Tax shown on Confirm page: buildMergedTransactionData() copies the tax fields onto the preview (

  App/src/libs/MergeTransactionUtils.ts

  Lines 397 to 400 in b570d0e

  	taxValue: mergeTransaction.taxValue,
  	taxAmount: mergeTransaction.taxAmount,
  	taxCode: mergeTransaction.taxCode,
  	taxName: mergeTransaction.taxName,

  ), and MoneyRequestView in merge mode shows the row iff !!transaction?.taxName, bypassing the policy check:

  App/src/components/ReportActionItem/MoneyRequestView.tsx

  Lines 571 to 573 in b570d0e

  	const isTaxEnabled = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
  	const shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode && !isTimeRequest && !isPerDiemRequest;
  	const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

• Tax with error after merge: the request sends the foreign taxCode + taxPolicyID (

  App/src/libs/actions/MergeTransaction.ts

  Lines 413 to 414 in b570d0e

  	taxCode: mergeTransaction.taxCode,
  	taxPolicyID: mergeTransaction.taxPolicyID,

  ) and the optimistic update writes taxValue/taxCode/taxAmount onto the kept transaction via the DERIVED_MERGE_FIELDS filter (

  App/src/libs/actions/MergeTransaction.ts

  Lines 256 to 267 in b570d0e

  	const targetTransactionDetails = getTransactionDetails(targetTransaction);
  	const filteredTransactionChanges = Object.fromEntries(
  	Object.entries(mergeTransaction).filter(([key, mergeValue]) => {
  	if (!(DERIVED_MERGE_FIELDS as readonly string[]).includes(key)) {
  	return false;
  	}
  	const targetValue = getMergeFieldValue(targetTransactionDetails, targetTransaction, key as MergeFieldKey);
  	return !deepEqual(mergeValue, targetValue);
  	}),
  	);

  ). The kept expense now holds a tax code its policy doesn't have, tripping the tax-disabled alert (MoneyRequestView.tsx#L572).

All three merge entry paths run through this same util and already pass targetTransactionPolicy: the identical-transactions skip-to-confirm path (

App/src/libs/actions/MergeTransaction.ts

Lines 110 to 118 in b570d0e

	const {conflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	searchReports,
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);

), DetailsReviewPage (

App/src/pages/TransactionMerge/DetailsReviewPage.tsx

Lines 69 to 77 in b570d0e

	const {conflictFields: detectedConflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	[targetTransactionReport, sourceTransactionReport],
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);

), and ReceiptReviewPage (

App/src/pages/TransactionMerge/ReceiptReviewPage.tsx

Lines 58 to 66 in b570d0e

	const {conflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	[],
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);

).

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

Make getMergeFields() policy-aware: exclude taxValue when the target workspace doesn't track tax, forwarding the targetTransactionPolicy the caller already holds (MergeTransactionUtils.ts#L235):

function getMergeFields(targetTransaction: OnyxEntry<Transaction>, targetTransactionPolicy?: OnyxEntry<Policy>) {
    const excludeFields: MergeFieldKey[] = [];
    if (isDistanceRequest(targetTransaction)) {
        excludeFields.push('amount', 'taxValue');
    }
    // Tax is policy-scoped: don't merge or surface it when the kept expense's workspace has taxes disabled
    if (!targetTransactionPolicy?.tax?.trackingEnabled) {
        excludeFields.push('taxValue');
    }
    return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
}

(policy?.tax?.trackingEnabled is the same predicate isTaxTrackingEnabled uses:

App/src/libs/PolicyUtils.ts

Lines 1423 to 1439 in b570d0e

	function isTaxTrackingEnabled(
	isPolicyExpenseChatOrUnreportedExpense: boolean,
	policy: OnyxEntry<Policy>,
	isDistanceRequest: boolean,
	isPerDiemRequest = false,
	isTimeRequest = false,
	): boolean {
	if (isPerDiemRequest || isTimeRequest) {
	return false;
	}
	const distanceUnit = getDistanceRateCustomUnit(policy);
	const customUnitID = distanceUnit?.customUnitID ?? CONST.DEFAULT_NUMBER_ID;
	const isPolicyTaxTrackingEnabled = isPolicyExpenseChatOrUnreportedExpense && policy?.tax?.trackingEnabled;
	const isTaxEnabledForDistance = isPolicyTaxTrackingEnabled && !!customUnitID && policy?.customUnits?.[customUnitID]?.attributes?.taxEnabled;
	return !!(isDistanceRequest ? isTaxEnabledForDistance : isPolicyTaxTrackingEnabled);
	}

.)

With the field excluded, the merge transaction never contains taxValue/taxCode/taxName/taxAmount/taxPolicyID, so every downstream consumer is fixed at the single convergence point: the Confirm page shows no Tax row (taxName is undefined at the #L573 gate), the API request omits taxCode, and the optimistic filter has nothing to write. Excluding the field (not just skipping the empty-inherit branch) also covers the stale-tax edge: a target expense still carrying an old taxValue from before taxes were disabled would otherwise surface a bogus tax conflict row. Regression safety in one sentence: tax-enabled workspaces and distance merges take exactly today's code paths (trackingEnabled true → no exclusion; distance already excluded), and getMergeFields is module-private with this single caller.

Why the obvious spot fix does not work: gating only the Confirm-page display (adding isTaxEnabled to MoneyRequestView.tsx#L573) hides the row, but the request still sends the source's taxCode/taxPolicyID (actions/MergeTransaction.ts#L413-L414) and the optimistic update still stamps the tax fields (#L256-L267) — the merged expense still ends up taxed with an error, failing the expectation that merging "doesn't merge tax rates".

What alternative solutions did you explore? (Optional)

1. Display-only gate in MoneyRequestView — incomplete, as proven above: the data still merges.
2. Special-case taxValue inside the empty-inherit branch (#L307) — fixes this repro but misses the stale-taxValue conflict path; field-level exclusion covers both with less code.
3. Destination-aware tax recompute on report selection — if the user moves the merged expense to the source's tax-enabled report, tax could legitimately follow; that needs changes in three places (report-selection handler, Confirm display, request path). The expected behavior here is only that a tax-disabled kept expense doesn't inherit tax, which the minimal one-point fix delivers; this could be a follow-up.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The merge flow decides which fields participate in the merge purely from the target transaction's shape, never from the target policy's tax settings. taxValue is a merge field:

App/src/libs/MergeTransactionUtils.ts

Lines 48 to 51 in b570d0e

	// Define the specific merge fields we want to handle
	const MERGE_FIELDS = ['amount', 'merchant', 'created', 'category', 'tag', 'description', 'taxValue', 'reimbursable', 'billable', 'attendees', 'reportID'] as const;
	// Some fields are dependant on others. We need to automatically derive the correct field values depending on user selection.
	const DERIVED_MERGE_FIELDS = [...MERGE_FIELDS, 'taxCode', 'taxAmount'] as const;

and getMergeFields only ever drops it for distance requests:

App/src/libs/MergeTransactionUtils.ts

Lines 176 to 186 in b570d0e

	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
	const excludeFields: MergeFieldKey[] = [];
	// Distance request's amount/currency/receipt depend on merchant selection
	// Distance request's tax depends on distance rate
	if (isDistanceRequest(targetTransaction)) {
	excludeFields.push('amount', 'taxValue');
	}
	return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
	}

In the reported steps the merge is started from the expense on the tax-disabled workspace, and that expense stays the target — selectTargetAndSourceTransactionsForMerge only swaps target/source for card or split expenses:

App/src/libs/MergeTransactionUtils.ts

Lines 477 to 495 in b570d0e

	function selectTargetAndSourceTransactionsForMerge(
	targetTransaction: OnyxEntry<Transaction>,
	sourceTransaction: OnyxEntry<Transaction>,
	targetTransactionPolicy?: Policy,
	sourceTransactionPolicy?: Policy,
	) {
	// If target transaction is a card or split expense, always preserve the target transaction
	// Card takes precedence over split expense
	if (isFromCreditCardImport(sourceTransaction) || (isExpenseSplit(sourceTransaction) && !isFromCreditCardImport(targetTransaction))) {
	return {
	targetTransaction: sourceTransaction,
	sourceTransaction: targetTransaction,
	targetTransactionPolicy: sourceTransactionPolicy,
	sourceTransactionPolicy: targetTransactionPolicy,
	};
	}
	return {targetTransaction, sourceTransaction, targetTransactionPolicy, sourceTransactionPolicy};
	}

So the target (tax disabled, no tax) and the source (tax enabled, has a tax rate) both go through the merge loop with taxValue still in the field list:

App/src/libs/MergeTransactionUtils.ts

Line 235 in b570d0e

for (const field of getMergeFields(targetTransaction)) {

Because the target's taxValue is empty, taxValue never becomes a conflict field. A field that only one expense has is treated as mergeable data and is silently auto-filled from the other expense — using the source transaction's policy:

App/src/libs/MergeTransactionUtils.ts

Lines 307 to 320 in b570d0e

	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
	const updatedValues = getMergeFieldUpdatedValues({
	transaction: selectedTransaction,
	field,
	fieldValue: selectedFieldValue as MergeTransaction[typeof field],
	getCurrencyDecimals,
	mergeTransaction: mergeableData as MergeTransaction,
	searchReports,
	policy: selectedPolicy,
	});
	Object.assign(mergeableData, updatedValues);

which writes the source's taxCode, taxName, taxAmount, and — critically — a taxPolicyID pointing at the tax-enabled workspace:

App/src/libs/MergeTransactionUtils.ts

Lines 697 to 704 in b570d0e

	if (field === 'taxValue') {
	updatedValues.taxCode = transaction?.taxCode;
	updatedValues.taxName = getTaxName(policy, transaction) ?? transaction?.taxValue ?? '';
	updatedValues.taxPolicyID = policy?.id;
	if (mergeTransaction?.amount) {
	updatedValues.taxAmount = convertToBackendAmount(calculateTaxAmount(transaction?.taxValue, mergeTransaction.amount, getCurrencyDecimals(getCurrency(transaction))));
	}
	}

This single fact explains both halves of the report:

Why Tax is correctly absent on the Select details page. That page renders only conflictFields; the mergeableData is written straight into the merge transaction without ever being shown:

App/src/pages/TransactionMerge/DetailsReviewPage.tsx

Lines 69 to 80 in b570d0e

	const {conflictFields: detectedConflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	[targetTransactionReport, sourceTransactionReport],
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);
	setMergeTransactionKey(transactionID, mergeableData);
	return detectedConflictFields as MergeFieldKey[];

Tax was auto-merged rather than asked about, so it is invisible here — this is the bug hiding, not working.

Why Tax appears on the Confirm details page. The confirmation page renders MoneyRequestView with the merged data, which carries the tax fields over:

App/src/libs/MergeTransactionUtils.ts

Lines 397 to 400 in b570d0e

	taxValue: mergeTransaction.taxValue,
	taxAmount: mergeTransaction.taxAmount,
	taxCode: mergeTransaction.taxCode,
	taxName: mergeTransaction.taxName,

and in the merge flow the tax section's visibility is driven only by the presence of taxName, deliberately bypassing the isTaxEnabled check that hides it everywhere else:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 571 to 573 in b570d0e

	const isTaxEnabled = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode && !isTimeRequest && !isPerDiemRequest;
	const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

Since taxName was auto-filled from the source, shouldShowTax is true.

Why the merged expense ends up with tax and an error. taxCode/taxAmount are derived merge fields, so they differ from the target's (empty) values and survive the filter into the optimistic transaction changes:

App/src/libs/actions/MergeTransaction.ts

Lines 257 to 267 in b570d0e

	const filteredTransactionChanges = Object.fromEntries(
	Object.entries(mergeTransaction).filter(([key, mergeValue]) => {
	if (!(DERIVED_MERGE_FIELDS as readonly string[]).includes(key)) {
	return false;
	}
	const targetValue = getMergeFieldValue(targetTransactionDetails, targetTransaction, key as MergeFieldKey);
	return !deepEqual(mergeValue, targetValue);
	}),
	);

and the foreign taxCode plus taxPolicyID are sent with the request:

App/src/libs/actions/MergeTransaction.ts

Lines 413 to 414 in b570d0e

	taxCode: mergeTransaction.taxCode,
	taxPolicyID: mergeTransaction.taxPolicyID,

The merged expense now lives on a tax-disabled workspace while holding a tax rate from a different policy. Viewed normally, isTaxEnabled is false but taxCode is set, so shouldShowTaxDisabledAlert (MoneyRequestView L572) forces the Tax row to render, and the tax code is not valid on that policy, which surfaces as the tax violation error seen in the video.

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

Stop taxValue from participating in the merge when the target transaction's policy has tax tracking disabled, in getMergeFields:

App/src/libs/MergeTransactionUtils.ts

Lines 176 to 186 in b570d0e

	function getMergeFields(targetTransaction: OnyxEntry<Transaction>) {
	const excludeFields: MergeFieldKey[] = [];
	// Distance request's amount/currency/receipt depend on merchant selection
	// Distance request's tax depends on distance rate
	if (isDistanceRequest(targetTransaction)) {
	excludeFields.push('amount', 'taxValue');
	}
	return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
	}

function getMergeFields(targetTransaction: OnyxEntry<Transaction>, targetTransactionPolicy?: OnyxEntry<Policy>) {
    const excludeFields: MergeFieldKey[] = [];

    // Distance request's amount/currency/receipt depend on merchant selection
    // Distance request's tax depends on distance rate
    if (isDistanceRequest(targetTransaction)) {
        excludeFields.push('amount', 'taxValue');
    } else if (targetTransactionPolicy && !isTaxTrackingEnabled(true, targetTransactionPolicy, false, isPerDiemRequest(targetTransaction), isTimeRequest(targetTransaction))) {
        // The merged expense stays on the target transaction's policy, so tax must not be carried over from the source when that policy has tax tracking disabled
        excludeFields.push('taxValue');
    }

    return MERGE_FIELDS.filter((field) => !excludeFields.includes(field));
}

and pass the policy at the only call site, which already has it in scope:

for (const field of getMergeFields(targetTransaction, targetTransactionPolicy)) {

isTaxTrackingEnabled is the same helper MoneyRequestView uses, so the merge and the expense view agree on what "tax is disabled" means. isDistanceRequest is passed as false because the distance case is already handled by the branch above, and isPerDiemRequest/isTimeRequest are forwarded since those never support tax. The targetTransactionPolicy && guard keeps behaviour unchanged when the policy simply hasn't resolved yet (for example an unreported expense before the policy for moving expenses is known, or a partially-loaded search snapshot), so we only drop tax when we positively know the destination policy has tax tracking off.

Why this layer: getMergeFields is the single funnel that all three entry points into getMergeableDataAndConflictFields share — the setup that can skip straight to confirmation, the Details review page, and the Receipt review page — so all of them are fixed at once, and getMergeFields is module-private, so the signature change is contained:

App/src/libs/actions/MergeTransaction.ts

Lines 110 to 122 in b570d0e

	const {conflictFields, mergeableData} = getMergeableDataAndConflictFields(
	targetTransaction,
	sourceTransaction,
	localeCompare,
	getCurrencyDecimals,
	searchReports,
	targetTransactionPolicy,
	sourceTransactionPolicy,
	);
	if (!conflictFields.length) {
	// If there are no conflict fields, we should set mergeable data and navigate to the confirmation page
	setMergeTransactionKey(navigationTransactionID, mergeableData);
	Navigation.navigate(ROUTES.MERGE_TRANSACTION_CONFIRMATION_PAGE.getRoute(navigationTransactionID, Navigation.getActiveRoute(), isOnSearch));

With this change, no tax key is ever written into the merge transaction, which fixes every symptom in one place and needs no change in MoneyRequestView:

• Confirm details page: taxName is undefined, so shouldShowTax is false and the Tax section is gone.
• Merge request: no foreign taxCode/taxPolicyID is sent, and the tax fields are absent from the optimistic transaction changes, so the merged expense simply keeps the target expense's own tax state — none — with no violation.
• Select details page is unchanged, since tax was never a conflict field in this scenario.

I'd also add a unit test in tests/unit/MergeTransactionUtilsTest.ts asserting that getMergeableDataAndConflictFields returns no tax keys and no taxValue conflict when the target policy has tax.trackingEnabled off while the source policy has it on.

What alternative solutions did you explore? (Optional)

Gate shouldShowTax on isTaxEnabled in MoneyRequestView for the merge flow. Rejected: it only hides the Tax row on the Confirm page. The tax data would still be merged into the merge transaction and sent to the backend, so the merged expense would still carry the other workspace's tax rate and its error — the worst reported symptom would survive while looking fixed.

Turn taxValue into a conflict field so the user picks. Rejected: it contradicts the expected result (no tax section should appear), and asking a user to choose a tax rate for a workspace that has tax disabled is not a meaningful choice.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 17:21:16 UTC.

Proposal

What is the root cause of that problem?

taxValue is one of the merge fields. When one expense has no tax and the other has a tax, getMergeableDataAndConflictFields() treats the empty/non-empty pair as non-conflicting and automatically copies the taxed expense's taxValue plus the derived taxCode, taxName, and taxPolicyID into the merge draft.

App/src/libs/MergeTransactionUtils.ts

Lines 49 to 51 in b570d0e

	const MERGE_FIELDS = ['amount', 'merchant', 'created', 'category', 'tag', 'description', 'taxValue', 'reimbursable', 'billable', 'attendees', 'reportID'] as const;
	// Some fields are dependant on others. We need to automatically derive the correct field values depending on user selection.
	const DERIVED_MERGE_FIELDS = [...MERGE_FIELDS, 'taxCode', 'taxAmount'] as const;

App/src/libs/MergeTransactionUtils.ts

Lines 307 to 320 in b570d0e

	if (isTargetValueEmpty || isSourceValueEmpty || targetValue === sourceValue) {
	const selectedTransaction = isTargetValueEmpty ? sourceTransaction : targetTransaction;
	const selectedFieldValue = isTargetValueEmpty ? sourceValue : targetValue;
	const selectedPolicy = isTargetValueEmpty ? sourceTransactionPolicy : targetTransactionPolicy;
	const updatedValues = getMergeFieldUpdatedValues({
	transaction: selectedTransaction,
	field,
	fieldValue: selectedFieldValue as MergeTransaction[typeof field],
	getCurrencyDecimals,
	mergeTransaction: mergeableData as MergeTransaction,
	searchReports,
	policy: selectedPolicy,
	});
	Object.assign(mergeableData, updatedValues);

Selecting the destination report does not reconcile those already-derived tax fields with the selected report's policy. The reportID branch only updates reportName, so the tax from the tax-enabled workspace remains in the merge draft even after the report from the tax-disabled workspace is selected.

App/src/libs/MergeTransactionUtils.ts

Lines 663 to 666 in b570d0e

	if (field === 'reportID') {
	const reportName = transaction?.reportName?.length ? transaction?.reportName : getReportName(getReportOrDraftReport(getReportIDForExpense(transaction), searchReports));
	updatedValues.reportName = reportName.length ? reportName : null;
	}

The confirmation transaction then copies all of those stale tax fields, the merge-specific view intentionally shows a tax whenever taxName is present, and the merge request forwards the stale taxCode and taxPolicyID. Therefore this is not only a visibility issue: the invalid tax is also submitted and retained on the merged expense.

App/src/libs/MergeTransactionUtils.ts

Lines 394 to 400 in b570d0e

	reportID: mergeTransaction.reportID,
	reportName: mergeTransaction.reportName,
	routes: mergeTransaction.routes,
	taxValue: mergeTransaction.taxValue,
	taxAmount: mergeTransaction.taxAmount,
	taxCode: mergeTransaction.taxCode,
	taxName: mergeTransaction.taxName,

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 571 to 573 in b570d0e

	const isTaxEnabled = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const shouldShowTaxDisabledAlert = !isTaxEnabled && !!transaction?.taxCode && !isTimeRequest && !isPerDiemRequest;
	const shouldShowTax = isFromMergeTransaction ? !!transaction?.taxName : isTaxEnabled || shouldShowTaxDisabledAlert;

App/src/libs/actions/MergeTransaction.ts

Lines 410 to 416 in b570d0e

	billable: mergeTransaction.billable,
	reimbursable: mergeTransaction.reimbursable,
	tag: mergeTransaction.tag,
	taxCode: mergeTransaction.taxCode,
	taxPolicyID: mergeTransaction.taxPolicyID,
	receiptID: mergeTransaction.receipt?.receiptID,
	reportID: mergeTransaction.reportID,

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

Update getMergeFieldUpdatedValues() so its reportID handling also validates tax applicability against the policy belonging to the transaction whose report was selected. Reuse isTaxTrackingEnabled() with the selected transaction type. If tax tracking is disabled for that destination, explicitly clear taxValue, taxCode, taxName, and taxAmount, and set taxPolicyID to the selected destination policy ID so the merge command can remove any previously selected tax. If tax is enabled, preserve the independently selected or auto-derived tax fields.

App/src/libs/PolicyUtils.ts

Lines 1423 to 1438 in b570d0e

	function isTaxTrackingEnabled(
	isPolicyExpenseChatOrUnreportedExpense: boolean,
	policy: OnyxEntry<Policy>,
	isDistanceRequest: boolean,
	isPerDiemRequest = false,
	isTimeRequest = false,
	): boolean {
	if (isPerDiemRequest || isTimeRequest) {
	return false;
	}
	const distanceUnit = getDistanceRateCustomUnit(policy);
	const customUnitID = distanceUnit?.customUnitID ?? CONST.DEFAULT_NUMBER_ID;
	const isPolicyTaxTrackingEnabled = isPolicyExpenseChatOrUnreportedExpense && policy?.tax?.trackingEnabled;
	const isTaxEnabledForDistance = isPolicyTaxTrackingEnabled && !!customUnitID && policy?.customUnits?.[customUnitID]?.attributes?.taxEnabled;
	return !!(isDistanceRequest ? isTaxEnabledForDistance : isPolicyTaxTrackingEnabled);

The destination must be derived from the selected reportID, not assumed from the transaction that survives the merge. The report is itself a selectable conflict: choosing the tax-enabled report should keep a valid tax even if the surviving transaction originally belonged to a tax-disabled workspace, while choosing the tax-disabled report must clear tax even if the surviving transaction originally belonged to a tax-enabled workspace.

App/src/libs/MergeTransactionUtils.ts

Lines 277 to 285 in b570d0e

	// We allow user to select unreported report
	if (field === 'reportID') {
	if (targetValue === sourceValue) {
	const updatedValues = getMergeFieldUpdatedValues({transaction: targetTransaction, field, fieldValue: SafeString(targetValue), getCurrencyDecimals, searchReports});
	Object.assign(mergeableData, updatedValues);
	} else {
	conflictFields.push(field);
	}
	continue;

Apply this shared rule in both report-selection paths: DetailsReviewPage.handleSelect() already supplies the selected transaction, its policy, and the current merge draft; update the equal-report auto-resolution call inside getMergeableDataAndConflictFields() to supply the target policy and accumulated merge data as well. The other production call inside getMergeableDataAndConflictFields() handles non-report fields and remains unchanged by the new reportID branch. This keeps manual selection, automatic selection, search-backed policies, and direct merge setup consistent.

App/src/pages/TransactionMerge/DetailsReviewPage.tsx

Lines 95 to 115 in b570d0e

	(transaction: Transaction, transactionDetails: TransactionDetails, field: MergeFieldKey) => {
	const fieldValue = getMergeFieldValue(transactionDetails, transaction, field);
	// Clear error if it has
	setHasErrors((prev) => {
	const newErrors = {...prev};
	delete newErrors[field];
	return newErrors;
	});
	// Update both the field value and track which transaction was selected (persisted in Onyx)
	const currentSelections = mergeTransaction?.selectedTransactionByField ?? {};
	const updatedValues = getMergeFieldUpdatedValues({
	transaction,
	field,
	fieldValue,
	getCurrencyDecimals,
	mergeTransaction,
	searchReports: [targetTransactionReport, sourceTransactionReport],
	policy: transaction.transactionID === targetTransaction?.transactionID ? targetTransactionPolicy : sourceTransactionPolicy,
	});

Test coverage:

• Add a getMergeFieldUpdatedValues() unit test where the merge draft contains tax, the selected report belongs to a policy with tax tracking disabled, and assert that every tax field is cleared while reportID/reportName remain correct.
• Add the inverse unit test where the surviving transaction's original policy has tax disabled but the selected destination policy has tax enabled, verifying that choosing that report does not erase a valid tax.
• Add a getMergeableDataAndConflictFields() test for automatic report resolution under a tax-disabled policy to verify that stale tax cannot reach confirmation without visiting the details selector.

What alternative solutions did you explore? (Optional)

I considered changing MoneyRequestView to hide tax when the confirmation policy has tax disabled. That would only mask the preview: mergeTransactionRequest() would still send the stale tax fields, and the merge-specific taxName condition is intentional for valid merge cases such as distance expenses. I also considered excluding tax solely from the original target transaction's merge fields, but the user may select either report as the destination, so that would drop valid tax in one direction and retain invalid tax in the reverse direction. Reconciling dependent tax fields when reportID is selected is the earliest shared layer that keeps both preview and submitted data correct.