Potential duplicates is not flagged when create same amount cash and card expenses

[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.25-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94777
Email or phone of affected tester (no customers): applausetester+thcard@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

Preconditions:

• Create a workspace and connect a company card feed; import some transactions.

1. Open https://staging.new.expensify.com/
2. Open the report that contains imported card transactions
3. Create a cash expense that is the same with one card transactions

Expected Result:

they are flagged as duplicates

Actual Result:

Potential Duplicates error is not flagged

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196060_1782880604775.duplicates.mp4

View all open jobs on GitHub

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

[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/380e08216fc0a621681ec26ebe23d82333677e0b60e304847aa80aef6d5775ef

[MelvinBot]

Issue Analysis

Root cause: This is a backend duplicate-detection issue, not an App bug. The App does not decide which transactions are duplicates — the "Potential Duplicates" flag is driven entirely by a duplicatedTransaction violation that the server attaches to a transaction. When a cash expense matching a company-card transaction is not flagged, it's because the backend never emitted that violation for the cash‑vs‑card pair. No App code path suppresses it.

Where the fix goes: Outside the App repo — in the server-side violation/duplicate-detection engine that compares transactions (amount/date/merchant) and emits the duplicatedTransaction violation. This needs a separate internal investigation by an engineer with backend access. There is no App-side change that resolves this.

Note on PR #94777: #94777 ("Skip reimbursable step in duplicate resolver for managed card transactions") is unrelated to the cause. It is additive (0 deletions in TransactionUtils) and only changes the resolution wizard that runs after a duplicate is already flagged. It cannot affect whether detection fires. The bug was merely found during that PR's QA.

Investigation details / evidence

The App only ever reads the server-supplied violation; it never computes duplicates by amount comparison:

• TransactionUtils/index.ts:1973-1990 — isDuplicate just searches the transaction's violations array for DUPLICATED_TRANSACTION and checks it isn't dismissed. No computation.
• TransactionUtils/index.ts:2088-2111 — hasDuplicateTransactions reads violations straight from Onyx. Purely a read.
• Violations/ViolationsUtils.ts — the App's client-side violation engine (getViolationsOnyxData) computes category/tag/tax/receipt violations locally but contains zero references to DUPLICATED_TRANSACTION. Duplicate detection is intentionally left to the server.

There is no cash-vs-card gating in the App's detection/display path. The only card-specific branch in duplicate handling is inside the merge resolver (which review step to show for a managed card) — the code #94777 touched — which runs only after a duplicate is already flagged.

Data flow: server compares transactions and emits duplicatedTransaction with a data.duplicates array → App receives it via Onyx → App renders the "Review duplicates" flag. If the server doesn't emit it for the cash+card pair, the App has nothing to show.

Likely backend angle to check (for the internal investigator): whether the detection routine compares manual/cash expenses against imported company‑card transactions at all, or whether the two are bucketed/filtered separately, or whether a field mismatch (e.g. merchant/date on the imported transaction vs. the freshly created cash expense) prevents a match.

Confidence: High that this is backend-side (direct file:line evidence in App). The exact backend matching criteria need confirmation in the backend repo, which isn't accessible here.

---

Next Steps: This requires a backend fix — please escalate to an internal engineer with access to the server-side violation engine. Reply with @MelvinBot <feedback> to refine this analysis.

[melvin-bot]

Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

12 days overdue. Walking. Toward. The. Light...

[melvin-bot]

this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!