Lot Numbers Answer the Recall Question. Serial Numbers Answer the Returns Question.
Every retailer already tracks lot numbers, because recalls force the issue: when a batch goes bad, you need to know which units belong to it. Fewer retailers track serial numbers, because nothing forces that issue. That lasts until someone works out that a return desk which can’t tell one unit of a product from another is a return desk that can’t tell a real return from a fake one.
Those are two different questions, and it matters that they stay different:
A lot number answers: is this unit part of a known population? That’s the recall question. It’s a class-level answer: every unit in lot L2847 gets the same one.
A serial number answers: is this the unit I sold you? That’s the returns question. It’s a unit-level answer: no two units share one.
A return desk that only has lot numbers can confirm a returned item is a real, GS1-recognized product. It cannot confirm the specific unit in the customer’s hand is the specific unit that left the store. That gap is where return fraud lives, and it’s a bigger line item than most loss-prevention conversations treat it as.
What the gap actually costs
Four patterns, all defeated the same way once a serial number and a sale record exist:
Receipt fraud. A shopper pairs a legitimate receipt with a different, unpurchased unit: pulled from a shelf, a friend’s unopened one, sometimes a stolen one. The receipt is real. The transaction happened. The unit in their hand just isn’t the one it paid for. Lot-level checking can’t catch this, because the swapped unit is from the same lot, same product, same everything a lot number describes. Serial-level checking catches it immediately: the specific serial being returned was never the one recorded against that sale.
Double returns. The same unit gets returned, resold, and returned again, sometimes at the same store, sometimes after being picked back up somewhere in between. Without a per-unit record of “this one already came back,” every return is independently plausible. With one, the second attempt reports back instantly as already returned.
Cross-retailer arbitrage. Buy where it’s cheap, or where a promotion just ran, and return where the refund policy is friendlier or the price is higher. This one is subtle because nothing about the returned unit looks wrong. It’s genuinely the product, genuinely unopened, genuinely purchased somewhere. It just wasn’t purchased here. A serial check scoped to your own sales says exactly that: your store has no record of ever selling this unit, however convincing the story at the counter is.
Counterfeit-swap returns. Buy the real thing, open it at home, put a counterfeit back in the box, return the box. The packaging is untouched. The receipt matches the SKU. If the return desk never scans anything past the box, this one is invisible. If it scans the product itself, the swapped serial has no sale behind it and the fraud surfaces at the counter instead of after the refund clears.
Notice the common shape: every one of these produces a unit that looks fine at the SKU level and wrong at the serial level. That’s not a coincidence. It’s the entire reason lot-and-SKU-level checking, which is what most loss-prevention tooling actually does today, structurally cannot see this category of fraud. It isn’t a matter of the check needing to run more carefully. It’s asking a question one level too coarse to contain the answer.
Where the serial has to live
That last pattern, the counterfeit swap, exposes a design decision that’s easy to get backwards: the serial number has to be readable off the product itself, not just the packaging.
A code printed only on the outer box protects the box. It has nothing to say about what’s inside it. If a return desk’s whole verification consists of scanning a barcode on packaging that survives the swap untouched, serialization has bought nothing against the exact fraud pattern it was supposed to stop. On-product marking, the code applied to or bonded with the item rather than just its wrapper, is what makes “scan the thing being handed back to you” mean anything.
This is also the deciding factor in which GS1 Application Identifiers actually belong in your Digital Link QR in the first place. Our short answer: perishables get a best-before date, and almost everything else gets a serial number, a unit-level pointer into a resolver rather than a payload stuffed into the code itself. A serial only pays off at the return desk, though, if it was designed to be scanned off the product a customer is holding, not off packaging that’s already back at the store before anyone checks it. And the QR sizing math is exactly why a serial-as-pointer design costs so little on the pack: ten or so characters, not the full transaction history.
What “verified” actually means here
To be specific rather than hand-wavy about what a returns-verification check can and can’t tell you: it answers from your own sales record, not a universal ledger. A unit your store never sold reports back as never sold or unrecognized, which is precisely the signal that catches cross-retailer arbitrage, receipt fraud, and the swap pattern, because in every one of those cases the honest answer really is “we have no record of selling this.”
There’s exactly one case where that tenant-scoped answer deliberately breaks the rule: an open recall. If the unit belongs to a recalled lot, that’s surfaced regardless of who’s asking or who sold it, because a recall is public safety information, not one retailer’s private sales data. The recall question and the returns question stay separate questions, but a recall always wins the argument.
The one-call version of all of this
Practically, this collapses to one scan at the return desk: GTIN plus serial in, a decision back: sold, already returned, never sold, unrecognized, or recalled. No separate lookup, no manual cross-reference against yesterday’s transaction log. The technical detail (the actual API, the decision states, the ingestion paths for getting sale records in) is in our returns verification documentation for anyone integrating it into a POS or return-desk workflow.
The bigger point stands on its own without the product pitch: if your loss-prevention stack can answer “is this a real product from a real lot” but not “is this the exact unit we sold,” return fraud has a door standing open that nobody’s watching, because nobody built the lock for a question that specific. Recall answers one question. Returns need the other one.