[$250] Report - Tax rate selected manually is not retained on report if a rule was created before.

[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?: 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: #81514
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace with rules enabled.
Prerequisite 2: "Taxes" enabled and at least two taxes different from default available.

1. Open the Expensify app.
2. Navigate to "Workspaces" > "Rules" > "Add Merchant Rule"
3. In "For expenses with", add any merchant.
4. In "Apply these updates", add any category, a description and a tax that is different from the default one.
5. Save the rule.
6. Navigate to workspace chat.
7. Start a manual expense creation flow.
8. Add an amount and tap on "Next"
9. Add the same merchant from step 3.
10. Select a category different from the one on created rule and also a different description.
11. Navigate to "Tax" field and select a rate that is different as the one selected on the created rule, and also different from the default one.
12. Finish the expense creation flow.
13. Open the report of the just created expense.
14. Note that "Category" and "Description" fields, show the information added manually while creating expense.
15. Note that tax rate selected manually, was not retained.

Expected Result:

Created rules should not override the fields that were selected manually by the user while creating expense.

Actual Result:

Tax rate selected manually while creating an expense, is not retained if a rule was created before.

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022025806224289136176
• Upwork Job ID: 2025806224289136176
• Last Price Increase: 2026-02-23

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @sonialiap (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: Backend bug
Causing PR: Cannot be determined - this appears to be a backend issue, not a frontend (App) bug
Related Feature: Merchant Rules (enabled via #82438)

Recommendation: REMOVE DeployBlockerCash LABEL

The tax rate override issue is caused by backend logic applying merchant coding rules incorrectly, not by any App PR.

Labels: Removing DeployBlockerCash label. This does NOT block the App deploy. Keeping DeployBlocker label as this blocks the backend/Web deploy.

Detailed Analysis

Evidence

What happens:

1. User creates a merchant coding rule with specific category, description, and tax rate
2. User manually creates an expense with the SAME merchant but DIFFERENT category, description, and tax rate
3. After expense creation completes, the tax rate is overridden by the rule
4. However, category and description are NOT overridden (remain as manually selected)

Why this indicates a backend bug:

• Merchant rules are applied by the backend after expense submission, not by frontend code
• I extensively searched the App codebase and found NO logic that applies coding rules to transactions
• The issue reports the tax is "not retained" AFTER completing the flow, indicating server-side processing
• The selective override (tax only, not category/description) suggests backend rule application logic is incorrect

Verification

Frontend code checked:

• src/libs/actions/IOU/index.ts - No merchant rule application logic
• src/libs/ExpenseRuleUtils.ts - Only formatting utilities, no application logic
• src/pages/iou/request/step/IOURequestStepConfirmation.tsx - Uses transaction tax values as-is
• setMoneyRequestTaxRate() function - Simple setter, no rule checking

Merchant Rules PRs:

• Enable merchant rules v2 #82438 "Enable merchant rules v2" - Just removed a feature flag
• Create merchant rule #80545 "Create merchant rule" - UI for creating rules, no application logic
• Add merchant rules option to workspace duplication #81514 "Add merchant rules option to workspace duplication" - Only about duplication feature

None of these App PRs contain logic for APPLYING merchant rules to expenses during creation.

Root Cause

Merchant coding rules are a backend feature. The backend applies these rules when processing expense submissions. The bug is that the backend is:

1. Correctly NOT overriding category and description when manually selected
2. INCORRECTLY overriding tax rate even when manually selected

This inconsistency in the backend rule application logic cannot be fixed in the App repository.

Why This Doesnt Block App Deploy

• No App PR caused this issue
• The bug exists in backend code, not frontend
• Reverting any App PR would not fix the issue
• The fix must be made in the backend/API codebase