In short: Forecast consumption decides how much of a period's forecast an incoming sales order cancels, and the backward and forward windows that control it are usually inherited from an implementation nobody in the room today attended. Set those windows from the measured gap between an order's requested date and the forecast bucket it should be netting against, since that distribution is the thing the parameter is trying to describe. Two failure modes account for most of the money: forecast that no order ever reached, which keeps generating supply after the week has gone, and order volume that consumed a forecast belonging to a neighbouring period, which removes supply the following week still needs. The weekly check is one reconciliation line per item, location and bucket, where original forecast, consumed quantity, remaining forecast and open orders have to add up to the demand the supply plan actually received.
It is Tuesday morning. The supply plan for the Lyon distribution centre wants 620 units of a line for week 34. The demand plan for that week says 400. Open sales orders against week 34 total 260. Nobody in the room can account for the 620, and the planner who configured this two ERP upgrades ago now works somewhere else.
The arithmetic is 400 plus 260 minus 40. Forty units of forecast were cancelled by the orders that arrived, and the other 360 are still standing in the plan next to the orders that were supposed to replace them. The rule that produced the number 40 is forecast consumption. On most implementations it gets set once, at go-live, by somebody with eleven other configuration decisions to finish that week, and then it runs untouched for a decade while the ordering behaviour it describes changes underneath it.
What the netting rule is actually deciding
Independent demand reaches the supply plan twice. It arrives first as a forecast, weeks or months ahead, and then again as a sales order with a customer and a requested date on it. Orlicky set out the netting logic that has to sit between them in 1975, and the problem has not changed since: the same unit of demand must not be planned for twice.
Forecast consumption is the rule that decides how much of a forecast a given order has already accounted for. Four settings control it in almost every system, whatever the field names happen to be. The direction, meaning whether an order may reach backwards in time for forecast, forwards, or both. The backward window in days. The forward window in days. And the level at which the match is attempted, which is usually a combination of item, plant or distribution centre, and sometimes a customer group.
Work an ordinary case. Forecast of 400 units sits on week 34 at Lyon. A customer order for 260 arrives with a requested delivery date on the Wednesday of week 34, and the backward and forward windows are both five days. The order reaches into week 34, finds the forecast, and consumes 260 of it. What passes to supply is 140 of remaining forecast plus 260 of firm order, totalling 400. That is the behaviour everyone assumes they have.
Now move the requested date to the Monday of week 35 and set backward consumption to two days. The order reaches back as far as the Saturday of week 34, finds nothing because the forecast sits on the Monday, and consumes nothing. Week 34 keeps its full 400. Week 35 gets 260 on top of whatever forecast it already carried. The supply plan reads 660 across the two weeks for a customer who is going to buy 400. Two days of parameter is the whole difference.
Set the window from a gap you can measure
The backward and forward windows are a description of how your customers order relative to how you spread the forecast. They deserve to be set from data, and the data takes an afternoon to pull.
Take three months of sales order lines with the item, the location, the requested delivery date and the date the order was created. For each line, work out the gap between the requested date and the start of the forecast bucket it ought to have netted against. Plot the distribution of that gap by item family. Then compare its shape against the windows configured on those items.
The typical finding in a business with monthly forecast buckets is a hockey stick. The forecast is spread evenly across the weeks of the month because nobody ever changed the default distribution profile, while sixty or seventy percent of the order volume lands in the final five working days. Under an even spread, the orders arriving in the last week consume the forecast placed on that week, exhaust it, and then reach backwards into the earlier weeks under whatever window you allowed. Where the window is short, the early weeks keep forecast that no order will ever claim, and the last week goes short of forecast so its incoming orders arrive as pure additions.
That pattern does not respond to tuning the window, because the window is being asked to correct a spreading assumption. The fix is the profile the forecast is distributed with. Take the actual within-period order arrival curve for each family, use it as the distribution profile, and the consumption windows suddenly have very little work to do.
Where the gap distribution is genuinely wide, set the windows at something like its eightieth percentile in each direction and accept that the tail will misbehave. A window set at the mean of a skewed distribution will be too short about half the time, and the half where it is too short is the half carrying the large orders.
The forecast no order ever reached
Every week, some forecast goes unconsumed. Demand was overstated, a customer ordered a substitute, an order slipped into the next period. The question that matters is what your system does with the remainder when the bucket closes.
Two behaviours are common. The remainder drops silently, which is the benign case. Or it rolls into a past due bucket, which MRP reads as demand required immediately, and that is where the damage happens.
Put numbers on it. A location forecast at 400 a week that consistently receives 320 in orders strands 80 units a week. Over a thirteen week quarter that is 1,040 units of demand that no customer ever asked for. If it accumulates in past due, every MRP run sees a requirement of over a thousand units needed today, generates supply against it, and does so again next week with the number a little larger. Planners learn to ignore past due rows because they are always wrong, which means they also ignore the ones that are real.
The diagnostic is cheap. Sum the unconsumed forecast remaining on all buckets whose date has passed, by location, and value it at standard cost. In a business of any size the figure is usually large enough to end the argument about whether this is worth an hour.
When an order eats next week's forecast
The opposite failure is quieter and it moves in a two week rhythm.
A single large order lands on the Thursday of week 34 for 900 units against a weekly forecast of 400. It consumes the 400 in its own bucket, then reaches forward under a ten day window and takes the 400 sitting on week 35 and a further 100 from week 36. Week 34 now shows 900 of firm demand and no forecast. Week 35 shows nothing at all, because its forecast has gone and its orders have not arrived yet. The supply plan sees a hole, cancels or reschedules planned orders into it, and the factory or the supplier reacts.
Then week 35 begins, ordinary orders arrive for around 400 units, and there is no forecast left for them to consume. They land as additional demand on a week the supply plan has already emptied. The recovery is an expedite, and the expedite gets attributed to demand volatility in the review meeting, when the entire swing was created by a forward consumption window.
The other version of the same problem is a level mismatch. Forecast held at item and distribution centre, orders carrying a specific ship-to that the consumption logic matches on. Nothing ever matches, so nothing is ever consumed, and every order in the business is double counted. This one is easy to spot because the symptom is total, and it hides for years in the item groups nobody looks at.
What it does to the plan between runs
Consumption sits directly on the path between the demand plan and the supply plan, and it re-evaluates every time the planning run executes. Orders arrive through the week, so the demand the supply plan reads on Wednesday differs from what it read on Monday, even where the forecast itself has not been touched.
That churn is the ordinary source of replan noise in the execution window. Blackburn, Kropp and Millen tested dampening strategies for exactly this instability in the Journal of Operations Management in 1986, and Zhao and Lee looked at freezing the master schedule under demand uncertainty in the same journal in 1993. The general finding across that literature is that some amount of freezing costs very little in plan quality and buys a lot of stability. Where the frozen interval sits and who may reach into it is a decision rights question that belongs with the weekly execution forum (Y1).
There is an amplification effect on top of the noise. Lee, Padmanabhan and Whang named demand signal processing as one of the four causes of the bullwhip effect in Management Science in 1997, and a consumption rule that swings total demand up and down between runs is a demand signal processor sitting in your own building.
The reconciliation line that catches all of it
One report answers every question above. Build it per item, location and bucket, for whatever horizon your supply plan reads, with five columns: original forecast, quantity consumed, remaining forecast, open order quantity, and the total demand the supply plan received.
The identity to check is that total demand equals original forecast minus consumed plus open orders. Where it does not hold, something in the chain is transforming demand between the demand plan and the supply plan, and finding out what is a better use of a morning than another forecast accuracy review.
Then run two filters over the same table. Rows where open orders are above zero and consumed is zero say the match is failing, usually on level or on window. Rows where remaining forecast is above zero on a bucket whose date has passed say forecast is being stranded. Sort both by extended value and look at the top fifty. The value concentrates hard, and a handful of item groups normally accounts for most of it.
Where this stops
Consumption is an approximation standing in for a question no parameter can answer, which is whether a given order was part of the demand you forecast or genuinely on top of it. A new listing at an existing customer, a one-off tender, an order pulled forward from next quarter for a customer's own reasons: these are additional volume, and consuming forecast against them removes supply the baseline still needs. A window cannot tell the two apart. A demand planner looking at a large order can, which is an argument for reviewing the largest orders by hand and leaving the rest to the rule.
The mechanism also matters much less than this in some businesses than others. Where orders arrive with almost no lead time, as in point of sale driven replenishment, forecast and orders barely coexist in the same window and the netting rule has nothing to do. The short horizon signal problem there is a different one, and daily consumption data answers it (D10). At the other end, in a make to order environment, the planning strategy fields on the item decide whether a forecast should exist at the finished level at all, which is a separate configuration question (EE6).
One more caution. The reconciliation above will show you a difference between two numbers, and it will not tell you which one is right. A remaining forecast of 80 units on a closed week might be a forecast that was too high or an order that arrived under a different item code. Resolving that is item by item work, and the value of the report is that it puts a short, ranked list in front of you instead of a system-wide suspicion.
Pull three months of sales order lines with their creation date, requested date and quantity, plot the gap between the requested date and the start of the forecast bucket it should have netted against, and compare the eightieth percentile of that gap against the backward and forward consumption days configured on your fifty highest value item and location combinations.