In April 2026, Plant Services covered a panel at the 2026 Fluke Xcelerate event. Jason Hahn, Global Reliability and Systems Manager at Amsted Automotive, was asked for his biggest maintenance challenge. He named his own systems. Of the "min/max levels, minimum reorder points, lead times, pricing, who we assumed were a supplier we could count on, or a distributor for those parts" they held, he said: "none of that data is valid anymore." His subject was critical equipment sourcing. Your Item Card holds the same fields.
ERP master data accuracy, applied to planning, is whether the stored values that drive replenishment (reorder point, safety stock, lead time, order modifiers) still match how your suppliers and customers behave today. Business Central's planning engine reads those values as inputs and calculates against them. The Microsoft planning pages cited below describe what the engine does with them. They describe no test of whether the values are still true.
Planning teams look for a bad signal in the model or in dirty data. Neither has to be wrong. The planning run can finish clean, the alert can fire on time, and an AI agent can recommend the right quantity for a lead time no supplier quotes anymore. A signal computed from an expired parameter is wrong even when the arithmetic is right. The AI readiness checklists for planning that I see start at the model. This article starts at the parameter table, because that is where the number was last true.
Field-definition drift, where one plant stores lead time in calendar days and another in working days, is a separate failure, covered in root cause 4 of the AI pilot article. In this failure every definition is consistent and every value is old. The tariff article asks who decides when policy moves. This one asks whether the numbers that decision reads moved with it.
Why a stale reorder point makes a correct planning signal wrong
Microsoft's planning documentation gives the reorder point one job: "A reorder point represents demand during lead time" (Microsoft Learn, Handling reordering policies, page updated June 2026). The engine proposes an order when inventory "is projected to pass below the level defined by the reorder point." Safety stock covers "fluctuations in demand up to a targeted service level." Read together, the reorder point is two facts, a demand rate and a lead time, frozen into one stored number. The page describes that relationship. It does not describe the number recalculating when a lead time changes, so the value stays where a person last put it unless you built something to move it.
Run one item through it, with illustrative numbers. It consumes 40 units a day, the supplier quotes 20 days, and safety stock is set to zero for clarity, so the reorder point is 800. A rerouted lane or a new country of origin moves the realised lead time to 45 days. The reorder point stays at 800. Calculate Plan crosses it on schedule and proposes the order on schedule. Stock runs out on day 20, the order lands on day 45, and 25 days at 40 units leaves 1,000 units of demand unserved. Every step of the calculation was correct. The item still stocks out.
The engine does catch this, late. Microsoft says the planning system "considers it an emergency" when future demand "can't be served from the projected inventory," and the planning line it creates carries an Emergency warning icon, sized to "the exact deficiency." By then the lead time has made the gap unavoidable. The first visible symptom of a stale parameter is the expedite.
An alert layer or an AI agent on top of Business Central inherits the same number with more speed and more confidence. Days of cover can be computed right while the reorder it drafts still assumes the old lead time. A card built from stored fields shows the value. It does not show how old the value is.
ERP master data accuracy: which planning parameters expire
Parameters decay at different speeds for different reasons. Microsoft's planning parameters page (Microsoft Learn, updated March 2026) says settings on the Item Card, SKU, Inventory Setup and Manufacturing Setup pages "determine how the planning system controls item supply." That is four places per item, and the SKU can carry its own values for each location. The reordering policy decides whether the engine reads a value at all: for the Order policy, Microsoft's table says "No planning parameters are considered." Those items cannot carry a stale reorder point. Audit the items on Fixed Reorder Qty., Maximum Qty. and Lot-for-Lot first.
| Parameter | Depends on | Expires when | Revalidate when | Owner (one named person, from this role) |
|---|---|---|---|---|
| Reorder Point | Demand during the item's lead time (Microsoft's definition) | The lead time or the daily consumption it was sized on moves | Realised lead time exceeds stored lead time by more than the Safety Lead Time, or consumption over the lead time shifts | Planner for the item class |
| Safety Stock Quantity | Demand fluctuation against a targeted service level | Supplier delivery variance widens, or the service level target changes | The late-receipt spread widens, or the target changes | Planner, with the ops head who sets the service level |
| Lead time on the item | The supplier's real transit: origin country, mode, lane, customs | Re-sourcing after a tariff change, a carrier or route change | Every supplier, origin, lane or carrier change, plus the stored-versus-realised comparison | Procurement |
| Safety Lead Time | The spread of actual arrival dates around the due date | Arrival spread outgrows the buffer. Microsoft advises a default of at least one day, which a supplier running two days late spends | Realised lead times vary by more than the buffer | Planner |
| Reorder Quantity, Maximum Inventory, Minimum Order Quantity, Order Multiple | Supplier minimums and pack sizes, price breaks, cash available for stock | Supplier renegotiation, a price change, a tighter working-capital limit | A supplier price or minimum revision, or finance changes the stock limit | Procurement, with finance |
| Default supplier and price | Who ships it and what it costs landed, duty included | A tariff rate change, a supplier exit, a distributor swap | Any rate change on the item's origin, any change in supplier status | Procurement |
Hahn's list maps onto the last three rows: lead times, pricing, the supplier he assumed he could count on. Those three feed the first two. One expired lead time leaves the reorder point and the safety stock stale without anyone editing either, which is how a single supplier change invalidates a whole item class.
How to find stale min/max and lead time values in Business Central
Your records already hold the evidence. Run four comparisons on the items whose policy reads a parameter, ranked by what a stock-out costs you. Hahn is restarting at "the top" of his critical equipment list. Do the same.
- Stored against realised lead time. For each vendor and item pair, take the interval from purchase order date to posted receipt over recent receipts and set it against the stored lead time. A gap wider than the item's Safety Lead Time means the buffer is already spent.
- Emergency lines. Count the Emergency planning lines per Calculate Plan run on reorder-point items. A rising count is a lead, not proof: a customer pulling an order forward produces one too. This reading is IQ's, not Microsoft's.
- Planner overrides. Count how often a planner changes a proposal's date or quantity before accepting it. A planner who corrects the same item every run is revalidating by hand and recording it nowhere.
- Parameter age. Find the date the reorder point, safety stock and lead time were last confirmed true. A change-log entry shows someone edited the item. It does not show anyone checked the number. If no confirmation date exists, that is the finding.
The emergency freight article itemises what the expedite costs once it reaches the dock, for a different cause of the same bill.
A parameter-validity check: an age, a named owner, a trigger
Hahn had to rebuild from scratch. A register turns the rebuild into routine. Six steps, in order:
- Scope by policy. Pull the items and SKUs whose Reordering Policy reads a parameter: Fixed Reorder Qty., Maximum Qty., or Lot-for-Lot with safety stock. Skip Order. Rank what remains by the cost of a stock-out.
- Add the age. For each parameter on each ranked item, record the date it was last confirmed true and the evidence: the realised lead time over recent receipts, the consumption over that lead time. A last-modified stamp does not count.
- Add the owner. One named person per parameter class, using the table above, plus a named delegate. Planners use the value, procurement knows when a supplier changed, finance knows when the duty did, and whoever maintains the item master types the number. Four people touch one field today.
- Set triggers by event first. A supplier or country-of-origin change, a route or carrier change, a tariff rate change on the item, a distributor swap, a supplier price revision. Add a maximum age per item class as the fallback, set by the owner. An item past its maximum age goes on the owner's list.
- Put the age on the recommendation. Any alert or agent proposal that reads a parameter shows its value and its age. A parameter with no confirmation date or no owner goes to a person before it drives a purchase order. This is a design rule. No product described on this site enforces it today.
- Log every revalidation. Parameter, old value, new value, who confirmed it, when, what triggered it, and which proposals ran on the old value in between. The last field is the one that lets you find the purchase orders placed on the stale number.
Who owns revalidating a planning parameter
Hahn's rebuild ran through two functions at once. He is "working closely with our maintenance management, our purchasing team" to work all of it out again. A parameter that planners, buyers and finance all depend on, and none of them owns, gets rebuilt only after a disruption makes the cost visible. Put one question to every planning signal: is the data it was computed from still true, and who owns revalidating it?
In decision infrastructure terms, this is the input side of Signal: a named owner for the number a signal is computed from, and a record of when someone last confirmed it. Build the register first, then put the age on every recommendation that reads from it.
Frequently asked questions
What is ERP master data accuracy for planning?
ERP master data accuracy, applied to planning, is whether the stored values that drive replenishment still match how your suppliers and customers behave today. Those values are the reorder point, safety stock, lead time, order modifiers and the supplier and price behind them. The planning engine calculates correctly from whatever is stored, so an expired value produces a wrong signal from right arithmetic.
How often should reorder points and lead times be revalidated?
Revalidate on events first: a change of supplier or country of origin, a route or carrier change, a tariff rate change on the item, a distributor swap, a supplier price revision. Add a maximum parameter age per item class, set by the owner, as the fallback. A calendar cycle alone misses a disruption that lands mid-cycle.
How do you tell whether a reorder point is stale in Business Central?
Compare the stored lead time with the interval from purchase order date to posted receipt over recent receipts. If the gap is wider than the item's Safety Lead Time, the buffer is spent. Then count Emergency planning lines per Calculate Plan run on reorder-point items, count how often planners change a proposal before accepting it, and look for the date the parameter was last confirmed. A last-modified stamp shows an edit, not a check.
Can an AI agent or alert layer detect stale planning parameters?
Only if it is given the parameter's age and realised data to compare against. An agent reading a stored reorder point or lead time calculates correctly from whatever value is there. The Microsoft planning pages cited here describe no validity check. Build the register first, then show the age on every recommendation.
Pick the ten items you can least afford to stock out. For each, write down the date its reorder point was last true and the name of the person who confirmed it. Every blank cell is a finding.