Using Retailer POS Data in CPG Sales Planning

Most CPG sales plans are built on shipments, because shipments are what the ERP knows. Shipments are also the one number that reliably lies to you about demand, since they measure when inventory moved into a retailer rather than when a shopper bought anything.

Retailer POS data fixes that, and it introduces three problems of its own: it never reconciles cleanly to shipments, it arrives at different grains from different retailers, and it tempts teams into planning at a level of detail the forecast cannot support. This is how to bring it in anyway.

Key takeaways

• Plan on consumption, forecast shipments from it. Consumption is the demand signal; shipments are consumption plus a pipeline change.
• Shipments and POS will not tie out, and chasing an exact reconciliation wastes a quarter. Track the gap as inventory, not as error.
• Pick the coarsest grain that answers the question. Store-week is right for execution, chain-month for planning.
• Distribution change is the most common thing mistaken for demand change. Always plan on velocity per store, then multiply by planned doors.

What POS data actually is

Point-of-sale data is the record of units scanned at a register, usually delivered by the retailer through a portal or a feed, sometimes weekly and sometimes daily. Retail Link at Walmart, the vendor portals at Kroger and Target, and distributor portals like KeHE Connect all carry a version of it.

It is different from syndicated data, which is a projected market estimate built from a sample. POS is a census of the stores it covers and nothing outside them. That distinction matters more than most teams treat it: your Kroger POS is the truth about Kroger and says nothing about the rest of the market, while a syndicated read covers the market and is an estimate everywhere.

Why POS and shipments will never tie out

The gap between what you shipped and what scanned is inventory sitting somewhere in the retailer's system, plus shrink, plus timing. It is not an error to be eliminated. It is a real quantity worth tracking on its own.

The useful discipline is to compute weeks of supply in the retailer's system each period, rather than to explain the variance line by line. Four weeks of cover drifting to nine is a forward buy that will suppress your next two months of orders, and a sales plan built on shipment trend will miss it entirely. See consumption versus shipment data for the full framing.

Bringing retailer POS data into the sales planning cycle

Retailer POS data arrives at store-item-week or store-item-day. Planning at that grain is almost always a mistake, because the forecast error at store-week is enormous and the plan inherits it.

• Store-week: execution work only. Voids, out-of-stocks, price compliance, display verification.
• Chain-week: promotion measurement. Enough resolution to see a lift and its decay, coarse enough to be stable.
• Chain-month or chain-period: the sales plan. Aggregate up, never plan down.

The rule that saves the most rework: build the plan in velocity per store per week, then multiply by planned distribution. A plan built directly in total units bakes in your current door count, and every distribution change then requires rebuilding it rather than changing one input.

A worked plan line

A 16 oz fermented salsa at Sprouts, planning the next quarter. Trailing 12 weeks show 3.2 units per store per week across 412 doors, with two promoted weeks at 4.1. Non-promoted velocity is 3.0.

The plan: 3.0 base velocity, 430 doors by mid-quarter from a known expansion, two promoted weeks at a 1.35 lift factor derived from the trailing promotions rather than from the vendor's claim. That yields roughly 12 weeks times 430 stores times 3.0, plus the incremental from two promoted weeks, giving about 16,400 units of consumption.

Shipments are then consumption plus the planned pipeline change: 18 new doors need an initial fill, and the promotion needs about three weeks of forward cover. That is roughly 1,300 units of pipeline on top, so the shipment forecast is near 17,700. Those two numbers being different is the point, and a plan that reports only one of them will be defended as wrong by whoever holds the other.

Where teams get burned

• Reading a distribution gain as a demand gain. Total units rose 14 percent and velocity fell 3 percent is a very different quarter than the reverse.
• Planning the promotion at last year's lift. Lift decays with repetition, and the same offer run quarterly returns less each time.
• Treating a portal outage as a demand drop. Missing weeks read as zeros in most extract pipelines, and a zero is indistinguishable from a real collapse unless somebody checks coverage.
• Mixing daily and weekly retailers in one aggregate without aligning week-ending dates. Retailers do not share a calendar, and a one-day offset moves a promotion into the wrong week.

How Scout handles it

Scout ingests retailer POS and distributor feeds, aligns them to a common calendar, and keeps velocity per store per week as the planning unit with distribution as a separate multiplier. The shipment-to-consumption gap is reported as weeks of retailer cover rather than as a reconciliation error, so a forward buy is visible before it suppresses the next order cycle.

Related reading: POS data, what is syndicated data, and retail demand forecasting.