## TL;DR

The detector compares image hashes or visual similarity, but two photos of the same receipt taken at different angles look like different images, so the duplicate slips through. Match on transaction identity instead: merchant, date, amount, and payment method form a fingerprint that is identical regardless of the photo angle. Image comparison becomes a secondary signal, not the primary key.

## Error

```text
agent's duplicate detector missed receipts photographed twice at different angles
```

## Steps

1. Confirm the miss: find two expenses with different receipt photos that share merchant, date, and amount. Expected: the pair is visibly the same purchase.
2. Check what the detector keyed on (image hash, perceptual hash, or visual embedding). Expected: the image-based key explains the miss.
3. Change the primary duplicate key to the transaction fingerprint: normalized merchant, date, amount, and payment method. Expected: the pair now matches on identity.
4. Keep image comparison as a secondary check to catch same-transaction re-uploads with edited amounts. Expected: the two layers catch both miss types.
5. Re-run detection over the audited period. Expected: the angle-variant duplicates are flagged.

## When to use

- A duplicate detector misses re-photographed receipts.
- The same receipt uploaded from phone and email both pass detection.
- Tuning duplicate detection recall.

## When not to use

- The detector over-flags distinct receipts (a precision problem, opposite fix).
- The duplicates are exact file copies (image hashing already catches those).
- The miss is across different employees (a policy question).

## Tool compatibility

Applies to custom audit agents with duplicate detection (Python, agent frameworks; current 2026 releases).

### Variant phrasings

### same receipt submitted as two different photos

Transaction-identity matching catches what image matching misses.

### duplicate detector fooled by a re-scan

Angle, lighting, and crop changes defeat visual comparison. Match the transaction.

### phone photo and email forward both passed as unique

Two captures of one purchase. The merchant-date-amount fingerprint unifies them.

## Why it happens

Perceptual and cryptographic image hashes are sensitive to capture conditions: angle, lighting, crop, and resolution all change the hash. Two photos of the same receipt are legitimately different images of the same transaction. Transaction identity (who, when, how much, how paid) is invariant across captures, which is why it is the robust primary key, with image comparison demoted to catching tampered re-uploads.

## Provenance

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