Duplicate & Similarity Detection

Resubmitted receipts are a common type of receipt fraud: the same receipt claimed twice by one user, shared between users, or lightly edited to slip past exact-match checks. When the check runs, Taggun compares a submission against prior stored receipts and returns accepted candidates with similarity scores for your workflow to review.

Availability

📘

Availability

Duplicate & Similarity Detection is part of the fraud detection suite, included on the Advanced plan and above. Enable Receipt Similarity in your account Feature Settings when it is available on your plan. See Plans & Feature Access.

How It Works

1. Data extraction — Taggun extracts text and supporting data from the image.
2. Similarity analysis — the extracted data is compared against eligible prior stored receipts in the applicable account-wide scope (or campaign, for validation endpoints).
3. Scoring — a similarity score between 0 and 1 is generated for each match found, and any scores over a threshold of 0.8 are eligible for entry into the response.
4. Match decision — a prior receipt is flagged as similar when its score clears Taggun's similarity thresholds and key fields line up. Thresholds are fixed, not adjusted per merchant.

Reading the score

A high score alone is not the complete match decision. Taggun applies fixed similarity-score gates together with exact field or metadata conditions. Do not assume that changing one field guarantees that a prior receipt will not be returned. Treat returned matches as review signals.

🚧

This check needs stored receipts

Duplicate and similarity detection compares the current submission against eligible previously stored receipts. See Security, Privacy & Data Residency for storage and retention choices.

Scope of Comparison

When checking runs without a containerId, Taggun uses eligible prior stored receipts in the applicable account-wide scope. A containerId restricts that scope. On validation endpoints, a configured similarity check is scoped to the campaign. Same-referenceId candidates are excluded as documented below.

Request

On extraction endpoints, no request changes are needed once the feature is enabled. On validation endpoints, opt in per campaign via the fraud detection rule:

{
  "fraudDetection": {
    "allowSimilarityCheck": true
  }
}

referenceId and userId are accepted on extraction and validation requests; see Common Request Parameters and Validate Receipts for their contract declarations. containerId is extraction-only and is defined in Common Request Parameters:

Common Scenarios

1. Two different images of the same receipt

Two users photograph and submit the same physical receipt — an innocent shared-household mistake or a deliberate double claim.

Example input pair: two photographs of one physical receipt. The image alone does not establish who submitted it or why.

{
  "trackingId": "T-001",
  "entities": {
    "similarReceipts": [
      { "referenceId": "R-001", "userId": "U-001", "trackingId": "T-002", "similarityScore": 1 }
    ]
  }
}

2. Attempted bypass with slight modification

A user edits one detail (e.g. the transaction date) and resubmits. The API may return a high similarity score; the value below is illustrative, not a guaranteed result for an edit.

Example input pair: the transaction date differs between the two versions. This does not guarantee a particular score or response.

{
  "trackingId": "T-003",
  "entities": {
    "similarReceipts": [
      { "referenceId": "R-002", "userId": "U-002", "trackingId": "T-004", "similarityScore": 0.98 }
    ]
  }
}

3. Multiple similar submissions by the same user

One user submits the same receipt several times — forgetfulness or repeated claiming. Returned matches that pass Taggun's internal gates appear in similarReceipts; the public contract does not promise an exhaustive or unbounded candidate list.

{
  "trackingId": "T-005",
  "entities": {
    "similarReceipts": [
      { "referenceId": "R-003", "userId": "U-003", "trackingId": "T-006", "similarityScore": 1 },
      { "referenceId": "R-004", "userId": "U-003", "trackingId": "T-007", "similarityScore": 1 }
    ]
  }
}

4. Multiple similar submissions by different users

Near-identical receipts arriving from several userIds suggests coordinated fraud.

{
  "trackingId": "T-008",
  "entities": {
    "similarReceipts": [
      { "referenceId": "R-005", "userId": "U-004", "trackingId": "T-009", "similarityScore": 0.97 },
      { "referenceId": "R-006", "userId": "U-005", "trackingId": "T-010", "similarityScore": 0.96 },
      { "referenceId": "R-007", "userId": "U-006", "trackingId": "T-011", "similarityScore": 0.95 }
    ]
  }
}

5. Lower-scoring match that needs review

Two legitimate purchases can still be similar. This example was returned as a match with a score of 0.82, so Taggun's configured similarity gates were met; use the returned match as a review signal rather than assuming a lower score is automatically safe.

Example input pair: different receipts from the same merchant can share a strong visual pattern. The image alone does not establish authenticity.

{
  "trackingId": "T-012",
  "entities": {
    "similarReceipts": [
      { "referenceId": "R-008", "userId": "U-007", "trackingId": "T-013", "similarityScore": 0.82 }
    ]
  }
}

Presence in similarReceipts means the match logic accepted the candidate. Do not invent a universal customer-side "safe band" from the score alone.

Response

Both similarity properties are optional and may be omitted. When present, verbose extraction uses entities.similarReceipts and Receipt Validation uses root similarReceipts. A property may be empty or present without usable match data. Guard for an array before iterating and treat an empty array as no returned candidates.

Verbose extraction returns similarity matches under entities.similarReceipts. Receipt validation returns them at root as similarReceipts; the validation schema permits either an array or null. Compare the other fraud-result shapes in Data Fields That Taggun Extracts.

When no similar receipts are found, verbose extraction can return:

{
  "trackingId": "T-20241001-8439425",
  "entities": {
    "similarReceipts": []
  }
}

Receipt validation can return:

{
  "trackingId": "T-20241001-8439425",
  "similarReceipts": []
}

The validation schema also permits "similarReceipts": null.

Use Cases

• Promotions — surface potential repeat submissions for review or campaign decisions.
• Expense management — surface potential duplicate reimbursement claims.

Best Practices

• Send userId when you want matched receipts, when available, to retain an end-user association for cross-user investigation.
• Route flagged receipts to a review process rather than hard-rejecting at moderate scores.

FAQ

Will Taggun flag two different people submitting the same receipt?
Similarity matching can return prior matches. Include userId when you want returned matches, when available, to carry the end-user association needed for cross-user investigation; do not assume that userId changes candidate selection.

What if receipts from one merchant are always very similar?
Similar layouts alone are not the full match decision. Taggun also applies fixed similarity-score gates together with exact field or metadata conditions. Do not assume that changing one field guarantees that a prior receipt will not be returned. Review returned matches in business context.

Need something not covered here? Contact [email protected] — see Contacting Support.