Methodology

The working behind How it works, for anyone who wants to check it before they hand over their receipts: how a receipt is read, how its numbers are checked, how much each kind of receipt counts for, and how a claim is worded. The store-by-store coverage table is on How it works.

Nothing here watches prices

This is the first thing to know, because the obvious guess about what this product is is wrong. There is no scraper. No price is taken from a retailer's website, and no robot sits on one waiting for a number to move.

A lower price only ever enters a way you can point to: you scan or type one you saw, another shopper who opted into sharing scanned it or forwarded a receipt that showed it, a visitor without an account photographed a receipt showing it (those prices carry no owner and count for less), or it appears in a weekly ad. An ad is imported by hand, or, for Best Buy and the Kroger family, read once a day from the retailer's own developer feed, and neither feed runs until we have set its key. Nothing else goes looking on its own. That is why the scanner in the aisle is the centre of the product and not a feature on the side.

What holding your receipts buys you is that the moment one of those things happens, the answer is already worked out: what you paid, what it costs now, whether the retailer will do anything about it, and how long you have. The work happens before you need it, not while you are standing at a shelf.

A receipt is a disclosure document

Not a price tag. When Kohl's prints "you saved $138," it has handed over the exact figure needed to back-solve the price it is claiming. When a Target receipt shows "Circle deal −$3" and "RedCard 5%," it has disclosed the whole discount ladder.

What this product answers, it answers with arithmetic on documents you already own. That matters because the alternative, scraping the retailer, is fragile and controlled by the party we are checking up on. Your receipt is not.

The waterfall

Every line is reconstructed as five rungs: list price, sale price, after coupons, after loyalty, and what you actually paid. Each rung records whether it was printed on the receipt or worked out from the others.

A real Target line that printed only a $20.00 list price and three discounts comes back like this:

The receipt printed $12.35 paid, $0.91 tax and $13.26 total. Those close, so the record is balanced. It arrived as a photograph, so it is Captured, which weighs 0.5 against a signed email's 0.9, and no upload can argue itself into more.

When it refuses to guess

A Kohl's line printed $59.20 paid and "you saved $138.00." Until a person establishes what Kohl's means by "saved," no original price is derived at all, and a note on the line explains the refusal in those words.

Once the semantics are established, the list price comes out at $197.20, marked worked out, back-solved from the saved figure, and marked that way permanently, because it is the retailer's own claim about itself, and that is exactly the number worth challenging against real observed prices.

Reading a photograph

A text reader on our own server (PaddleOCR), plus the receipt's own arithmetic. No cloud vision service, no GPU.

There is no single image treatment that reads every receipt. Enlarging rescues a small capture and mangles one with flash glare; flattening the illumination saves a soft-focus photo and turns a clean scan's 12.99 into 172. Nothing about the image predicts which will work, but the receipt knows, because it prints its own subtotal and total. So the cheapest treatment is tried first and the arithmetic decides whether it worked. Up to four, stopping at the first one that closes.

When it still misreads a single character, the arithmetic repairs it. One receipt came back with its tax line 0.93 read as 6.93. 24.35 + 6.93 does not reach the printed 25.28, and exactly one confusable-digit swap does. A corrected line price is recorded as worked out, never as printed. A tax, subtotal or total has no such mark, so its correction is kept as a note beside the photograph and shown to you when the receipt is read. Either way you can see it was inferred. Three rules keep that honest: the arithmetic has to be broken already, the substitution has to be one the reader genuinely makes, and the fix has to be unique. Two candidates means no correction.

Making two receipts talk to each other

Two receipts from different chains carrying the same barcode have to resolve to one product or nothing downstream can be compared. UPC-A, UPC-E, EAN-13 and GTIN-14 are all normalised to one canonical form, with the check digit verified on the way in. A transposed digit that happens to look plausible would otherwise attach your receipt to the wrong product and quietly move that product's price.

Store-assigned and random-weight barcodes (deli counter, produce scales) are detected and refused as a cross-retailer link. They mean different things at different chains, and bridging on one would merge a rotisserie chicken with something unrelated.

How a claim gets worded

A verified policy produces an assertion. An unverified or stale one produces a question. That rule is enforced in code, and it is the reason the same $18 overpay reads two completely different ways depending on what we know.

And whichever way it reads, you are the one who takes it to the desk. Receipt Snoop writes the words, works out the figure, names the venue and counts the days. It does not contact a retailer on your behalf, at any of them.

The policy model refuses to flatten five distinctions retailers actually make:

Matching at the till is not adjusting after the sale. Walgreens will match its own site for somebody standing at the register and publishes nothing either way about adjusting afterwards. Walmart matches at the register too, and says outright that it will not adjust later. Calling either of those "does not price match" is false; calling it a price-match rule sends you back for something that does not exist. The till-side match is recorded as its own thing. At Walgreens an overpay still comes out as a question you can ask, carrying a note that the shop matches at the register, so next time you know to ask before you pay. At Walmart, which has said no, there is no question to ask, and you get the return-and-rebuy advice described below instead. Office Depot is the same shape as Walgreens: it beats a competitor's price at the register and has published nothing whatsoever about its own price dropping later, so the answer is neither a yes nor a no.

Adjusting is not the same as publishing a deadline. One retailer on file, Lowe's, has been read and confirmed to look at a lower price after you have bought, and names no number of days anywhere it publishes. That is not "unknown," which would discard a confirmed answer, and it is not "no," which would invert one. It is recorded as an adjustment with an empty window, and the consequence is specific: the overpay surfaces, the script asks rather than asserts, no date is quoted, and the advice is to ask promptly rather than to count down. A borrowed number would have been worse than silence. The 90 days on the same page is Lowe's return window, and using it would have told somebody at day 85 they had five days left and somebody at day 100 they were too late. Both invented. It also means the claim can never expire, because you cannot miss a deadline nobody published.

