Rules - Billable is auto disabled after applying to existing unsubmitted expenses

[lanitochka17]

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.31-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: #83005
Email or phone of affected tester (no customers): isodjnosidjiojiojiso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Rules in More features.
• Set Billable default to Billable in Rules.
• Admin invites member to the workspace.

1. Go to staging.new.expensify.com
2. [Member] Create an expense with Apple merchant in workspace chat.
3. [Admin] Go to workspace settings > Rules.
4. [Admin] Click Add merchant rule.
5. [Admin] Create a merchant rule that changes merchant to Banana when merchant is Apple. Do not add anything to Billable field.
6. [Admin] Open the created rule.
7. [Admin] Enable Apply to existing unsubmitted expenses > Save rule.
8. [Member] Open the expense.

Expected Result:

System message will only show changes with merchant.

Actual Result:

System message shows "changed... the expense to "non-billable" (previously "non-billable")", when Billable is left untouched in the created rule.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7093937_1772649595149.4.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @NicMendonca (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.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a merchant rule is created that only changes the merchant name (without modifying the billable field), and "Apply to existing unsubmitted expenses" is enabled, the system message incorrectly shows "changed the expense to 'non-billable' (previously 'non-billable')" — even though billable was never touched.

What is the root cause of that problem?

There are two compounding bugs:

1. Client-side: null vs undefined mismatch in rule API serialization (src/libs/actions/Policy/Rules.ts)

When a rule is created without setting billable, mapFormFieldsToRuleForOnyx (line 63) converts the undefined form value to null via form.billable ?? null. Later, when the rule is edited or re-saved, this null value is loaded back into the form. Then mapFormFieldsToRuleForAPI (line 94) checks form.billable !== undefined — but null !== undefined is true, so the null billable value leaks into the API payload even though the user never set it.

2. Client-side: No equality guard in modified expense message rendering (src/libs/ModifiedExpenseMessage.ts)

At line 498, hasModifiedBillable only checks whether oldBillable and billable keys exist in the report action original message (using the in operator). It never checks whether the values are actually different. And buildMessageFragmentForValue (line 66) has no early return when oldValue === newValue — it falls through to the else branch and produces "changed the expense to X (previously X)". Compare this to how tags are handled at line 454, which does check if (newTag !== oldTag).

When the backend receives a rule application request that includes (or implies) billable with shouldUpdateMatchingTransactions=true, it creates a MODIFIED_EXPENSE report action containing both oldBillable and billable fields with the same value. The frontend then renders this as a nonsensical "changed" message.

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

Fix 1 — src/libs/actions/Policy/Rules.ts: Change the guard in mapFormFieldsToRuleForAPI from strict inequality to a nullish check for both billable and reimbursable:

• Line 91: form.reimbursable !== undefined → form.reimbursable != null (or form.reimbursable !== undefined && form.reimbursable !== null)
• Line 94: form.billable !== undefined → form.billable != null

This prevents null values (from Onyx round-tripping) from being sent to the API.

Fix 2 — src/libs/ModifiedExpenseMessage.ts: Add an equality guard so that when oldBillable and billable have the same value, no "changed" message is generated. The simplest approach is to add && reportActionOriginalMessage.oldBillable !== reportActionOriginalMessage.billable to the hasModifiedBillable condition at line 498. The same fix should be applied to hasModifiedReimbursable at line 518.

What alternative solutions did you explore? (Optional)

• Adding the equality guard inside buildMessageFragmentForValue itself (an early if (newValue === oldValue) return;) would be more broadly protective for all fields, but could mask other bugs where old and new values shouldn't be the same.
• Changing mapFormFieldsToRuleForOnyx to store undefined instead of null — but this would conflict with Onyx's handling of undefined values (they get stripped during serialization).

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.