[$250] [Merge] Expense - Tax is shown on merge confirmation page when destination WS has no taxes

[jponikarchuk]

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): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Air 15.7.3 Chrome, Pixel 5 Android 14
App Component: Money Requests

Action Performed:

1. Sign in to ND
2. Create Workspace 1, enable Taxes, add tax rate 10%
3. Create Workspace 2, Taxes are disabled
4. Add Expense 1 in the workspace 1 chat, select tax rate 10%, rename the report for the convenience
5. Create Expense 2 in the workspace 2 chat
6. Navigate to the Workspace 1 chat, open Expense 1
7. Click More - Merge, select Expense 2 from Workspace 2
8. Select Amount, merchant, category, and report of the Expense 2, click Continue
9. Observe the confirmation page

Expected Result:

In review details step, Tax field does not show , as it's auto selected depending on destination report (#71244 Test 3 Step 1)

Actual Result:

Tax rate and Tax amount fields are shown on merge confirmation page, when destination WS has no taxes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022025522339194621554
• Upwork Job ID: 2025522339194621554
• Last Price Increase: 2026-02-22

[melvin-bot]

Triggered auto assignment to @heyjennahay (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.

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

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

When merging two expenses where one comes from a workspace with taxes enabled and the other from a workspace with taxes disabled, the merge confirmation page incorrectly shows "Tax rate" and "Tax amount" fields even when the destination workspace has taxes disabled.

What is the root cause of that problem?

There are two contributing factors:

1. MoneyRequestView.tsx has a short-circuit that bypasses the policy tax check (MoneyRequestView.tsx:417):

shouldShowTax = !!transaction?.taxName || isTaxTrackingEnabled(...)

The !!transaction?.taxName evaluates to true before isTaxTrackingEnabled can check the destination policy's tax.trackingEnabled setting. In the merge flow, the transaction is overridden by the merged transaction data (MoneyRequestView.tsx:209-211), which always carries taxName from the source transaction.

2. The merge data pipeline never filters out tax fields based on the destination policy's tax settings:

• MERGE_FIELDS always includes 'taxValue' (MergeTransactionUtils.ts:41) — no policy tax-enablement check
• getMergeFields() only excludes 'amount' for distance requests, never tax fields (MergeTransactionUtils.ts:167-176)
• buildMergedTransactionData() unconditionally copies taxValue, taxAmount, taxCode, and taxName into the merged transaction (MergeTransactionUtils.ts:384-387)

Compare with the expense creation flow in MoneyRequestConfirmationList.tsx (line 360) which correctly uses only isTaxTrackingEnabled() without the taxName bypass.

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

The fix should be in MoneyRequestView.tsx at the shouldShowTax computation. When the component is rendering a merge confirmation (i.e., mergeTransactionID is provided), the shouldShowTax check should rely on isTaxTrackingEnabled() rather than short-circuiting on !!transaction?.taxName. This ensures the destination policy's tax settings are respected.

Additionally, in MergeTransactionUtils.ts, getMergeFields() should exclude 'taxValue' from MERGE_FIELDS when the destination policy does not have tax tracking enabled (similar to how 'amount' is excluded for distance requests). This prevents the tax field from appearing in the details review step when it's irrelevant to the destination workspace.

What alternative solutions did you explore? (Optional)

An alternative would be to clear tax fields in buildMergedTransactionData() when the target policy has taxes disabled (setting taxName, taxCode, taxValue, taxAmount to empty/zero). However, this would be a downstream fix that masks the real issue — the merge flow should not present tax as a selectable/reviewable field at all when the destination workspace doesn't support taxes.

---

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

[annaweber830]

Proposal

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

When we merge expenses and choose a destination report that belongs to a workspace with taxes disabled, the merge confirmation page still shows tax fields. This is incorrect because tax visibility in that review step should follow the destination workspace policy.

What is the root cause of that problem?

MoneyRequestView computes tax visibility with a fallback that always shows tax when the merged transaction carries taxName, even if the destination workspace policy does not track taxes.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 415 to 418 in 97b8ca7

	const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);
	const shouldShowTax = !!transaction?.taxName || isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const tripID = getTripIDFromTransactionParentReportID(parentReport?.parentReportID);

const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);

const shouldShowTax = !!transaction?.taxName || isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
const tripID = getTripIDFromTransactionParentReportID(parentReport?.parentReportID);
const shouldShowViewTripDetails = hasReservationList(transaction) && !!tripID;

