Rules - Expense preview shows "Cash" label for time expense in Preview matches list

[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 Time and Rules in workspace settings > More features.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a time expense.
4. Open the expense.
5. Click Merchant.
6. Enter Apple and save it.
7. Go to workspace settings > Rules.
8. Click Add merchant rule.
9. Click the first Merchant field, enter Apple and click Save.
10. Click Preview matches.

Expected Result:

Expense preview will show "Time" label for time expense.

Actual Result:

Expense preview shows "Time" label for time expense in Preview matches list.

This issue also happens with distance and per diem expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7093999_1772653224239.13.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @luacmartins

[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 @bfitzexpensify (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: #83005 - "Enable merchant rules v3" by @luacmartins (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

This requires a backend fix. The frontend code is working correctly - the issue is that the backend API GET_TRANSACTIONS_MATCHING_CODING_RULE does not return complete transaction data with the fields necessary to determine transaction types (time, distance, per diem). Rolling forward with a backend fix is more appropriate than reverting the frontend PR.

Labels: Removing DeployBlockerCash label as this requires a backend fix, not an App repository fix.

📋 Detailed Analysis

Evidence

PR #83005 simply removed the production gate for merchant rules (removed the if (isProduction) return null check), enabling the merchant rules feature including the "Preview matches" functionality.

When users now click "Preview matches" in the merchant rules flow, the PreviewMatchesPage component calls getTransactionsMatchingCodingRule() which makes a backend API call to GET_TRANSACTIONS_MATCHING_CODING_RULE. This API returns matching transactions, but appears to not include complete transaction data.

Verification

I examined the files involved:

• src/pages/workspace/rules/MerchantRules/PreviewMatchesPage.tsx - Displays transactions in preview
• src/components/TransactionItemRow/DataCells/TypeCell.tsx - Renders the type label
• src/libs/TransactionUtils/index.ts - Contains getTransactionType() logic

The getTransactionType() function correctly checks:

1. isTimeRequest() - checks if transaction.comment.type === CONST.TRANSACTION.TYPE.TIME
2. isDistanceRequest() - checks if transaction.comment.type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && transaction.comment.customUnit.name === CONST.CUSTOM_UNITS.NAME_DISTANCE
3. isPerDiemRequest() - checks if transaction.comment.type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && transaction.comment.customUnit.name === CONST.CUSTOM_UNITS.NAME_PER_DIEM_INTERNATIONAL
4. Falls back to checking card fields and defaults to "Cash"

Root Cause

The backend API GET_TRANSACTIONS_MATCHING_CODING_RULE is not returning the comment field (or not returning it with complete data) in the transaction objects. This causes the frontend to incorrectly classify time/distance/per diem transactions as "Cash" transactions because it cannot determine the actual transaction type.

This is a backend bug - the API needs to be updated to return complete transaction objects including the comment field with type and customUnit data.