Expense rules - Non-existing category can be imported but does not apply to expense

[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.36-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: #95105
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Enable Rules.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules.
3. Click More > Import merchant rules.
4. Upload a file that contains "Updated category" that is not in category list.
5. Open the expense rule.
   → Category field shows the imported category which does not exist in workspace.
6. Go to workspace chat.
7. Create an expense with the merchant that matches the expense rule.
8. Open the expense.
   → Category field does not update when category field in expense rule shows the imported category.

Expected Result:

Imported category in expense rule should be auto added to category list when the imported category does not exist in the workspace.

Actual Result:

Imported category in expense rule is not auto added to category list when the imported category does not exist in the workspace.
In Step 5, Category field shows the imported category which does not exist in workspace.
In Step 8, Category field does not update when category field in expense rule shows the imported category.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210645_1784288303486!random_merchants_true_false__1_.csv

Bug7210645_1784288303482.1.mp4

View all open jobs on GitHub

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

[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/427dbae82f73bb0c88b4e7b93791bb99de07cb13ee004a189e49666541e5827e

https://platform.applause.com/services/links/v1/external/3fbdc013cd3b2271b1687d362e0f5584bbd547844da54a5b288d44139591b007

[melvin-bot]

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

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

The new merchant-rules spreadsheet import flow (from #95105) takes the "Updated category" cell as free text and never checks it against the workspace's category list, nor creates a missing category. So a rule can be stored with a category name that doesn't exist on the policy. The rule UI just echoes that stored string, but when an expense matches the rule the backend has no real category to apply — so nothing is applied.

This is specific to the import flow. Manual rule creation can't hit this because its category picker only offers existing enabled policy categories, so a manual rule can never reference a non-existent category.

Evidence

• Import builds each rule with the raw cell value, no membership check: ImportedMerchantRulesPage.tsx:175 → :193. The only validation in this page checks that a merchant filter + at least one action column are mapped — never that the category exists.
• The action just JSON-stringifies and POSTs the rules; it never touches the policy category collection: Rules.ts importMerchantRulesSpreadsheet.
• Manual flow constrains the category to existing enabled policy categories only: AddCategoryPage.tsx:29-36.
• A repo-wide search of the rules code finds no category-creation call (no CreateWorkspaceCategories/CREATE_POLICY_CATEGORY) anywhere in the import path.

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

There's a product decision here — pick one:

1. Auto-create the missing category (matches what the reporter expects). On import, for any "Updated category" not already in policyCategories, create it (optimistically via the categories action + Onyx, and/or have the backend ImportMerchantRulesSpreadsheet command create it). This keeps rules consistent with manual creation where the category always exists.
2. Reject/skip unknown categories — surface a validation error (or drop the category cell) when the imported category isn't a real policy category, mirroring the manual picker's constraint.

Either fix lives primarily in App (the import page + action), but if option 1 is chosen the backend companion command (ImportMerchantRulesSpreadsheet, Auth#22642 / Web-Expensify#54176) likely also needs to create the category server-side — that half can't be verified from the App repo and should be checked by an internal engineer with backend access.

Since this is a deploy blocker on a brand-new feature that isn't in production yet, the fastest way to unblock the deploy is to revert #95105 and re-land it with the category-handling decided, rather than rushing a fix under the deploy-blocker clock.

Notes / alternatives considered

• Could the category be applied by name rather than requiring a real category? No — the manual flow's constraint shows the intended model is that rule categories reference existing policy categories, so silently storing an unknown name is the defect regardless of which option is chosen.
• Confidence: High on the App-side root cause (verified in code). The exact backend behavior of the import command (silently drop vs. attempt to create the unknown category) is unverified — Auth/Web-Expensify aren't available in this workspace.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96389) to create a draft PR (pick option 1 or 2 first).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[NicolasBonet]

@MelvinBot implement option #1