"Create a rule" is shown after editing invoice category when rule does not apply to invoice

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.76-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: #99164
Email or phone of affected tester (no customers): applausetester+sddd1jsods32@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.
• Create a Control workspace.
• Enable Rules and Invoices.

1. Go to staging.new.expensify.com
2. Open FAB > Send invoice.
3. Send an invoice with merchant and category to any user.
4. Open the invoice.
5. Click Category.
6. Change the category.

Expected Result:

"Create a rule" prompt will not appear when invoice field is edited because rule does not apply to invoice.

Actual Result:

"Create a rule" prompt is shown after editing invoice category when rule does not apply to invoice.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256585_1789088126448.11.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7256585

[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/20f11b59ae2e8a70d501b7d7962d3a67df5906e2210dcbeeaf67e0b8c53fd0ae

[melvin-bot]

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

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

[melvin-bot]

@JS00001 @situchan you have been assigned to this deploy blocker because you reviewed the offending PR: #99164

[melvin-bot]

@Krishna2323 you have been assigned to this deploy blocker because you authored the offending PR: #99164

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #99164 - "Surface "Create a rule" prompt on expense edits to drive merchant rule adoption in-situ" by @Krishna2323 (High confidence)
Related Issues: #96354 (the feature request this PR implemented)

Recommendation: ROLL FORWARD

The feature is brand new (not in production) and the miss is a single missing eligibility check — invoice reports were never excluded from the "Create a rule" callout. A targeted guard is far cheaper and safer than reverting a 50-file feature PR that has follow-up work built on it, and the callout is already gated behind the rulesRevamp beta so exposure is limited.

Assigned: @Krishna2323 (PR author), @situchan and @JS00001 (approving reviewers) — already assigned by Melvin, no change needed
Labels: No changes. DeployBlockerCash is correct and stays (App-side fix). DeployBlocker was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

• PR Surface "Create a rule" prompt on expense edits to drive merchant rule adoption in-situ #99164 introduced this entire feature: MerchantRuleSuggestionBanner, useMerchantRuleSuggestion, MerchantRuleSuggestionUtils, the MerchantRuleSuggestion Onyx key, and the trackMerchantRuleSuggestion calls inside UpdateMoneyRequest.ts. The "Create a rule" copy in the report (createRuleFromExpenseAction / createRuleFromExpensePrompt) was added by this PR across all src/languages/* files.
• It merged 2026-09-10 and is listed in the current deploy checklist (Deploy Checklist: New Expensify 2026-09-10 #100893) for 9.4.76-0 — exactly the version reported. The issue is staging-only / N/A in production, consistent with a brand-new feature.
• The PR's own test plan has a "F. Visibility" section listing where the banner must not appear (non-admins, Rules disabled, personal/self-DM expenses, no merchant, multi-expense list view). Invoices were simply not on that list, so the case was never gated and never tested.
• Grepping the whole feature surface for any invoice handling returns nothing:
  • MerchantRuleSuggestion.ts, useMerchantRuleSuggestion.ts, MerchantRuleSuggestionUtils.ts, and MerchantRuleSuggestionBanner.tsx contain no reference to isInvoice, isInvoiceReport, or CONST.REPORT.TYPE.INVOICE.

Verification

Affected files, all created or modified by #99164:

1. src/libs/actions/MerchantRuleSuggestion.ts#L22-L47 — records the edit that produces the offer. Its only bail-out is line 33: !transactionID || !reportID || !isControlPolicy(policy) || !arePolicyRulesEnabled(policy, policyCategories). Nothing about report type.
2. src/hooks/useMerchantRuleSuggestion.ts#L62 — the display-side gate, canCreateMerchantRule, repeats the same four policy/beta conditions and likewise never asks whether the expense is an invoice.
3. src/libs/actions/IOU/UpdateMoneyRequest.ts#L1341-L1343 — the category path from the repro steps, calling trackMerchantRuleSuggestion unconditionally after API.write.
4. src/pages/iou/request/step/DynamicIOURequestStepCategory.tsx#L191-L212 — the RHP that calls updateMoneyRequestCategory, passing the report's policy straight through.

Confirmed each of these paths is in the PR's file list (gh pr view 99164 --json files): src/libs/actions/MerchantRuleSuggestion.ts (+119, new), src/hooks/useMerchantRuleSuggestion.ts (+85, new), src/libs/actions/IOU/UpdateMoneyRequest.ts (+48/-1), src/components/MerchantRuleSuggestionBanner.tsx (+212, new).

Root Cause

An invoice sent from a Control workspace lives on a report whose policyID is the sender's Control workspace. So when the sender edits the invoice's category:

1. DynamicIOURequestStepCategory calls updateMoneyRequestCategory with that Control policy and its policyCategories.
2. trackMerchantRuleSuggestion evaluates its gate at MerchantRuleSuggestion.ts#L33. isControlPolicy(policy) is true and arePolicyRulesEnabled(policy, policyCategories) is true (Rules are enabled on the workspace), so the offer is written to Onyx.
3. useMerchantRuleSuggestion re-checks the same policy-shaped conditions at line 62 and also passes, so the banner renders.

Every gate in the feature reasons about the workspace (Control? Rules on? write access? beta?) and about the transaction (merchant present? field actually changed?). None reasons about the report type, which is the only thing that distinguishes an invoice from an expense here. Since merchant rules only govern expenses, the callout appears on an invoice, and taking the offer would seed a real merchant rule on the sender's workspace from invoice data.

MoneyRequestView — the view this banner is shown alongside, and which #99164 also touched — already establishes the precedent for exactly this check: isInvoice at line 302, used to suppress invoice-inapplicable fields at line 532 and line 564. The new feature just didn't follow it.

Suggested fix

Bail out of trackMerchantRuleSuggestion for invoice reports, so nothing is ever written to Onyx and no banner can render. All six trackMerchantRuleSuggestion call sites in UpdateMoneyRequest.ts (billable L441, reimbursable L514, tag L954, tax L1094, category L1343, description L1435) already have parentReport — the IOU/invoice report — in scope, so it can be passed down and checked with isInvoiceReport(parentReport) without threading any new data through.

Worth adding the matching guard in useMerchantRuleSuggestion too, as defense in depth for any offer already sitting in Onyx, and adding invoices to the "F. Visibility" list in the PR's test plan so it's covered going forward.