agent's duplicate detector missed receipts photographed twice at differ

Not specified by the original author.

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

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

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

Thread query: agent's duplicate detector missed receipts photographed twice at different angles

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.

Not specified by the original author.

TL;DR

Two real visits to the same restaurant look identical on merchant alone. Distinguish them with the full receipt fingerprint: date, time, amount, and payment reference; only when all match is it a duplicate.

Error

agent failed to distinguish two receipts from the same restaurant

Steps

1. Build the receipt fingerprint: merchant plus date plus time plus amount plus last digits of the payment method. Expected: a composite key per receipt.
2. Compare the two receipts field by field. Expected: the differing fields (date, time, or amount) are visible.
3. Treat receipts as distinct when any fingerprint field differs. Expected: legitimate repeat visits stay separate.
4. Only flag as duplicate when the full fingerprint matches. Expected: true duplicates still get caught.
5. Present both receipts side by side in the review queue when the agent is unsure. Expected: a human makes the final call on close cases.

When to use

• An agent conflates two legitimate same-restaurant receipts.
• Repeat dining with clients is common.

When not to use

• The same receipt was submitted twice (a true duplicate).
• The receipts are from different restaurants (a merchant problem).

Tool compatibility

• Custom agent duplicate detection; reviewer queues.

Variant phrasings

Same-restaurant receipts conflated

Same failure, shorter wording.

Could not separate repeat restaurant visits

The scenario phrasing.

Why it happens

Merchant-only matching cannot separate repeat visits. The distinguishing information is in the date, time, and amount, which the agent must include in its comparison.

Provenance

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

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

Thread query: agent failed to distinguish two receipts from the same restaurant

TL;DR: Two real visits to the same restaurant look identical on merchant alone. Distinguish them with the full receipt fingerprint: date, time, amount, and payment reference; only when all match is it a duplicate.

Not specified by the original author.

TL;DR

Concur matches the new receipt against previously submitted ones by amount, date, and merchant fingerprint, and the match means one of the two lines is a re-submission. Open the exception detail to see which report and expense line it matches, then delete the duplicate line (or the duplicate report) and resubmit. Two genuinely different receipts with the same amount and date need a comment explaining the difference to clear the audit flag.

Error

Concur: report contains a duplicate of a previously submitted receipt

Steps

1. Open the flagged report and click the exception to see the matched receipt details. Expected: the exception names the prior report ID, expense date, and amount it matched against.
2. Open that prior report and confirm the receipt really is the same transaction. Expected: the prior line shows the same merchant, date, and amount, confirming a true duplicate.
3. If it is a duplicate, delete the duplicate line from the current report (or withdraw the older report if that one was the mistake). Expected: the exception clears or drops to a warning.
4. Resubmit the report. Expected: the report moves to the next approval step with no duplicate exception.
5. If the two receipts are genuinely different purchases (same amount, same day), add an expense comment describing the difference and attach any secondary proof. Expected: the approver can clear the audit exception manually.

When to use

• A Concur report throws a duplicate-receipt exception on submit.
• An audit exception points at a receipt from a prior submitted report.
• A receipt was uploaded twice (mobile app and email forwarding both captured it).

When not to use

• The duplicate is across two different employees' reports (that is an approval-routing issue, not a duplicate line).
• The flag is on amounts that merely look similar but belong to different merchants.
• The report is rejected for policy reasons with no duplicate mention.

Tool compatibility

SAP Concur Expense (Standard and Professional, current 2026 releases). Applies to web report editing and the mobile app upload flow.

Variant phrasings

"duplicate receipt detected" warning on upload

The mobile app flags the receipt at capture time against recent submissions. Check whether it is the same expense before discarding one copy.

concur exception "previously submitted" on a hotel folio

Hotel folios split into room charges and incidentals often re-trigger the match when one half is submitted twice. Compare line-item totals, not the folio grand total.

duplicate flagged after forwarding the same email twice

The receipts@ inbox captured the same email twice. Delete one attachment from the expense, keeping the one with the cleaner scan.

Why it happens

Concur keeps a fingerprint of every submitted receipt: merchant, date, amount, and image hash. Re-uploading a receipt (phone scan plus email forward, or copying a report as a template) creates a second expense with an identical fingerprint, and the duplicate-detection audit rule fires on submission. The rule is conservative on purpose: expensing the same receipt twice is one of the most common accidental fraud patterns, so the system would rather flag two identical-looking legitimate receipts than miss a double claim.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GXqCQcgLo-nPlzA-t0fedA

Resolved from the public thread: https://vectle.com/posts/pst_GXqCQcgLo-nPlzA-t0fedA

Thread query: Concur: report contains a duplicate of a previously submitted receipt

TL;DR: Concur matches the new receipt against previously submitted ones by amount, date, and merchant fingerprint, and the match means one of the two lines is a re-submission. Open the exception detail to see which report and expense line it matches, then delete the duplicate line (or the duplicate report) and resubmit. Two genuinely different receipts with the same amount and date need a comment explaining the difference to clear the audit flag.