In merge confirmation, transaction is overridden with merged data that can retain tax information from the source expense, so !!transaction?.taxName becomes true and forces tax fields visible. This causes the UI to ignore the destination workspace tax setting because the OR condition short-circuits before policy-based tax eligibility controls the result.

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

For merge confirmation only, compute shouldShowTax strictly from isTaxTrackingEnabled(...) so destination policy tax settings remain authoritative; keep the existing taxName fallback for non-merge money request views.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 415 to 418 in 97b8ca7

	const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);
	const shouldShowTax = !!transaction?.taxName || isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const tripID = getTripIDFromTransactionParentReportID(parentReport?.parentReportID);

Current code:

const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);

const shouldShowTax = !!transaction?.taxName || isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
const tripID = getTripIDFromTransactionParentReportID(parentReport?.parentReportID);
const shouldShowViewTripDetails = hasReservationList(transaction) && !!tripID;

Updated code:

const shouldShowAttendees = shouldShowAttendeesTransactionUtils(iouType, policy);

const shouldShowTax = isFromMergeTransaction
    ? isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest)
    : !!transaction?.taxName || isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
const tripID = getTripIDFromTransactionParentReportID(parentReport?.parentReportID);
const shouldShowViewTripDetails = hasReservationList(transaction) && !!tripID;

This keeps existing behavior for regular expense views while making merge confirmation align with destination-workspace tax configuration.

What alternative solutions did you explore? (Optional)

• Remove taxValue from merge fields when the destination workspace disables taxes. I did not choose this as the primary fix because it addresses merge payload composition rather than the immediate visibility bug on the confirmation UI.
• Clear tax fields in buildMergedTransactionData() for tax-disabled destinations. I avoided this because it mutates merged preview data and can hide values indirectly instead of fixing the display condition.

[imadirtydog]

Proposal

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

When merging two expenses where the destination workspace has taxes disabled, the merge confirmation page incorrectly shows "Tax rate" and "Tax amount" fields.

What is the root cause of that problem?

buildMergedTransactionData unconditionally copies tax fields from the merge transaction, regardless of the destination workspace's tax settings:

App/src/libs/MergeTransactionUtils.ts

Lines 386 to 389 in 97b8ca7

	taxCode: mergeTransaction.taxCode,
	taxName: mergeTransaction.taxName,
	};
	}

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

This causes MoneyRequestView to display tax fields because shouldShowTax short-circuits with !!transaction?.taxName before checking the destination policy.

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

Primary Solution

Pass the destination policy to buildMergedTransactionData and only include tax fields when taxes are enabled.

1. Update function signature:

App/src/libs/MergeTransactionUtils.ts

Line 357 in 97b8ca7

return null;

function buildMergedTransactionData(
    targetTransaction: OnyxEntry<Transaction>,
    mergeTransaction: OnyxEntry<MergeTransaction>,
    targetPolicy?: OnyxEntry<Policy>
): Transaction | null {

2. Conditionally include tax fields:

const isTaxEnabled = targetPolicy?.tax?.trackingEnabled;

return {
    ...targetTransaction,
    // ... existing fields ...
    taxValue: isTaxEnabled ? mergeTransaction.taxValue : undefined,
    taxAmount: isTaxEnabled ? mergeTransaction.taxAmount : undefined,
    taxCode: isTaxEnabled ? mergeTransaction.taxCode : undefined,
    taxName: isTaxEnabled ? mergeTransaction.taxName : undefined,
};

3. Update call site:

App/src/pages/TransactionMerge/ConfirmationPage.tsx

Line 69 in 97b8ca7

const mergedTransactionData = buildMergedTransactionData(targetTransaction, mergeTransaction);

const mergedTransactionData = buildMergedTransactionData(targetTransaction, mergeTransaction, targetTransactionPolicy);

Secondary Solution (if changing function signature is not desired)

Only include tax fields if the target transaction already has tax data:

App/src/libs/MergeTransactionUtils.ts

Lines 386 to 389 in 97b8ca7

	taxCode: mergeTransaction.taxCode,
	taxName: mergeTransaction.taxName,
	};
	}

taxValue: targetTransaction.taxCode ? mergeTransaction.taxValue : undefined,
taxAmount: targetTransaction.taxCode ? mergeTransaction.taxAmount : undefined,
taxCode: targetTransaction.taxCode ? mergeTransaction.taxCode : undefined,
taxName: targetTransaction.taxCode ? mergeTransaction.taxName : undefined,

If the destination workspace has taxes disabled, the target transaction won't have taxCode, so tax fields won't be included in the merged result. This approach requires no signature changes.