For brands, wholesalers and distributors selling into retail

Retailer Sell-Through Data: Seeing What Actually Sold, Store by Store

Your ERP knows exactly what each retailer ordered from you, because you invoiced it. That is sell-in. It tells you nothing about how many units consumers actually bought last week, which stores are sitting on twelve weeks of cover, or which stores have been out of stock since the last delivery. Those answers live in the retailer’s systems, and they reach you, if at all, as a portal download, an emailed spreadsheet or an EDI report in a format nobody else uses.

Most suppliers who get this data use a fraction of it. Someone downloads a report on Monday, pastes it into a workbook, fixes the item codes by hand, and the result is a week late and slightly wrong. This page covers the gap between sell-in, sell-through and stock on hand, how retailer data actually arrives, what it takes to turn many different sources into one trustworthy weekly picture, the contractual and competition limits on using it, and the decisions it should drive.

Review Your Retailer Data (03) 9003 0111

The Shape of the Problem

3 numbers

Sell-in, sell-through, stock on hand

Only the first one is in your own systems by default

4 to 6 sources

Typical for a mid sized supplier

Portals, emailed files, EDI reports, marketplace APIs and buying groups, each in its own format

7 fields

In the common data model

Retailer, store, week, your SKU, units, value and stock on hand

1 queue

For unmatched items and stores

Every code that cannot be mapped is held for review, never silently dropped

Why Sell-In Alone Misleads You

Sell-in, sell-through and stock on hand measure three different things. Planning from the first one alone produces errors that look like demand.

Phantom demand from pipeline fill

When a retailer ranges a new line, opens stores or builds stock ahead of a promotion, your invoices jump. It looks like demand, and forecasts built on sell-in carry it forward. If consumers are buying at half that rate, the retailer stops ordering for weeks while it sells down, and your forecast is now badly wrong in both directions. Sell-through separates the consumer rate from the pipeline movement, which is the only way to tell a successful launch from a full warehouse.

Overstocked stores hide behind a healthy total

A retailer’s total stock of your line can look reasonable while forty stores hold three months of cover and thirty hold none. Central replenishment often allocates on averages or on the store grade rather than on actual store rate of sale. Store level stock on hand, divided by recent weekly sales, shows weeks of cover per store. That is the figure that tells you where markdowns are coming and where sales are being lost, and it is invisible in sell-in.

Stockouts you never saw

A store that is out of stock records zero sales. If you only look at total sales, the zero looks like weak demand rather than lost demand, and the line can end up being deranged for underperforming when it was simply not on the shelf. Combining stock on hand with sales lets you flag store weeks with zero stock and zero sales separately from store weeks with stock and no sales, which is a very different conversation with the buyer.

Buyers already have the numbers

The retailer’s category team sees sell-through, margin and stock for your lines and your competitors’ lines every week. If you arrive at a ranging review with only your invoice history, you are negotiating with less information than the person across the table. Having your own clean view of rate of sale per store, promotional uplift and out of stock rates lets you check their claims, propose specific fixes and argue for distribution with evidence rather than optimism.

How a Reliable Sell-Through Pipeline Works

Six building blocks. Each one fixes a specific way that retailer data goes wrong between the retailer’s system and your decision.

Every file captured, on time

Collect from every source

Each retailer is set up with its own collection method. Portal reports are downloaded on schedule where the portal allows automated access, or uploaded by a person to a monitored drop location where it does not. Emailed spreadsheets go to a dedicated mailbox and are picked up automatically. EDI sales and inventory reports, such as EANCOM SLSRPT and INVRPT messages where a retailer supports them, arrive through your EDI provider. Online retailers and marketplaces are polled by API. Each expected file has a due time, and a missing one raises an alert.

One table, every retailer

Normalise into one model

Every source is translated into the same structure: retailer, store, week ending date, your SKU, units sold, sales value and stock on hand, plus the original file and row it came from. Columns are mapped per retailer and per file version, because retailers change report layouts without notice. Values are recorded with their basis, whether at retail or at cost and whether GST inclusive or exclusive, so nothing is added together that should not be. Raw files are kept so any figure can be traced back.

Retailer codes become your SKUs

Map item codes through GTIN

Retailers report against their own article numbers, and sometimes against a barcode. The match uses the GTIN wherever it is present, because it is the one identifier both sides share, then a maintained cross reference of retailer item code to your SKU. Inner and outer carton barcodes, superseded GTINs after a pack change, and retailer specific bundles are all handled explicitly. Anything that does not match goes to an unmatched queue with the units and value at stake, so the biggest gaps are fixed first.

Stores that stay correct

Maintain the store master

