Duplicate invoice claims: what counts as the same purchase?

A duplicate invoice claim is easy to describe and surprisingly easy to define badly. The obvious case is one image submitted twice. The harder case is the same purchase photographed again, exported as a new PDF, cropped to a different line, or submitted by another account. Harder still is the invoice that legitimately supports two separate claims.

The right question is not “have we seen these bytes before?” It is “what does this program consider one use of purchase evidence?”

Four duplicate patterns

Exact resubmission. The same file is uploaded twice after a timeout or double tap. API idempotency should stop this before it becomes a fraud decision.

Same page, changed image. A participant crops, rotates or recompresses the invoice. Perceptual image matching can link visually equivalent evidence even when file hashes differ.

Same purchase, new capture. Two phone photos show the same paper invoice. Image similarity may be weaker, so structured identity—seller, invoice number, date, buyer and total—becomes important.

Overlapping claim. One invoice contains ten eligible units. A participant claims six today and the remaining four later. Whether that is legitimate depends on program terms and line-level consumption records.

Define uniqueness at the right level

A whole-invoice rule is simple: once an invoice is accepted, no part can be claimed again. That works for programs requiring one claim per document. It fails when a single invoice is allowed to fund several product-specific claims.

Line-level uniqueness requires more structure. The system must identify the line, eligible quantity, previously consumed quantity and claim history. A synthetic record might say:

{
  "seller_id": "synthetic-distributor-12",
  "invoice_number": "INV-20481",
  "line_product": "AX-40",
  "purchased_quantity": 10,
  "previously_claimed_quantity": 6,
  "available_quantity": 4
}

This is a program design example, not a promise of automatic cross-claim quantity accounting in Steve. The downstream incentive or loyalty system should remain the authority for consumed entitlements unless the implementation explicitly assigns that responsibility elsewhere.

Use several signals, not one magic key

Signal	Useful for	Failure mode
Client submission ID	Network retries	Does not catch another account
Cryptographic file hash	Exact file	Breaks after any image change
Perceptual image hash	Crops/recompression	Different photo of same paper
Seller + invoice number	Purchase identity	Number collisions across sellers/branches
Buyer + date + total	Supporting similarity	Common totals and dates collide
Product line + quantity	Partial claims	Requires reliable line matching

Choose identity fields per workflow. Steve supports perceptual image matching and configurable identity fingerprints across a workflow’s history. Similarity should generate an explainable flag: which fields matched, which differed, and which prior submission is relevant.

Avoid automatic rejection by coincidence

Invoice numbers are not globally unique. Totals repeat. A distributor can issue a credit note that references the original invoice. A company may have several branches with overlapping sequences. Blocking on one matching field produces avoidable false rejections.

Use a decision policy:

• exact client retry: deduplicate technically
• strong visual or identity match: flag with the prior evidence
• partial similarity: review, especially for high-value claims
• same invoice with permitted unused lines: let the incentive system decide remaining eligibility
• unreadable identity fields: request better evidence or review; do not label fraud

The reviewer screen should show both documents, extracted identity fields, prior decision and participant context. “Duplicate” without the matched evidence is not an actionable reason.

Build a proper test set

Include known groups: the same scan recompressed, two photos of the same invoice, similar invoices from one distributor, reused numbering from different branches, credit notes and legitimate partial claims. Label group membership and the expected program outcome. Only then can duplicate precision and recall be measured meaningfully.

Steve’s fraud controls match visual duplicates and workflow-specific identity fields. The review queue presents the match beside the new evidence and logs the decision. Steve can pass verified evidence downstream; the incentive platform should own remaining claim entitlement and payout.

If duplicate invoice claims are a known problem, book a discovery call with anonymized examples of both abuse and legitimate repeats. The first task is to define “same purchase” for your rules. The model comes after that.