[Due for payment 2026-07-13] Distance - Tax field does not auto update when rate changes after changing date

[applause-bot]

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.4.2-0
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: #92578
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.
• Enable Distance rates and Taxes.
• Create the following distance rates:
• Rate A: "2025 mileage" — $0.50/mile, start: 2025-01-01, end: 2025-12-31
• Rate B: "2026 mileage" — $0.60/mile, start: 2026-01-01, end: 2026-12-31
• Enable Track tax in Distance rates > Settings.
• Add tax to the distance rates as follow:
• Rate A: "2025 mileage" — Tax rate 0%, Tax reclaimable amount 0.40
• Rate B: "2026 mileage" — Tax rate 5%, Tax reclaimable amount 0.40

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Track distance > Manual.
4. Enter amount > Next.
5. On confirm page, click Date and select any date from 2025.
   → Tax field still shows Tax rate 5% when the rate is changed to Rate A with Tax rate 0%.
6. Click Rate and select the same rate (Rate A).
   → Tax field only updates to Tax rate 0% after manually reselecting distance rate.

Expected Result:

In Step 5, after changing date to 2025 and distance rate auto changes, Tax field will auto update to Tax rate 0%.

Actual Result:

In Step 5, after changing date to 2025 and distance rate auto changes, tax field still shows Tax rate 5% when the rate is changed to Rate A with Tax rate 0%.

In Step 6, after manually reselecting distance rate, Tax field updates to Tax rate 0%.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7176426_1781056430109.8.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7176426

Issue Owner

Current Issue Owner: @Krishna2323

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/84666f246f64379f5d333dfb20912520ebb0c553500e2352ab09a9e0f96ca70c

[melvin-bot]

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

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

When the expense date is changed, the date step recalculates the date-appropriate mileage rate and applies it via setCustomUnitRateID, but that function never recalculates the tax tied to the new rate.

In IOURequestStepDate.tsx:127-138, after the date changes for a distance request on a workspace/track expense, the new rate is computed and passed to setCustomUnitRateID.

setCustomUnitRateID (MoneyRequest.ts:612-652) only merges customUnitRateID, distanceUnit, and quantity into the draft. It does not touch taxCode / taxAmount / taxValue, so the tax of the previous rate stays on the transaction.

By contrast, the manual rate-selection page recalculates tax from the newly-selected rate's taxRateExternalID and writes it via setMoneyRequestTaxAmount / setMoneyRequestTaxRate / setMoneyRequestTaxValue — see IOURequestStepDistanceRate.tsx:177-192. That's why manually reselecting the rate (Step 6) fixes the tax, while the auto rate-change on date selection (Step 5) leaves it stale.

This was introduced by #92578 (date-aware mileage rate selection), which added the auto rate-change on date change without porting over the tax recalculation.

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

After the date-driven setCustomUnitRateID call in IOURequestStepDate.tsx:127-138, recalculate and persist the tax for the new rate when tax tracking is enabled — mirroring the logic already in IOURequestStepDistanceRate.tsx:177-192:

• Resolve the new rate's taxRateExternalID (fallback to the default tax code).
• Compute taxableAmount / taxValue / taxAmount for the new rate.
• Call setMoneyRequestTaxRate, setMoneyRequestTaxAmount, and setMoneyRequestTaxValue (using the draft variant when appropriate).

Preferred approach — consolidate so any auto rate-change stays consistent

A cleaner, DRY-er fix is to fold the tax recalculation into setCustomUnitRateID itself (it already receives policy and the new customUnitRateID), so every programmatic rate change keeps tax in sync rather than each caller re-implementing it. The shared tax math in IOURequestStepDistanceRate.tsx could be extracted into a small helper used by both call sites. Care should be taken to preserve the existing isEditing guard so editing flows aren't regressed.

What alternative solutions did you explore? (Optional)

None — the asymmetry between the two code paths is the direct cause, so aligning them is the fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[rlinoz]

Not a blocker, feature is behind a beta