Each retailer’s stores are held in a store master with the retailer’s store code, name, state, format, opening date, closing date and any grade or cluster you use. When a new store code appears it is queued for setup rather than guessed. Closures stop being expected in the data, renames and code changes are linked to the same physical store, and like for like comparisons exclude stores that were not trading in both periods. State is needed for rep territories and for any regional promotion analysis.

Weeks that compare

Align the calendars

Retailers report in their own retail weeks, which may end on Saturday, Sunday or another day, grouped into 4-4-5 or similar periods, with an occasional 53 week year. Your finance calendar is probably months. Every row is tagged with the retailer’s week, a standard week in your own calendar, and the period and financial year it falls into. Where week end days differ, the data is compared at the week level with the difference noted, rather than split into days that the source never provided.

Trustworthy every Monday

Check quality before anyone uses it

Each load runs checks before it is published: missing weeks or stores compared with the last period, duplicate files or restated weeks that would double count, negative sales from returns or corrections, stock on hand that jumps implausibly, values that do not reconcile to the file total, and totals that move sharply against prior weeks. Restated weeks replace the earlier version rather than adding to it. Failed checks hold that retailer’s data and tell the owner, while the other retailers publish normally.

What the Data Is For

Task	Traditional	Integrated	Notes
Replenishment proposals	Wait for the retailer’s order	Suggested order per store or DC	Based on rate of sale, stock on hand and lead time, sent to the buyer or used directly where you manage replenishment.
Rep visit priorities	Visit by habit or route	List of stores with gaps	Stores with zero stock, high cover or falling sales ranked first, pushed to the rep’s app or weekly email.
Promotion uplift	Compare invoice spikes	Uplift on a store baseline	Promoted weeks compared with a baseline excluding pipeline fill, with post promotion dip and stockouts measured too.
Scan deal and rebate claims	Accept the retailer’s figure	Units checked per store week	Claimed units compared with reported scan data for the deal dates and stores before the claim is approved.
Ranging reviews	Total sales by line	Rate of sale per stocked store	Normalised for distribution and out of stock weeks, so a line is judged on demand where it was available.
Demand forecasting	Forecast from sell-in	Forecast from consumer demand	Sell-through drives the base forecast, retailer stock levels predict when orders will resume or slow.
New product launch	Judged on first orders	Weekly sell-through by store	Shows within weeks whether the launch is consumer pull or pipeline, while there is still time to act.
Aged and slow stock in store	Found at markdown time	Flagged by weeks of cover	Gives time to propose a transfer, a promotion or a pause in supply before the retailer asks for markdown support.

What to Get Right

Using data beyond what the retailer allows

Retailer data usually comes under your trading terms, the portal terms of use or a separate data agreement, and those often limit what you can use it for and who may see it. Some restrict sharing with third parties such as agencies, brokers or software providers. Read the terms for each retailer before building, record the permitted uses in the data model, and restrict access by role. If the terms are unclear, ask the retailer or a lawyer.

Sharing one retailer’s data with another

Showing one retailer another retailer’s sales, pricing or promotional plans, even in summary, can raise confidentiality concerns and, depending on the circumstances, competition law issues under the Competition and Consumer Act. Keep each retailer’s data visible only to the people who need it, aggregate carefully in anything that leaves the business, and get legal advice before you share cross retailer insights with any customer. This is general information, not legal advice.

Adding values on different bases

One retailer reports sales at retail including GST, another at retail excluding GST, a third at your cost price, and the portal may show markdown value separately. Adding them together produces a number that means nothing. Record the basis of every value at load, convert only where the conversion is sound, and in most reports lead with units, which are comparable across retailers in a way that dollars often are not.

Silent gaps from unmatched codes

If unmapped item codes or unknown stores are dropped rather than queued, totals fall quietly and nobody knows why. New lines, pack changes and new stores are exactly when this happens, and exactly when the data matters most. Report the unmatched units and value each week alongside the published figures, and give one person clear responsibility for clearing the queue every week.

Double counting restated weeks

Retailers resend files, correct earlier weeks and sometimes send the same week in two reports. Loading each file as new data inflates sales. Every load should identify the retailer, week and store range it covers, replace any earlier version for that same scope, and keep the history of what changed. A duplicate check on file content catches the same file sent twice.

Over building for one or two retailers

If you supply one or two retailers with clean, consistent reports, a well structured spreadsheet with a lookup table for item codes, a store list and a standard weekly routine may be all you need. Automated collection and a proper data model earn their cost when there are several sources, store level data, many SKUs, or decisions like claims and replenishment depending on it.

How Yes AI Approaches Sell-Through Data

Source inventory first

We list every retailer, what data each provides, how it arrives, how often, at what level, and on what terms. Gaps such as independents with no data are recorded honestly, along with what a rep or a buying group could realistically fill.

