Expense - Tax field changes to 0% rate after editing tax code and submitting from self DM

[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.3.99-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84260
Email or phone of affected tester (no customers): sdosdoinjosnjosno@gmail.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:

• Taxes are enabled.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create an expense with 5% tax rate.
4. Go to workspace settings > Taxes.
5. Click 5% rate > Tax code.
6. Upgrade the workspace.
7. Edit tax code and save it.
8. Go to self DM.
9. Click Submit it to someone.
10. Select workspace chat.
    → On confirm page, Tax field shows 5% tax rate.
11. Click Create expense.
12. Open the created expense.

Expected Result:

Tax field will show 5% rate.

Actual Result:

Tax field changes to 0% rate after editing tax code and submitting from self DM.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171438_1780568921634.9.mp4

View all open jobs on GitHub

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

[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/98261dc2edecd055af29305dac40ada90e74984b978cf3361ff4b0f540469fb8

[melvin-bot]

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

[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

Posted by MelvinBot 🤖 — confidence: Medium-High. The App-side root cause (below) is proven from code; the final "0%" persistence depends on the server rejecting an unknown tax code, which should be confirmed by inspecting the created transaction after submit.

What is the root cause of that problem?

When a workspace tax code is renamed, the rename is stored by adding the tax under a new key with a previousTaxCode field pointing at the old code (TaxRate.ts:608). The expense created in the self DM still stores the old tax code.

PR #84260 added resolveCurrentTaxCode (old code → current key) and wired it into the display paths only — the confirmation TaxPicker and MoneyRequestView/getTaxName. That is why the confirm page correctly shows 5%.

But the save path was not updated. When submitting, the stale tax code is read verbatim (useExpenseSubmission.ts:254-256) and sent unchanged to the server via the SUBMIT flow (TrackExpense.ts:1758-1772 → spread into the API call at TrackExpense.ts:1551). The server can't match a tax code that no longer exists as a key, so the saved expense falls back to the default (0%).

This also explains "not reproducible in production": before #84260, the confirmation page itself showed the tax as missing/unselected (that's the original bug #83111). #84260 fixed the display so confirm now shows 5%, exposing that the save path still drops it.

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

Resolve the renamed tax code before sending it to the server, mirroring what the display paths already do. Apply resolveCurrentTaxCode(policy, …) to the transaction's tax code where the submit value is derived (useExpenseSubmission.ts:254-256) so the current key — not the stale one — is persisted. The same stale-code pattern is used by the CATEGORIZE and SHARE track-expense paths, so the fix should cover all three convert actions for consistency.

What alternative solutions did you explore? (Optional)

Revert #84260 (fast deploy-blocker option): this removes the trigger but reintroduces #83111 (tax name missing/unselected after rename) and doesn't fix the underlying save-path gap. Forward-fixing is preferred unless time forces a revert.

Supporting evidence & data flow

1. Track expense created in self DM → transaction.taxCode = OLD_CODE (5%).
2. Rename workspace 5% tax code → taxes[OLD_CODE] removed; taxes[NEW_CODE] = {…, previousTaxCode: OLD_CODE} (TaxRate.ts:608).
3. Confirm page (TaxPicker) calls resolveCurrentTaxCode(policy, OLD_CODE) → NEW_CODE → shows 5% ✅.
4. On submit, useExpenseSubmission.ts:255 keeps transaction.taxCode = OLD_CODE (no resolution).
5. SUBMIT case puts taxCode: OLD_CODE into workspaceParams (TrackExpense.ts:1764) → spread into the API params (TrackExpense.ts:1551).
6. Server can't match OLD_CODE (it only exists as previousTaxCode under NEW_CODE) → persisted tax defaults to 0%.
7. After the server response replaces the optimistic data, MoneyRequestView reads taxCode/taxValue from the saved transaction → shows 0% ❌.

Why display vs. save diverge: display utilities were patched by #84260 to call resolveCurrentTaxCode; the IOU submit/convert actions in src/libs/actions/IOU/ were not (no occurrences of resolveCurrentTaxCode there).

Verification suggestion: after step 11, inspect the created transaction's taxCode/taxValue in Onyx (or the API request payload). Expected to show the stale OLD_CODE being sent and an empty/default value persisted.

Related issue

• [Due for payment 2026-08-28] [$250] Tax - Tax name is missing and tax is no longer selected after changing tax code #83111 — the original "tax name missing after changing tax code" that Fix: Tax name missing and tax unselected after changing tax code #84260 fixed; reverting Fix: Tax name missing and tax unselected after changing tax code #84260 reintroduces it.

---

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.

[Krishna2323]

@marufsharifi could you please check this?