CPG demand planning starts with the sales history

A forecast is a claim about what happened, extended forward. When a planner says the model is off, the conversation goes to the model: the wrong method for a seasonal item, too few periods, a promotion that should have been flagged as an outlier. Those are real, and they are second order.

The first order problem in CPG demand planning is that the history fed into the model was rebuilt by hand this cycle, from four sources that disagree about what a product is and when a week ends. A model trained on a history that changes every time someone rebuilds it cannot be evaluated, because you cannot tell a bad method from a moving input.

What a forecast needs from the history

Four properties, and a history that has them is worth more than a better method applied to one that does not.

1. One product key. Every channel writes the same product a different way, so the history has to resolve retailer item numbers, distributor codes, marketplace ASINs and your own SKUs to one item, with pack conversions stated rather than inferred.
2. One calendar. A retailer week ending Saturday and a fiscal month ending on the 30th produce different weekly totals from identical transactions, so one definition wins and everything converts into it.
3. Defined channels. Distributor shipments, retailer sell-through and direct sales are three different events, and adding them together without saying which is which double counts the same case.
4. A history that stops moving. Late feeds and restated retailer files change last month after you closed it, so the history needs a version you can point a model at and a record of what changed when.

None of that is forecasting work. It is the assembly underneath, and in most brands it is done in a spreadsheet by the person who understands the joins (there is usually exactly one), once a cycle, under time pressure.

Why CPG demand planning fragments across channels

The structural cause is that no single system sees demand. Shipments live in NetSuite or another ERP and describe what left your warehouse. Sell-through arrives from retailer portals and describes what left the shelf, by their item number, on their calendar, days later. Direct demand sits in Shopify and Amazon Seller Central at daily grain. Distributor reports arrive as spreadsheets with a format that changes when someone at the distributor gets a new laptop.

Each of those is correct about its own slice. The demand history is the join, and the join is where the definitions live: which event counts as a sale, whether returns net off the period they were sold in or the period they came back, whether a free case in a promotion is a unit of demand or a cost line. Every answer is defensible, and a spreadsheet column will hold any of them without recording which one was used.

What changes when the history is defined once

Permute is where those definitions get written down. We connect the ERP, the retailer feeds, the marketplaces, the distributor spreadsheets and the rest of the systems we connect, resolve every channel's identifier to one product, and hold the definitions of a unit sold, a return and a promotional case as explicit rules in the Ontology layer rather than as formulas in whichever workbook was open. A planner asks for weekly units by channel for the last two years, on the retail calendar, net of returns, and gets it with the source rows attached: this feed, this file, received at this time. When a retailer restates a month, the history moves and the workspace records that it moved, so an accuracy review can separate a method problem from an input that changed underneath it. Access follows the same rules, so a co-packer with a login sees the products they make and nothing else.

We are not a forecasting engine, and this is the boundary worth being precise about. The projection belongs in a planning tool, a statistical model, or the planner who has run this category for six years. What we supply is the input, and once the input holds still the argument moves from whose number is right to which assumption to make.

How to tell whether your history is the problem

Run one check before touching the model. Take a month you closed three months ago and rebuild its weekly units by channel today, from the same sources, without looking at what you reported at the time.

• The rebuilt total matches what you reported, or you can name every line of the difference and the feed it came from.
• A restated retailer file from two months ago is visible as a restatement rather than absorbed into the current number.
• The same product sold through three channels rolls up to one item without a manual mapping step in between.
• Returns land in a stated period, and the rule is the same one the finance team uses.
• A promotional free case is either demand or cost, consistently, and you can say which without checking the workbook.
• Two people rebuilding the history independently produce the same file.

A brand that fails three or more of those is not going to fix its forecast by changing method. Our How to automate POS data analysis walks through the mapping and calendar work in order, and AI inventory planning: what works and what breaks covers the same fragmentation from the stock side. For the tooling question underneath all of this, CPG analytics software: what to look for before you buy sets out which category of tool does which part.

The forecast improves later, and by less than people expect. What improves immediately is the review: when the history is fixed, a cycle-over-cycle accuracy number means something, and the planner stops defending the data and starts defending the call.

Questions planners ask about sales history