What scan-based trading is
Scan-based trading (SBT) is a consignment arrangement where the vendor owns the product sitting on the retailer's shelf until it scans at the register, at which point the sale triggers payment. It's also called pay-on-scan, and the first time I reconciled an SBT account I had to unlearn everything I knew about how a sale gets recorded. There was no purchase order, no receiving deduction, no invoice in the normal sense. The cash register was the invoice.
The model is common in direct-store-delivery (DSD) categories: beverages, bread, salty snacks, and magazines. A bread vendor like Bimbo or a beverage DSD route restocks the shelf, but the retailer doesn't buy the product on delivery. The retailer pays for each unit only when a shopper buys it, and whatever doesn't sell goes back to the vendor. If you searched "what is scan based trading" because a retailer proposed it and the terms felt upside down, they are, relative to a normal wholesale deal.
How pay-on-scan works
In a conventional deal, the retailer buys the inventory, owns it, and eats the loss on anything that spoils, gets stolen, or never sells. SBT flips that. The vendor retains ownership of the on-shelf inventory, so the retailer carries almost no inventory risk and pays out of money it has already collected from the shopper.
Run a week at a single store on a bread SKU to see the cash mechanics. The shelf price is $4.49 and the retailer's margin is 25%, so the vendor's scan price (what the retailer pays per unit) is $3.37.
| Line | Value |
|---|---|
| Units delivered to shelf | 60 |
| Units scanned (sold) | 52 |
| Unsold / stale (returned) | 8 |
| Shelf price | $4.49 |
| Vendor scan price (per unit) | $3.37 |
| Retailer pays vendor | 52 × $3.37 = $175.24 |
| Retailer keeps (margin) | 52 × $1.12 = $58.24 |
| Vendor revenue | $175.24 |
| Vendor loss on 8 stale units | vendor's cost × 8 |
The retailer paid for exactly 52 units, the ones that rang up. The 8 stale units never cost the retailer a cent. The vendor absorbs that shrink, which is the whole point of the model from the retailer's side. Compare that to a normal wholesale arrangement, where the retailer would have paid for all 60 on delivery and taken the retail margin hit on the 8 that didn't move.
Who carries the risk
SBT moves three things off the retailer's books and onto the vendor's: inventory ownership, shrink, and the working capital tied up in product on the shelf. For the retailer that's close to a free option. For the vendor it's a trade. You give up the certainty of a sell-in sale in exchange for the shelf space and, usually, more control over your own merchandising.
The catch for the vendor is that you're now financing the retailer's shelf and trusting their scan data to be accurate. Every dollar you get paid depends on a register reading the right SKU. Scan errors, shopper substitutions at self-checkout, theft recorded as "didn't scan," and mislabeled returns all come out of the vendor's pocket, because under SBT a unit that didn't scan is, by definition, a unit you don't get paid for even if it physically left the store.
This is why reconciliation against scan data is the entire game in SBT. The vendor's only proof of a sale is the retailer's POS feed, so the vendor has to tie deliveries minus returns to scanned units, store by store, and chase the gaps. I treated those gaps the way I treated unauthorized billback deductions: assume nothing, match every line, and dispute the variance before it ages out.
Why scan-based trading matters to a brand-side analyst
For the analyst, SBT changes what "sales" even means in the data. Your revenue is scanned units, not shipped units, so your sell-in shipment numbers and your actual paid revenue diverge by exactly the unsold-and- returned volume. If you benchmark an SBT account against a wholesale account without adjusting for that, the SBT account will look like it has worse margin or worse velocity when really it just has a different definition of a sale.
It also means the syndicated and POS scan data isn't just a market-share signal on an SBT account. It's the literal basis for what the retailer owes you. A 2% scan-reporting error on a high-volume DSD line is a 2% revenue error, not a rounding issue. Watching delivered-versus-scanned variance by store is how you catch a store that's underreporting before it becomes a quarter of leaked revenue.
Where Scout fits
Because SBT revenue is defined by scan data, the gap between what you delivered and what actually scanned is the number that matters most, and it's the hardest to see when deliveries live in one system and scans live in another. Scout connects your retailer POS or SPINS data to your shipment and trade-spend side, so you can watch delivered-versus-scanned variance and the true cost of an SBT account in one place. To be clear on scope: Scout measures and analyzes that variance and cost. It is not a deduction-recovery or claims-matching tool, it won't reconcile a disputed scan claim with the retailer for you, and it isn't an EDI or DSD settlement system.
The short version
- Scan-based trading is consignment: the vendor owns the on-shelf inventory until it scans at the register (pay-on-scan), and unsold product goes back to the vendor.
- It's standard in DSD categories like beverages, bread, and snacks. The retailer offloads inventory ownership, shrink, and working capital onto the vendor.
- The vendor's revenue is scanned units, not shipped units, so scan-data accuracy is the whole game. Reconcile delivered-versus-scanned by store, or scan errors quietly become lost revenue.