agent's duplicate detector broke: flagged every uber receipt as duplicate

TL;DR

The match key is too loose: same merchant plus similar amount matches every Uber ride. Tighten the key to merchant plus exact amount plus date (and time where available), so only genuinely identical charges match.

Error

agent's duplicate detector broke: flagged every uber receipt as duplicate

Steps

1. Inspect the match key the detector uses. Expected: you find it matches on merchant alone or merchant plus rounded amount.
2. Tighten the key to merchant plus exact amount plus transaction date. Expected: distinct rides on different days no longer match.
3. Add the transaction time to the key where the feed provides it. Expected: two same-day, same-amount rides still separate correctly.
4. Re-run the detector over the flagged backlog. Expected: the false-positive flood clears, leaving only true duplicates.
5. Add a precision metric: track the share of flags confirmed as true duplicates. Expected: a number that warns you if the key loosens again.

When to use

• A duplicate detector flags an entire vendor's receipts.
• Reviewers are drowning in false-positive duplicate flags.

When not to use

• The flags are true duplicates (merge or delete them).
• Matching fails to find real duplicates (the key is too tight; different fix).

Tool compatibility

• Custom duplicate detectors in audit agents; Expensify, Ramp, Fyle flag queues.

Variant phrasings

Duplicate detector false positives on rideshare

Same failure, vendor-generalized.

Every receipt flagged as duplicate

The flood symptom of a too-loose key.

Why it happens

Rideshare receipts share merchant names and cluster around similar amounts. A key without date and exact amount cannot tell Tuesday's ride from Thursday's, so it calls them all duplicates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8ER5vkduP4weuCUxUv1DGQ