Why does your plan look right in month three and absurd in…

Why does your plan look right in month three and absurd in month one?

Because in month three there is only forecast, and in month one there is forecast and orders — and your master plan is covering both. The name for it is forecast double-counting, and it is a configuration outcome, not a bug.

Master planning is a calculation. It executes the replenishment policy you gave it, and the policy that decides whether an incoming sales order consumes forecast or adds to it lives in four settings across three pages. Get them wrong and the far horizon still looks sane, because nothing has arrived to double-count yet.

The four settings that decide it

**Method used to reduce forecast requirements — Where it lives: Master plans page, General* FastTab — `Master planning > Setup > Plans > Master plans` · What it decides: Whether forecast is reduced at all, and by what rule. Options are None, Percent - reduction key, Transactions - reduction key, Transactions - dynamic period*
**Reduce forecast by — Where it lives: Coverage groups page, Other* FastTab — `Master planning > Setup > Coverage > Coverage groups` · What it decides: Which demand counts as consumption. All transactions or Orders*
**Reduction key** — Where it lives: Same FastTab; keys created at Master planning > Setup > Coverage > Reduction keys · What it decides: The period boundaries inside which consumption is matched
**Forecast plan time fence** — Where it lives: Same FastTab · What it decides: "the number of days (from today's date) that the demand forecast should apply to"

All four are quoted from Master planning with demand forecasts, Microsoft's Planning Optimization [GA] page.

Start with the first one, because it is the one that is wrong most often. If Method used to reduce forecast requirements is None, Microsoft states the consequence plainly: "master planning creates planned orders to supply the forecasted demand (forecast requirements)… For example, if sales orders are placed, master planning creates additional planned orders to supply the sales orders. The quantity of the forecast requirements isn't reduced."

That is double-counting, documented, working as designed.

One correction worth carrying, because the belief is widespread. The Forecast plan time fence does still do work under Planning Optimization even though forecast plans do not exist there. Microsoft's parameters-not-used list says: "Planning Optimization doesn't support forecast plans. However, it does consider this value when consuming forecast data within a master plan." The separate Forecast plan override on the master plan's Time fences in days FastTab is a different control, and that one the same documentation set marks "Planning Optimization doesn't support".

The calculation — run it on your own data

This is a calculation you perform, not a result we are reporting. Five inputs, each with a place to fetch it:

**F — forecast quantity for one item, one month — Demand forecast lines** page, for the forecast model named on your master plan
**D — open demand for the same item in the same reduction-key period** — Sales order lines, plus any other issue transactions in that window
**S — how much of D is sales orders specifically** — The same query, filtered to sales
**The method — Master plans page, Method used to reduce forecast requirements**
**The qualifier — Coverage groups page, Reduce forecast by**

Take an item with F of 1,200 units for next month, D of 900 units of demand in the same reduction-key period, of which S is 650 units of sales orders and the remaining 250 units are a transfer order issue to a sister warehouse. Three settings, three different plans from the same data:

The spread between the first and second lines is 900 units of supply you never needed. The spread between the second and third is 250 units — the transfer order, counted as demand but not as consumption. Substitute your own F, D and S; the shape does not change.

Microsoft defines the qualifier exactly: "If you set the Reduce forecast by field to Orders, only sales order transactions are considered qualified demand. If you set it to All transactions, any non-intercompany issue inventory transactions are considered qualified demand." Intercompany sales orders need Include intercompany orders set to Yes to join that set.

Where two Microsoft pages disagree, and what to do about it

There is a genuine documentation conflict here, and a planner reconciling a variance should know it exists before assuming their system is broken.

The Planning Optimization page says surplus demand carries out of its period:

"If the quantity of qualified inventory transactions is more than the quantity of demand forecast

lines in the same reduction key period, the balance of inventory transactions quantity is used to

