## 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

```text
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