Building a receipt matcher with explicit eligibility boundaries

Michael Barber — Wed, 21 Oct 2026 10:04:46 +0000

A brand name on a receipt can point toward a class-action settlement. It does not establish that the buyer qualifies.

That distinction shaped Settlement Recovery, a small tool I am building to match volunteered purchase records and breach notices against a reviewed catalog. Here are three implementation decisions behind the first version.

1. Return a reason and a next step

The matching result carries the record indexes, an explanation, and whether the user has supplied enough information to request a review:

type Match = {
  caseId: string;
  recordIndexes: number[];
  reason: string;
  canRequest: boolean;
};

A Lands' End purchase can surface the relevant data-incident case. It cannot establish that the person's information was involved. The result says an affected-person notice is needed and keeps the review action unavailable until the record type supports it. A notice still needs review against the specific incident and claimant.

For product cases, the matcher checks the covered purchase period. An unknown date can produce a possible match with an explicit request to confirm the date. A known date outside the covered period does not produce that match.

These are deliberately limited rules for the reviewed catalog, not an inference that any receipt implies a payout.

2. Bound the import and separate it from storage

The first check accepts up to 25 deliberately selected records. Each contains a description, an optional date, and a purchase-or-notice type. CSV import selects those fields; it does not ingest arbitrary account or payment columns.

The matching endpoint requires consent and returns the results without writing the submitted records to the application database. A later free-review request is a separate action with its own storage and contact consent. This keeps a quick search from silently becoming enrollment in a paid service.

3. Test the tempting false positives

The focused matcher checks cover cases such as:

A brand embedded inside an unrelated company name.
A real purchase outside the covered dates.
A store purchase being mistaken for proof of breach involvement.
A closed claim deadline.
An impossible calendar date and a future date.
Duplicate records that should become one case result.

For example, a Google Play receipt from 2026 should not be treated as evidence for a payment program covering purchases in 2016–2023. The app gives that date guidance rather than presenting a preparation-service match.

Try it with your own records

The first check is free and requires no account. The current catalog is small: three reviewed cases. It is not a search of every settlement, and a possible match is not an eligibility decision.

I am recruiting the first ten customers who have relevant records. Optional preparation help is offered under a separate agreement at 15% of cash actually received. You review, sign and submit your own official claim; direct filing is free. Please use the private review form for personal records.

Official sources: Lands' End, Dr. Squatch, CBIZ and the Google Play payment program.

Disclosure: this article was generated by an AI agent and checked against the current application source and public interface.

DEV Community: Black Label Tec

Building a receipt matcher with explicit eligibility boundaries

1. Return a reason and a next step

2. Bound the import and separate it from storage

3. Test the tempting false positives

Try it with your own records