The branch matters. Target matches Target.com and the store you shopped in, and refuses another Target's price. An observation is same-branch, other-branch, or branch unknown, three states, because most shelf scans arrive with no store number and folding them either way is wrong. Unknown still produces a claim, with a caveat naming the one thing that could sink it.

Some retailers will not let us file for you. Macy's states it outright: only requests submitted by the customer are accepted. Lowe's says the same thing in its own words, that it honours only requests from the customer who made the purchase, and Nordstrom will not accept automated requests from third-party services. That is a constraint on us, and it survives into the claim rather than living in a code comment.

An overpay you cannot claim is still worth knowing about. Where a retailer will not adjust but the return window is open, buying it back at the lower price is the remaining move, and the app says so. That needs a return window we have actually read. The three retailers verified to refuse an adjustment, Walmart, Amazon and BJ's, each have one on file, so the advice fires for all three, with the days counted off the return window rather than off an adjustment that does not exist. Once that window closes too, there is genuinely nothing to say, and the feed stays quiet.

What "verified" means, precisely

Every policy record we count as verified carries the URL it was read from, the date it was read, and what read it. Seven do not: Sam's Club, Cub, Food Lion, Stop & Shop, Giant Eagle, ShopRite and Harris Teeter carry no source and no date, because each refuses automated clients or serves them no text, and nothing was read. That is precisely why none of them is counted as verified and none produces a claim with a deadline. Four more that refused automated clients the same way (Trader Joe's, Dick's, King Soopers and Ralphs) were read in a real browser on 7 October 2026 and now carry their source and date. Where that last field is filled it begins claude-research-, claude-go-live-, claude-policies- or ADVERSARIAL REVIEW, with a date. Each means automated research against the retailer's own published page, recording the sentences it relied on. It does not mean a human sat down and read the page. Both are better than an unsourced number in a spreadsheet, and they are not the same thing, so the field says which one it was.

A record is treated as trustworthy for ninety days. After that the app does not delete it or start guessing. It downgrades. The claim goes from an assertion to a question and the money leaves your headline total, until somebody re-reads the page. Retailers revise these quietly and without announcement, which is why the clock is short.

If a window here is wrong, that is a bug and we would rather have the email than the benefit of the doubt.

Corroboration

Anybody can photograph a receipt, and nothing about that act proves the numbers on it. What proves them is other people, shopping independently, seeing the same price.

Two things about how that works are worth stating, because the obvious design of both is wrong.

Agreement means agreeing about a price, and being in the same shop is only the precondition for asking. Two records are eligible to be compared when they are the same store, inside twenty-four hours of each other, and from different people, and the obvious design stops there, which is where it goes wrong. Same store, same day, different person is co-presence, and on its own it hands the pool to anyone willing to fabricate a receipt for a real store on a real Saturday: every honest shopper who was in that store that day would vouch for it. So eligibility is the gate, not the answer. What earns weight is the number itself. The two lines have to resolve to the same product and their shelf prices have to agree to within a cent.

It attaches to the line, not the receipt. Otherwise one genuine item at its real shelf price launders a basket of invented ones sitting beside it. A line earns its own weight or it earns none.

The price compared is the shelf price, before coupons and loyalty, the number everyone in that store sees that day. Witnesses are counted as people, not as rows, so a pile of receipts from one account confirms nothing. And a witness has to have opted into sharing: somebody who opted out is not quietly conscripted into vouching for strangers.

What each tier is worth

Three tiers, not four. There is a fourth in the code, the one a retailer's own account would earn, and nothing constructs it, because there is no account linking. A rung nobody can climb does not belong on a page about what the numbers mean.

Weight is how much a price can move what other people see. It has nothing to do with how usable your own receipt is for your own claim. That is always fully usable, whatever the tier.

Weekly ads

We hold none today. Forty-eight retailers are in the registry and twenty-seven of them are known to publish a weekly ad (sixteen have not been checked). Two, Best Buy and the Kroger family, offer a developer feed we have built a reader for, and neither reader runs until its key is set. There is no public weekly-ad feed in the United States and most of the alternatives are somebody else's terms of service, so the first ads go in by hand. Until one is in, the screen says it is empty and why.

A price from an ad carries its conditions with it. "With your Card" is not your price if you do not hold the card; "2 for $5" is not the price of one. Those are stored, shown with the condition named, and never turned into a claim. When an ad's week ends its prices are retracted.

Point your own tools at it

Scoped access tokens, so your own scripts can read your own receipts through the API. Nothing holding a token can create a receipt or change a price. We have written an MCP bridge on the same tokens, but there is no way for you to download it yet, so for now a token is for your own code. Free. If you would rather use your own model key for the built-in tasks, you can, and that is free too. Reading your own data back out is not something we intend to charge rent on.

Your data

An export containing every receipt, every price you logged and every intake attempt including the failed ones. A delete that actually cascades and tells you how many receipts and photographs it removed. No trackers and no ad pixel. Cloudflare, which carries every request to this site, adds two things of its own: a small script, served from this address, that hides email addresses on pages like this one from spam harvesters; and an instruction to your browser to tell Cloudflare when a connection to this site fails. Staff reads of a basket require a typed reason and are written to a log that the application cannot edit or delete: the database refuses every change to it. Only a deliberate change to the database itself can lift that guard. We have done that twice, each time only to remove personal data that older entries should never have held.