[$250] Distance - Tax amount is 0 on created tracked distance expenses even when distance rate has tax configured

[cristipaval]

Version Number: 9.3.53-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers):
Issue reported by: Internal
Bug source: Related to #87202

Action Performed:

Precondition:

• A workspace with Distance rates and Taxes enabled
• Track tax enabled in Distance settings
• A distance rate with a non-zero tax rate (e.g. 5%) and a reclaimable amount configured

1. Go to self DM
2. Click + > Track distance > Manual
3. Enter a distance amount and proceed
4. On the confirm page, select the rate with the 5% tax
5. Submit the expense
6. View the created expense

Expected Result:

The created expense should show the correct tax amount based on the configured tax rate on the distance rate.

Actual Result:

The tax amount on the created expense is 0, even though the correct tax rate was selected.

Note: The confirmation page shows the correct tax rate/amount after #87237, but the persisted expense still has a 0 tax amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

See comment: #87237 (comment)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041486589785177521
• Upwork Job ID: 2041486589785177521
• Last Price Increase: 2026-04-14
• Automatic offers:
• FitseTLT | Contributor | 111137113

Issue Owner

Current Issue Owner: @FitseTLT

[MelvinBot]

Proposal

What is the root cause of that problem?

There are two compounding issues causing the tax amount to persist as 0:

1. IOURequestStepDistanceRate.tsx:84 — shouldShowTax excludes track expenses

shouldShowTax = isTaxTrackingEnabled(isPolicyExpenseChat || isExpenseUnreported(currentTransaction), ...)

For a tracked distance expense in a self-DM, isPolicyExpenseChat is false and isExpenseUnreported(currentTransaction) is false (draft transaction). So shouldShowTax = false, and the entire tax block at lines 159–170 is skipped when the user selects a rate. The rate's taxRateExternalID is never written to the draft. PR #87237 fixes this part by adding isTrackExpense to the condition.

2. MoneyRequestConfirmationList.tsx:397–413 — initial tax code defaults to policy default, not the distance rate's tax code

Even with PR #87237 applied, there's a second issue: when the confirmation page first renders (before any rate change), the first useEffect sets taxCode to defaultTaxCode (the policy's default tax code from getDefaultTaxCode). This is the policy-level default tax — not the distance rate's specific taxRateExternalID. The second useEffect (line 611–616) then computes tax using this wrong code:

taxPercentage = getTaxValue(policy, transaction, transaction?.taxCode ?? defaultTaxCode)

If the policy's default tax rate is 0% (e.g., "Tax exempt") while the selected distance rate has a 5% tax configured via taxRateExternalID, the computed taxAmount = 0. This 0 is persisted to the draft and sent to the TrackExpense API at IOURequestStepConfirmation.tsx:999.

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

Two changes are needed:

1. In IOURequestStepDistanceRate.tsx (PR [CP Staging] Fix tax in confirmation page when creating a tracked distance request #87237's fix): Add isTrackExpense to the shouldShowTax condition so that selecting a distance rate for tracked expenses correctly saves the rate's taxRateExternalID, taxAmount, and taxValue to the draft.

2. In MoneyRequestConfirmationList.tsx: When computing the initial/default tax code for distance requests, look up the selected rate's taxRateExternalID from getDistanceRateCustomUnitRate(policy, customUnitRateID)?.attributes?.taxRateExternalID and use it as the effective default instead of defaultTaxCode. This ensures that even on initial render (before any rate change), the tax is computed using the correct rate-specific tax code. The first useEffect (line 397–413) should use this rate-aware default for distance requests, and the tax computation (line 604–605) should similarly prefer the rate's tax code.

What alternative solutions did you explore? (Optional)

An alternative would be to set the rate-specific taxCode on the draft at transaction initialization time (in initMoneyRequest in IOU/index.ts). However, the rate may not be known at that point, and placing the logic in MoneyRequestConfirmationList keeps it consistent with how tax is already computed for the display.

Investigation details

Data flow (bug path):

1. initMoneyRequest creates draft transaction without taxAmount or taxCode (IOU/index.ts:1147)
2. Confirmation page renders → first useEffect sets taxCode = defaultTaxCode (policy default, not rate-specific)
3. Second useEffect computes tax using defaultTaxCode → if policy default is 0%, taxAmount = 0
4. User selects rate with 5% tax → rate page skips tax block (shouldShowTax = false for track expenses)
5. User returns → confirmation page still has taxCode = defaultTaxCode → tax recomputed as 0
6. User confirms → IOURequestStepConfirmation.tsx:314 reads transaction?.taxAmount ?? 0 = 0 → sent to API

Key files:

• src/pages/iou/request/step/IOURequestStepDistanceRate.tsx:84,159–170 — rate page tax logic
• src/components/MoneyRequestConfirmationList.tsx:389,397–413,601–616 — confirmation page tax computation
• src/pages/iou/request/step/IOURequestStepConfirmation.tsx:314,999 — reads taxAmount and sends to API
• src/libs/PolicyUtils.ts:236–239 — getDistanceRateCustomUnitRate (used to get rate's taxRateExternalID)
• src/libs/PolicyUtils.ts:835–851 — isTaxTrackingEnabled

Related issues:

• [Due for payment 2026-04-16] [Due for payment 2026-04-14] Distance - Tax rate and amount do not update after selecting distance rate on confirm page #87202 — Parent issue (tax rate/amount don't update on confirm page after selecting distance rate)
• [HOLD E/E #601592] Distance - Change waypoint before create expense, Tax amount change to 0 #79861 — Similar: changing waypoint causes tax amount to change to 0

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

The tax amount on a created tracked distance expense saves as 0, even when the chosen distance rate has a non-zero tax configured.

What is the root cause of that problem?

Inside MoneyRequestConfirmationList.tsx, the defaultTaxCode is calculated using the policy's default tax code rather than the distance rate's custom tax code:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 391 to 393 in a0abb60

	// Update the tax code when the default changes (for example, because the transaction currency changed)
	const defaultTaxCode = getDefaultTaxCode(policy, transaction) ?? (isMovingTransactionFromTrackExpense ? (getDefaultTaxCode(policyForMovingExpenses, transaction) ?? '') : '');
	const defaultTaxValue = getTaxValue(policy, transaction, defaultTaxCode) ?? null;

This policy default code is what drives the computed taxPercentage and the resulting taxAmount:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 604 to 608 in a0abb60

	const taxPercentage =
	getTaxValue(policy, transaction, transaction?.taxCode ?? defaultTaxCode) ??
	(isMovingTransactionFromTrackExpense ? getTaxValue(policyForMovingExpenses, transaction, transaction?.taxCode ?? defaultTaxCode) : '');
	const taxDecimals = getCurrencyDecimals(transaction?.currency ?? CONST.CURRENCY.USD);
	const taxAmount = isMovingTransactionFromTrackExpense && transaction?.taxAmount ? Math.abs(transaction?.taxAmount ?? 0) : calculateTaxAmount(taxPercentage, taxableAmount, taxDecimals);

Because of this, an effect inside MoneyRequestConfirmationList.tsx ends up wrongly initializing the transaction's taxCode and taxAmount onto the draft using the policy's baseline tax (which is 0). The confirmation page background effect overwrites it with the defaultTaxCode behavior, persisting 0 to the backend upon submission.

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

In src/components/MoneyRequestConfirmationList.tsx, replace the usage of the bare policy-level defaultTaxCode for distance requests.

Before calculating the default, check if there is a selected customUnitRateID for the distance request, and read taxRateExternalID from it by using:
PolicyUtils.getDistanceRateCustomUnitRate(policy, customUnitRateID)?.attributes?.taxRateExternalID

Use this rate-specific tax code as the effective defaultTaxCode. Also, ensure that the taxPercentage calculation uses this rate-specific tax code instead of the generic policy defaultTaxCode. This guarantees that the draft correctly receives the distance rate's tax and properly transmits the correct taxAmount to the backend.

What alternative solutions did you explore? (Optional)

We could push this initialization logic further upstream into initMoneyRequest in IOU/index.ts so that when a distance request draft is created, the rate's taxCode is explicitly placed on the transaction draft right away instead of having MoneyRequestConfirmationList.tsx manage the default computation.

[JasimMalook]

Hello Expensify Team,

I’d like to submit my proposal to fix the issue where the tax amount on created tracked distance expenses shows as 0 even when the distance rate has a tax configured.

Root Cause Analysis:
The problem occurs due to two main reasons:

IOURequestStepDistanceRate.tsx – The shouldShowTax condition excludes tracked distance expenses. As a result, when creating a tracked distance expense, the selected rate’s taxRateExternalID is never saved to the draft. PR #87237 partially addresses this, but not completely.
MoneyRequestConfirmationList.tsx – On initial render, the tax code defaults to the policy’s default tax code rather than the selected distance rate’s tax. If the policy default tax is 0%, the persisted expense shows 0 tax, even if the selected rate has a non-zero tax configured.

Proposed Solution:

Update IOURequestStepDistanceRate.tsx:
Include isTrackExpense in the shouldShowTax condition to ensure the tax block executes for tracked distance expenses:
shouldShowTax = isTaxTrackingEnabled(
isPolicyExpenseChat || isExpenseUnreported(currentTransaction) || isTrackExpense,
...
);
Update MoneyRequestConfirmationList.tsx:
Use the selected rate’s taxRateExternalID as the effective default tax code during initial render:
const rateTaxCode = getDistanceRateCustomUnitRate(policy, customUnitRateID)?.attributes?.taxRateExternalID;

This ensures that even on first render, the correct tax is computed and persisted.

Alternative Solutions Explored:

Setting the rate-specific tax at transaction initialization. This is less optimal because the selected rate may not be known yet, and it could break the existing display logic.

Contributor Details:

Name: Jasim Malook
Email: jasimmalook@gmail.com
Upwork Profile: https://www.upwork.com/freelancers/~014c25762fc2275193

Thank you for considering my proposal. I am confident this solution will resolve the tax calculation issue for all tracked distance expenses and ensure correct persistence across the app.

[Abdullahtmk]

Proposal

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

When submitting a manual distance expense with a distance rate that has tax enabled (for example 5%), the confirmation screen correctly shows tax, but the created expense is persisted with taxAmount = 0.

What is the root cause of that problem?

The tax shown on confirmation is computed in UI state, but the persisted TrackExpense payload can still read stale transaction draft values.

In MoneyRequestConfirmationList, tax is calculated and then written to the draft in a useEffect:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 601 to 606 in 4362d1c

	// Calculate and set tax amount in transaction draft
	const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : Math.abs(transaction?.amount ?? 0);
	// First we'll try to get the tax value from the chosen policy and if not found, we'll try to get it from the policy for moving expenses (only if the transaction is moving from track expense)
	const taxPercentage =
	getTaxValue(policy, transaction, transaction?.taxCode ?? defaultTaxCode) ??
	(isMovingTransactionFromTrackExpense ? getTaxValue(policyForMovingExpenses, transaction, transaction?.taxCode ?? defaultTaxCode) : '');

But IOURequestStepConfirmation builds submit params from

transaction?.taxAmount ?? 0:

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

Line 314 in 4362d1c

const transactionTaxAmount = transaction?.taxAmount ?? 0;

And this transaction amount is passed to trackExpenseIOUActions as

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

Line 999 in 4362d1c

taxAmount: transactionTaxAmount,

So if submit happens before draft tax sync is committed, payload tax remains 0 even though confirmation UI displays the computed tax.

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

Guarantee tax is finalized before submit for distance flows: Recompute tax at submit time in IOURequestStepConfirmation (using the same formula as confirmation UI), and pass that computed value to trackExpenseIOUActions. Use this computed value as source of truth when isDistanceRequest is true.

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

// 1) Add imports near existing tax/distance imports
import DistanceRequestUtils from '@libs/DistanceRequestUtils';
import {calculateTaxAmount, getDefaultTaxCode, getTaxValue} from '@libs/TaxUtils';
import {convertToBackendAmount} from '@libs/CurrencyUtils';

// ...inside component...

// 2) Add helper before `trackExpense` callback
const getDistanceTaxPayload = useCallback(
    (item: OnyxTypes.Transaction) => {
        const itemTaxCode = (item?.taxCode ? item.taxCode : getDefaultTaxCode(policy, item)) ?? '';
        const itemTaxValue = item?.taxValue ?? getTaxValue(policy, item, itemTaxCode) ?? '';

        // If not a distance request, keep current behavior
        const itemIsDistanceRequest =
            isManualDistanceRequestTransactionUtils(item) ||
            isOdometerDistanceRequestTransactionUtils(item) ||
            isGPSDistanceRequestTransactionUtils(item);

        if (!itemIsDistanceRequest) {
            return {
                taxCode: itemTaxCode,
                taxValue: itemTaxValue,
                taxAmount: item?.taxAmount ?? 0,
            };
        }

        const itemRateID = getRateID(item) ?? '';
        const itemDistance = item.comment?.customUnit?.quantity ?? 0;
        const taxableAmount = DistanceRequestUtils.getTaxableAmount(policy, itemRateID, itemDistance);
        const decimals = getCurrencyDecimals(item.currency ?? CONST.CURRENCY.USD);
        const computedTaxAmount = convertToBackendAmount(calculateTaxAmount(itemTaxValue, taxableAmount, decimals));

        return {
            taxCode: itemTaxCode,
            taxValue: itemTaxValue,
            taxAmount: computedTaxAmount,
        };
    },
    [policy, getCurrencyDecimals],
);

Keep draft tax synchronized earlier: Continue draft updates in confirmation, but avoid relying on async useEffect timing as the only source before API call. Use per-item tax in submit loop:

In transactions.entries() submit path, prefer item.taxCode/taxAmount/taxValue (with fallback) so each submitted transaction carries correct tax.

Optional hardening in TrackExpense: Avoid treating 0 as “missing” in optimistic transaction construction (taxAmount ? ... : undefined), and instead handle explicit zero/non-zero values more safely.

This ensures persisted tax always matches the selected distance rate and confirmation calculation.

What alternative solutions did you explore? (Optional)

N/A