[Due for payment 2026-04-14] [Due for payment 2026-03-13] [$250] Distance - "Tax no longer valid" is shown on Tax field after changing distance rate

[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.28-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #74967
Email or phone of affected tester (no customers): sjiondsjndosijdonijso@gmaal.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Taxes and Distance rates.
• Add two tax rates - 5% and 10 %.
• Add a new distance rates - 1.00 / mile.
• Enable Track tax in Distance rates settings.
• Assign 5% tax rate to 0.725 / mile (default rate) with any tax reclaimable amount.
• Assign 10% tax rate to 1.00 / mile with any tax reclaimable amount.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual distance expense with the default distance rate (0,725 / mile).
4. Click Submit it to someone.
5. Select workspace chat.
6. On confirm page, click Rate.
7. Select another rate (1.00 / mile).
8. Click Create expense.

Expected Result:

Expense will be created without issue.

Actual Result:

"Tax no longer valid" is shown on Tax field when it cannot be edited.
User is blocked from submitting the distance expense.

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: @dylanexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028764072119933925
• Upwork Job ID: 2028764072119933925
• Last Price Increase: 2026-03-03
• Automatic offers:
• FitseTLT | Reviewer | 110642874

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #74967

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

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

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #74967 - "Fix - [Unreported] Add distance rate to the distance expenses tracked in selfDM" by @FitseTLT (High confidence)
Related Issues: None

Recommendation: REVERT

PR #74967 introduced distance rate selection for track expenses in selfDM but did not properly handle tax validation when changing rates. The tax validation uses the wrong policy reference, causing valid tax codes to be rejected.

Labels: No label changes made (keeping DeployBlockerCash as this is a frontend issue)

📋 Detailed Analysis

Evidence

The issue occurs specifically when:

1. User creates a distance track expense in selfDM with the default rate (e.g., 0.725/mile with 5% tax)
2. On the confirmation page, user changes to a different rate (e.g., 1.00/mile with 10% tax)
3. The tax code is updated correctly to match the new rate
4. However, validation fails with "Tax no longer valid" error

Verification

PR #74967 modified several key files:

• src/components/MoneyRequestConfirmationList.tsx - Tax validation happens here at line 1035
• src/libs/DistanceRequestUtils.ts - Added policyForMovingExpenses parameter to getRate function
• src/hooks/usePolicyForTransaction.ts - Modified to return policyForMovingExpenses for track expenses
• src/pages/iou/request/step/IOURequestStepDistanceRate.tsx - Rate selection page where tax is updated

Root Cause

The bug is in src/components/MoneyRequestConfirmationList.tsx at line 1035:

if (shouldShowTax && !!transaction.taxCode && !hasTaxRateWithMatchingValue(policy, transaction)) {
    setFormError('violations.taxOutOfPolicy');
    return;
}

When changing the distance rate for a track expense in selfDM:

1. The new rate is selected from policyForMovingExpenses (the workspace that owns the distance rates)
2. The transaction's taxCode is correctly updated to match the new rate's tax (from policyForMovingExpenses)
3. But the validation checks if that taxCode exists in policy variable
4. For track expenses, policy is determined by usePolicyForTransaction which returns policyForMovingExpenses
5. However, there's a mismatch: the tax code from the new rate (stored in policyForMovingExpenses.customUnits.rates[rateID].attributes.taxRateExternalID) is being validated against policy.taxRates

The issue is that when policyForMovingExpenses is passed to getRate() for displaying the rate, but the validation still uses just policy to check if the tax is valid. The PR introduced the ability to use workspace distance rates in selfDM track expenses but didn't update the tax validation logic to use the correct policy reference (policyForMovingExpenses instead of policy for track expenses moving to workspace).