One model you own

Retailer data is normalised into a documented model in a database or warehouse you control, with item and store cross references your team can maintain, and raw files kept for audit. Your reporting tool, planners and rep app all read from the same tables.

Collection run and monitored by us

Collection, mapping, checks and publishing run on a managed cloud automation layer we operate, with alerts for late files, failed checks and growing unmatched queues, and a weekly status summary showing which retailers loaded cleanly and which need attention.

Access matched to the terms

Role based access so each retailer’s data is seen only by the people its terms allow, with a record of who can see what, designed with you and checked against each agreement, and reviewed whenever a retailer changes its terms.

From Monday Spreadsheets to a Weekly Picture

Five steps. The first two or three retailers are usually live within six to ten weeks, depending on how the data arrives and how clean your item master is.

Inventory sources and terms

Every retailer, its data, delivery method, frequency, level of detail, value basis and the terms that govern its use.

Agree the model and calendars

The common fields, value bases, store master, week and period mapping, and who owns each cross reference.

Build collection and mapping

Automated collection per source, GTIN and item code matching, store setup and the unmatched queue.

Load history and check it

Back history loaded where available and reconciled to the retailer’s own totals and to your sell-in.

Publish, use, extend

Weekly reports for sales, supply and finance, then replenishment proposals, rep lists and claim checks.

FAQ

What is the difference between sell-in and sell-through?

Sell-in is what you sold to the retailer, recorded on your own invoices. Sell-through, also called sell-out, is what the retailer sold to consumers, recorded at the retailer’s point of sale. Stock on hand is what remains in the retailer’s stores and distribution centres. Over a long enough period sell-in and sell-through roughly converge, but in any given month they can differ sharply because of pipeline fill, promotions, new stores and destocking. Planning from sell-in alone mistakes those movements for consumer demand.

How do retailers provide sales and stock data to suppliers?

It varies by retailer. Larger retailers commonly offer a supplier portal with downloadable sales and stock reports, sometimes at store and week level. Others email a scheduled spreadsheet. Some send EDI sales and inventory report messages, such as EANCOM SLSRPT and INVRPT, to suppliers who are set up for them. Online retailers and marketplaces may provide an API or a seller report. Buying groups sometimes consolidate members’ data. Many independents provide nothing, so their demand has to be inferred from orders or rep visits.

Can we automate downloads from a retailer’s supplier portal?

Sometimes. Some portals offer scheduled report delivery by email or file transfer, or an API, and those are the best route. Others are designed for a person to log in, and their terms of use may prohibit automated access or sharing logins. Check the terms before automating anything. Where automation is not allowed, a person downloading on a schedule and dropping the file into a monitored location still removes most of the manual work, because everything after the download is automated.

How do we match the retailer’s item codes to our SKUs?

Use the GTIN wherever the retailer’s data includes it, because it is the identifier both sides share. Where it does not, keep a cross reference of each retailer’s article number to your SKU, usually built from the retailer’s item listing or your EDI setup. Watch for inner and outer barcodes, GTIN changes after a pack or size change, and retailer bundles. Hold anything unmatched in a queue with its units and value so the most important gaps are fixed first.

Can we share sell-through insights with other retailers?

Be careful. Retailer data is usually supplied for limited purposes under confidentiality terms, and sharing one retailer’s sales, pricing or promotional information with another can breach those terms and, in some circumstances, raise competition law concerns. Market level insights built from properly aggregated and licensed sources are different from passing on a named customer’s figures. Get legal advice before sharing anything derived from one retailer’s data outside your business or with a different customer. This is general information only.

Why do our sell-through figures not match the retailer’s?

The usual causes are a different value basis, such as retail including GST against retail excluding GST or cost; different week end days or period boundaries; unmatched item codes or new stores missing from your totals; restated weeks loaded twice or not replaced; and returns netted off differently. A good pipeline reconciles each load to the file’s own totals and keeps the raw file, so a discrepancy can be traced to a specific store, item and week rather than argued about.

Is this worth building if we only supply a couple of retailers?

Possibly not. With one or two retailers sending consistent weekly reports, a well structured spreadsheet with a store list, an item code lookup and a fixed weekly routine can serve you well. The case for automation grows with the number of sources, the volume of stores and SKUs, how often report layouts change, and whether money depends on the data, as it does with scan deal claims and vendor managed replenishment. We will tell you plainly which side of that line you are on.

See What Your Retailers Actually Sold

Book a call. We review which retailers send you data, how it arrives, what it would take to bring it into one weekly view, and whether a spreadsheet process would be enough. You keep the source inventory either way.

Book a Retailer Data Review (03) 9003 0111

All discussions held in confidence. Australian-based consultants.