reduce the demand forecast quantity in the previous period (if there's unconsumed forecast). If no

unconsumed forecast remains in the previous reduction key period, the balance of inventory

transactions quantity reduces the forecast quantity in the next month (if there's unconsumed

forecast)."

— Master planning with demand forecasts

The general Forecast reduction keys page says it does not:

"If the quantity of qualified inventory transactions is more than the quantity of demand forecast

lines in the same reduction key period, the balance of inventory transactions quantity doesn't

reduce previous or future periods."

The two pages carry different revision dates and the second opens with a tip pointing readers at Demand planning [GA] instead. We are not asserting which behaviour your environment exhibits — that is a sandbox question with a definite answer, and it is worth an afternoon.

The second failure mode: the forecast is at a level the plan cannot use

The reduction rule can be perfect and the netting still silently wrong, because consumption is matched on inventory dimensions and on line specificity.

*Under All transactions, transfers between warehouses inside one site may be ignored. Microsoft gives the rule and then the example: "If you select All transactions, the system considers transactions that have both demand and supply in the same inventory dimensions neutral and it ignores them during the forecast reduction. For example, if the planning dimension is set to site only, not warehouse, the system ignores a transfer order between site 1, warehouse 11, and site 1, warehouse 13, and it doesn't reduce the remaining demand forecast." The arithmetic above therefore assumes warehouse is one of your coverage dimensions. Whether your plan covers by warehouse at all is set on the Storage dimension groups page, with the Coverage plan by dimension* check box — documented here.

Order-of-encounter matching. Where a forecast line names a required BOM (bill of materials — the parts list for a product) or route, the behaviour without the Consider BOM and route in supply- and demand forecast reduction with Planning Optimization feature is that "the sales order reduces the demand forecast in the order that the lines are encountered, without checking the BOM." The feature requires "version 10.0.49 or later" and must be turned on in Feature management.

Customer-level forecast. The Include customer forecast in the demand forecast option decides whether actual customer demand reduces both the customer forecast and the overall forecast, or only the customer forecast. Set to No, Microsoft states, "Master planning generates planned orders to cover both the overall forecast quantity and the forecast for each customer quantity." That is double-counting by design, and it is the right setting for some businesses — but only deliberately.

Add forecast models to the list. A model can aggregate submodels, "the structure can be only one level deep", and lines on the same day across a model and its submodels are summed. If Demand planning [GA] is publishing into a model that is also a submodel of the model your master plan names, you have found your extra layer — the export profile writes to a target company and a named forecast model ID, and nothing checks the hierarchy for you.

The other half of month one

Netting fixes the demand side. The supply side of a near-term plan is only as good as the lead time it trusts, and the lead time a replenishment plan trusts is the date a vendor confirmed — a date that gets overwritten each time the vendor moves it. If your month-one plan is still wrong after the netting is right, the companion piece in this cluster, Why is your supplier OTIF ninety-eight percent when deliveries are late?, is the next thing to read.

What to do this week

Open Master plans and read Method used to reduce forecast requirements for the plan you actually run. If it says None, you have your answer and the rest of this is detail.
Open Coverage groups and read Reduce forecast by for the groups that carry your fast movers, then check whether your real consumption arrives as sales orders or as transfer issues.
Run the arithmetic above for three items — one fast, one slow, one seasonal. Three items is enough to tell a configuration error from noise.
Open the Storage dimension groups page, confirm which dimensions carry Coverage plan by dimension, and confirm your forecast is published at that level.

Where we would draw the line

We would not fix month one by shortening the forecast plan time fence until the forecast disappears — that removes the symptom and the signal together. We would not switch Reduce forecast by to All transactions as a blanket setting, because it makes intra-site transfers part of your netting logic whether you meant them to be or not. And we would not build any optimization layer on a plan whose netting rule is unknown: an optimizer that reads a double-counted requirement optimizes the wrong number faster.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Worked example. Modelled from public documentation and typical operations.

If your month-one plan and your month-three plan disagree and you want a second pair of eyes on the netting settings, book a call and we will walk the four settings against your own coverage groups. https://cognilium.ai

Why does your plan look right in month three and absurd in month one?