Should sales forecasts be centralised? The question comes up in many SME manufacturers at the point where the sales team's spreadsheet, logistics' spreadsheet and production's spreadsheet start to contradict each other. The usual answer is to build a single figure, approved at head office, that everyone applies. Appealing on paper; in practice, it works at some levels of detail and fails at others.
We have seen a local forecast, built by a logistics manager to organise deliveries between distribution platforms, give excellent results within its scope, then become counter-productive as soon as it was shared with the plant. The problem was neither the method nor the person: it was the level of detail.
This article compares centralised forecasting with local, item-by-item forecasting, sets out the strengths and limits of each approach, and suggests a way to organise the loop between sales and planning so that the two can coexist.
Why centralising sales forecasts seems obvious
Sales forecasts drive the whole supply chain: stock levels, supplier orders, the production plan, transport bookings. A poor estimate costs on both sides: overstock that ties up cash and takes up floor space, and stockouts that lose sales, lower the service level and damage the brand.
Against this, centralising meets three legitimate needs:
- One single figure: sales, finance, production and logistics work from the same basis, instead of three diverging Excel files.
- The law of large numbers: at the level of a product family or a site, individual errors cancel out. An overestimated product A and an underestimated product B give a correct total.
- A process: a monthly calendar, an owner, a measure of the error. This is the principle of sales and operations planning, or S&OP.
Salesforce's guide to sales forecasting sums up these general good practices. It does not say at what level of detail the forecast must be accurate, and that is where everything is decided.
A local forecast that worked
A logistics manager organises deliveries between distribution platforms. The forecasts drive transport bookings, the organisation of the loading dock teams, and costs. What has to be forecast is volume: cases, pallets, linear metres of truck space.
The method came down to three steps:
- Choose a reference week in the sales history, representative of normal activity.
- Apply a correction coefficient based on experience: current trend, commercial context.
- Adjust for external factors: seasonality, public holidays, known events.
The result: an accurate forecast, suited to the need, which made it possible to size trucks and teams without surprises. Human expertise played a central role: the coefficient came from the manager's judgement, not from a model, and it was right.
Why this forecast failed once shared with the plant
Encouraged by this success, the logistics manager shared the forecasts with the plant to help it anticipate production. The idea seemed sound; it proved counter-productive, for a reason of granularity.
A forecast that is reliable in total volume can be very inaccurate item by item. For logistics, that does not matter: a truck carries product A or product B alike. For the plant, it is the opposite. It does not make “pallets”; it releases manufacturing orders for specific items, with different bills of materials, components and workstation times.
In practice:
- product A, overestimated, is made in excess: stock tied up, materials consumed for nothing;
- product B, underestimated, runs short: stockout, late orders, urgent changeovers to catch up.
The total was right, the service level fell, and the plant had to spend money correcting what the overall forecast had hidden.
| Link in the chain | What it has to forecast | Useful level of detail | Tolerance of error per item |
|---|---|---|---|
| Logistics, transport | Volumes: pallets, linear metres, parcels | Site, week, day | High: errors cancel out |
| Production | Quantities per item and per period | Item, week | Low: each item has its manufacturing order and components |
| Procurement | Component and material requirements | Component, week, supplier lead time | Low, amplified by bills of materials |
| Management, finance | Revenue, overall load | Family, month, quarter | High |
Centralise or forecast locally: strengths and limits
| Criterion | Centralised forecast | Local forecast, item by item |
|---|---|---|
| Strengths | One figure, consistency between departments, errors cancelled out in aggregate, a clear process and owner | Accuracy at plant level, field knowledge of customers and items, responsiveness |
| Weaknesses | Inaccurate item by item, slow to react, remote from customers, seen as imposed | Multiple files, no consolidated view, dependence on one person, individual bias not measured |
| Best used for | S&OP, budget, annual capacity, transport and volumes | MPS, MRP run, release of manufacturing orders, component purchasing |
The point is not to pick a side, but to recognise that a forecast must be accurate at the level where it is used, and that the same base can be read at several levels.
Organising the loop between sales and planning
The organisation that works is a base forecast at the finest level, item by item and month by month, which each link in the chain aggregates as it needs. Logistics adds it up in pallets, management in families and revenue, planning uses the item level as it is. You do not centralise the figure; you centralise the database and the calendar.
The monthly cycle we recommend:
- Week 1: sales enter their forecasts by customer and by item, separating the baseline from promotions and one-off deals (we explain this distinction in our article on sales forecasting in the food industry). Every change is dated and commented.
- Week 2: planning consolidates, compares with history and with last month's actuals, flags abnormal gaps (an item tripled with no explanation) and projects stock.
- Week 3: decisions in a short meeting, sales and production together. Flagged gaps are explained or corrected, and load is compared with capacity.
- Week 4: the approved forecast goes into the MPS and the MRP run. It is frozen for the month; later changes are logged and go through a decision, not a silent edit.
Two rules keep the loop alive: measure the error at each level (by item for planning, by family for management) and let human expertise correct the calculation rather than the other way round. The logistics manager's coefficient was right because they knew their flow; the same judgement, applied item by item by the people who know the customers, is missing from many centralised forecasts.
What we see in the field on forecasting
Three lessons keep coming up in the forecasting projects we support.
The level of aggregation decides everything. A forecast that is reliable overall can be ineffective at a more detailed level. Before talking about tools or methods, write down in black and white who needs what, at what level of detail and over what horizon.
Human expertise remains an asset. In many cases, the intuition and experience of a manager who knows the customers do better than an unsupervised statistical model. The tool should make it possible to record that judgement, date it and measure it, not replace it.
Each link in the chain has its own needs. A forecast that works for logistics does not necessarily work for production. Adjustments made by one department without telling the others are the main source of drift. In a project to digitise a forecasting spreadsheet in the food industry, it was the change history, cell by cell, that made the sales team's adjustments visible to the planners.
Conclusion: forecast at the level where it is used
Centralising sales forecasts is neither a good nor a bad idea in itself. What matters is the level of detail: centralise the database and the calendar, yes; impose an overall figure on a plant that makes item by item, no. The right organisation is a detailed, shared, commented forecast that each link in the chain aggregates in its own way, with the error measured where it costs.
This is how Planiprev works: a forecast item by item and month by month, baseline kept separate from promotions, entered by sales and consolidated by planning, with the change history, comments, projected stock and cover. Totals by family or by site are read from the same base. See how Planiprev organises the sales / planning loop or request a demo.