A supply planner sees a forecast of 100 units and sales orders for 35 units. Should the system plan for 135 units? Sometimes those orders are already represented in the forecast. Forecast consumption is the mechanism that can prevent counting the same expected demand twice, when the selected planning strategy and settings support it.
This fictional SAP SCM exercise separates the arithmetic from system configuration. Start with the existing SAP APO demand-planning guide for planning areas and forecast creation. Here the question is what happens when an actual order arrives after a forecast has been released to the receiving planning process.
Establish the planning context first
“SAP SCM” can describe different products and planning landscapes. APO Demand Planning, APO supply planning and ERP or S/4HANA planning do not share one universal screen or consumption rule. SAP IBP also requires its own model and configuration. Name the product, receiving planning application, model or version, requirement type and strategy before applying a formula.
For this exercise, assume one product P-100, one location VIZ-01 and one planning period. The selected strategy allows eligible customer orders to consume the released forecast for that product-location within an agreed date window. All quantities use the same unit. No safety stock, stock on hand, receipts, scrap or lot-sizing constraints are included.
These assumptions make demand arithmetic visible. They do not describe a confirmed production configuration or calculate the final procurement proposal.
Worked example: thirty-five ordered units within the forecast
The original forecast is 100 units. A customer order for 35 units is eligible to consume it. The consumed portion is 35; the remaining forecast is 100 minus 35, or 65. Total demand considered in this simplified case is the 35-unit order plus the 65-unit remaining forecast: 100 units.
Adding the full 100-unit forecast to the same 35-unit order would produce 135 units and overstate this case by 35. Deleting the entire forecast would leave only 35 units and omit the 65 units still expected from other customer demand.
| Scenario | Order quantity | Consumed forecast | Remaining forecast | Combined demand |
|---|---|---|---|---|
| Eligible order inside window | 35 | 35 | 65 | 100 |
| Eligible orders exceed forecast | 120 | 100 | 0 | 120 |
| Order intentionally additional | 35 | 0 | 100 | 135 |
The second scenario uses a separate 120-unit order total. It does not add 120 to the first row’s 35. The third row assumes the business requirement and selected strategy treat that order as additional demand. A higher total is then intentional, rather than a double-counting error.
Why a sales order may not consume a forecast
Check eligibility before changing the forecast. The order may belong to another product, location, requirement category or date outside the configured consumption window. A unit conversion can also hide a mismatch. For example, a forecast in pieces and an order in boxes require the approved conversion; comparing their raw numbers is misleading.
Backward and forward consumption settings can permit demand to consume forecasts in neighbouring periods. If that is enabled, a period-level total may change while the wider horizon still reconciles. Inspect dated requirements across the relevant window instead of assuming each calendar bucket is independent.
Keep simulation and operational demand apart
Record the planning model or version containing the forecast and the version used by the receiving planning run. A forecast shown in a simulation does not prove that operational customer orders consumed it. Likewise, a copied version may contain different requirements or settings from the operational version.
When a forecast is released or transferred, record its identifier, timestamp, product-location and receiving quantity. Establish whether a subsequent release replaces, adjusts or adds requirements under the configured process. Repeatedly releasing the same plan without understanding that behaviour can create a reconciliation problem independent of consumption.
Worked extension: consumption across two forecast dates
Consider a separate training scenario with 60 forecast units on date D1 and 80 on a later date D2. One customer order for 90 units arrives with a requirement date between them. Assume its configured window includes both forecast dates, and the selected mode consumes backward before forward. There are no other orders competing for these quantities.
The order first consumes all 60 units at D1, leaving 30 ordered units to allocate. It then consumes 30 units at D2. Remaining forecast is zero at D1 and 50 at D2. Across the complete window, 90 ordered units plus 50 remaining forecast units equal 140, matching the original forecast total.
Now test backward-only consumption using the same data. Only the 60 earlier units are eligible. The entire later forecast of 80 remains, and combined demand is 90 + 80 = 170. That difference is explained by the deliberately narrower rule. It does not prove that either result is wrong: choose the rule that represents the business requirement and verify its implementation in the selected product.
SAP documents consumption direction and periods for ERP and PP/DS, but this illustrative sequence should not be copied as a universal SAP IBP configuration. Record the applicable calendar and exact dated requirements; weekly display buckets alone can conceal which quantities were eligible.
A practical diagnostic sequence for planners
- Capture the product, location, planning version, order identifier, requirement date and unit for one affected order.
- Identify the forecast quantity actually available to the receiving planning process, including its dates and release history.
- Check the strategy and requirement category that determine whether this order may consume this forecast.
- Inspect the configured direction and window, then list the forecast quantities eligible within that window.
- Compare expected consumed and remaining quantities with the system’s detailed forecast or requirement display.
- Only after the demand reconciliation succeeds, investigate stock, scheduled receipts and planning parameters that affect supply proposals.
Keep a short evidence record containing “expected result,” “observed result” and “first point of difference.” If the order is missing in the receiving application, investigate integration before changing consumption settings. If it is present but ineligible, explain the category, strategy or date mismatch with the planning owner.
Use order changes as a controlled practice test
Begin again with the original 100-unit forecast and eligible 35-unit order. In an authorised training environment, reduce the unfulfilled order to 20 units and check the updated result after the relevant processing completes. Under the same simplified assumptions, the expected remaining forecast is 80 and combined demand remains 100.
Next, move the order date outside the allowed window and record the new allocation. Do not manually reduce the forecast at the same time, because that would prevent you from isolating the effect of the date change. SAP ERP documentation describes consumption allocation as dynamic when orders or planning are rescheduled; other landscapes require their own processing checks.
Frequently asked questions
Does consumption mean the original forecast was inaccurate?
No. Consumption represents expected demand becoming more specific. Forecast accuracy requires a separate comparison with the appropriate actual demand measure and time horizon. A well-consumed forecast can still be too high or too low.
Why does a weekly total disagree with the monthly total?
Consumption may cross the weekly boundary. Reconcile dated requirements across the complete allowed horizon and check that both displays use the same version and quantities. Do not add original forecast values from one view to remaining values from another.
Can combined demand be converted directly into a purchase quantity?
Not in this exercise. Stock, existing receipts, lead times, safety stock and lot-sizing rules were excluded deliberately. Demand reconciliation is an input to the next planning step, not a complete replenishment calculation.
Official SAP references
- SAP Documentation: Forecast Consumption and Requirements Strategies
- SAP Help: Consumption Strategies and Logic in ERP
- SAP Help: Consumption in PP/DS
Acceptance checks for the exercise
- The 35-unit eligible order leaves 65 forecast units and combined demand of 100 under the stated assumptions.
- The independent 120-unit case leaves zero forecast units and combined demand of 120.
- The intentionally additional 35-unit order retains the 100-unit forecast and produces 135 combined units.
- A changed-date case records whether the configured window allows consumption, including any neighbouring period.
- Every result names its product-location, unit, date window and planning version; supply proposals are reconciled separately.
These are expected results for a training design, not executed system findings. Use an authorised practice environment to record actual outcomes. Discuss this case alongside Softenant’s SAP SCM training in Vizag, and confirm the products and planning scenarios covered by your batch.