Reorder Point in Business Central: When to Trigger Replenishment, for Make-to-Stock and Make-to-Order

Reading Time: 11 minutes

This is the third one. I wrote about Safety Stock (how much buffer to hold) and EOQ (how much to order). The last piece of the puzzle is the one people get wrong most often: when to order. That is the Reorder Point, and the mistake I see on nearly every tenant is not a bad number. It is a number sitting on the wrong kind of item.

Here is the pattern. A planner reads somewhere that reorder points are good practice, opens the Item Card, and starts filling in the field on everything. Stocked products, made-to-order machines, configured assemblies, the lot. Six months later half the planning suggestions make no sense and nobody trusts the worksheet anymore. The reorder point was never the problem. Putting it on make-to-order items was.

So this post does two things. It shows you how to calculate a reorder point that holds up, and it draws the line, clearly, between the items that should have one and the items that should not. That second part is where most of the value is.

Get the Code

github.com/GmsoftLtd/bc-reorder-point

Free. MIT licensed. Object range 50300 to 50399 (no conflict with bc-safety-stock on 50100 to 50199 or bc-eoq-calculator on 50200 to 50299). Runtime 14.0, BC v27+.

What the Reorder Point Actually Is

Microsoft’s own planning documentation says it in one line: a reorder point represents demand during lead time. That is the whole idea. The reorder point is the inventory level low enough that, by the time your replenishment arrives, you have just about run down to your safety buffer and no further.

Picture stock draining away as you sell or consume it. At some level you place an order. Then you wait, because nothing arrives instantly. During that wait you keep selling. The reorder point is the level where you have exactly enough left to cover the selling you will do while the order is in transit, plus the safety stock you promised yourself you would not dip below.

Set it too low and you stock out before the replenishment lands. Set it too high and you carry stock you did not need yet, which is EOQ’s problem leaking into the trigger. The reorder point is not a buffer and it is not an order quantity. It is a trigger level, and it answers one question: how low do I let this get before I act?

The Formula

Reorder Point = (Average Daily Demand × Lead Time in days) + Safety Stock

That is it. Two terms. The first is demand during lead time. The second is the safety stock you calculated separately.

Worked example. Take the same item I used in the EOQ post: it sells about 4,800 units a year. Spread across the calendar that is roughly 13 a day. Your supplier’s lead time is 14 days. Your safety stock, calculated at a 95% service level, is 40 units.

Reorder Point = (13 × 14) + 40
             = 182 + 40
             = 222 units

When projected inventory drops to 222, it is time to order. The 182 covers the two weeks of selling you will do while you wait. The 40 is the cushion in case demand runs hot or the delivery slips. If everything goes to plan, the new stock arrives just as you touch 40, and you never break into the buffer. If it does not go to plan, the buffer is there for exactly that reason.

Notice how the three numbers connect. Safety Stock feeds the reorder point. EOQ becomes the reorder quantity that the engine orders once the point is hit. Three formulas, one coherent setup. That is the whole reason I built them as a set.

Where the Three Inputs Come From in BC

Average daily demand. Same source as the other two tools: Item Ledger Entries of type Sale, over a history window. The extension defaults to 365 days and averages across every calendar day, not just the days something sold. That matters. If you divide a year of sales by the handful of days that had orders, you get a spiky number that overstates the daily rate. Divide by the full calendar and the rate lines up with a lead time you also measure in calendar days. Apples to apples.

Lead time. This is where purchased and manufactured items part ways, and the extension handles them differently:

• For purchased items, it reads your actual purchase receipt history, comparing Order Date to Posting Date on each receipt, and averages the real lead times. Your supplier’s promised lead time and your supplier’s actual lead time are rarely the same number. Use the real one.
• For manufactured and assembled items, there is no purchase receipt to measure. It reads the Lead Time Calculation field on the item, which is your production or assembly lead time.
• If neither exists, it falls back to a value you set in Setup, and tells you in the log that it had to.

Safety stock. It reads Item."Safety Stock Quantity" straight off the card, the value you already calculated with the safety stock tool. You can switch this off if you want a bare demand-during-lead-time number, but I would leave it on. A reorder point with no buffer assumes nothing ever goes wrong, and something always goes wrong.

Make-to-Stock vs Make-to-Order

This is the section that matters. Get this wrong and the cleanest formula in the world still produces nonsense.

A reorder point only makes sense for make-to-stock. That is the whole model: you hold inventory on the shelf, demand draws it down, and when it hits a trigger level you replenish back up. The reorder point is the trigger. It assumes there is a stock level to defend.

Make-to-order breaks that assumption completely. With make-to-order, you do not hold the item in stock at all. A sales order comes in, and that specific order creates a specific supply: a purchase order to a vendor, or a production order on the shop floor, pegged one-to-one to the demand that caused it. There is no shelf to run down, so there is no trigger level, so there is no reorder point. In Business Central this shows up as the Reordering Policy set to Order, or the Manufacturing Policy set to Make-to-Order. Microsoft’s documentation confirms the mechanics: when either of those is set, the planning engine creates an order-to-order binding and keeps demand and supply linked until you ship. A reorder point would just sit there, ignored, because the engine is not asking “are we low?” It is asking “what did this specific customer order?”

Let me put both side by side, because the products-versus-finished-items angle is where people tie themselves in knots.

Make-to-stock, purchased product. You buy a part and sell it from stock. Classic reorder point territory. Demand draws inventory down, the point triggers, BC suggests a purchase order. Reordering Policy is usually Fixed Reorder Qty., the reorder point is the demand-during-lead-time plus safety stock, and the reorder quantity is your EOQ. This is the bread and butter.

Make-to-stock, manufactured finished good. You produce a finished item and keep it on the shelf so you can ship the moment an order lands. Still a reorder point, but now the lead time is your manufacturing lead time, not a vendor’s. When the point triggers, BC suggests a planned production order instead of a purchase order. The Manufacturing Policy is Make-to-Stock, which tells the engine to plan this item on its own merits, independently of any single sales order. This is how you run a catalogue of standard finished goods without quoting six weeks on everything.

Make-to-order, finished good. Now you build only when someone orders. A customer places a sales order, and BC creates a production order pegged directly to it. No stock, no trigger, no reorder point. Manufacturing Policy is Make-to-Order and the planning engine explodes that demand straight down through the bill of materials. Setting a reorder point here does nothing useful and quietly confuses your planning.

Make-to-order, purchased. Same story without the shop floor. A demand line creates a purchase order pegged to it. Order policy, no reorder point.

Here is the part people miss, and it is the most useful thing in this whole post. The policy can change as you go down the BOM. A make-to-order finished machine can sit on top of make-to-stock components. The machine itself has no reorder point, because you only build it to order. But the bolts, the motors, the standard sub-assemblies underneath it absolutely should have reorder points, because you stock those so the build can start the day the order lands. So the question is never “is this company make-to-order or make-to-stock.” It is “is this item make-to-order or make-to-stock,” asked one item at a time, all the way down the structure. The finished good and its raw materials often answer differently.

That is exactly why the extension skips make-to-order items on purpose and writes the reason into the log, rather than stamping a meaningless number on them. Run it across a full item list and it quietly does the right thing: reorder points on the stocked items, a logged skip on the made-to-order ones, no silent damage.

How BC Uses the Reorder Point in MPS / MRP

The reorder point is a field. The planning engine is what reads it. Two reordering policies actually use it:

• Fixed Reorder Qty. When projected inventory drops below the reorder point inside a planning bucket, the engine suggests a supply order for the Reorder Quantity (your EOQ). This is the classic reorder-point home, and it is what the extension switches a blank-policy item to when it writes the value, so the number does not just sit there inert.
• Maximum Qty. Same trigger, different quantity. When inventory drops below the reorder point, the engine tops you back up to Maximum Inventory rather than ordering a fixed batch. Use this when you care about a ceiling more than an economic batch size.

The other two policies, Order and Lot-for-Lot, do not use the reorder point. Order is make-to-order, which we just covered. Lot-for-Lot plans against actual demand in each time bucket and ignores the trigger level entirely.

One detail worth knowing, because it surprises people. BC works in time buckets, not on a continuous line. The engine does not fire the instant inventory crosses the point. It checks within each bucket and forward-schedules the supply from the first date after the bucket ends. The documentation is explicit that this is deliberate: fewer, cleaner suggestions instead of a new line every time stock wobbles. It mirrors how a human actually checks the shelf, once in a while, not every second.

There is also a Safety Lead Time field, separate from safety stock, that pads the lead time itself rather than the quantity. If your real risk is delivery slippage more than demand spikes, that is the lever. The reorder point in this extension covers the quantity side; Safety Lead Time is yours to set if you need the time side too.

What Comes With the Extension

Object	Type	ID
Reorder Point Setup	Table + Page	50300
Reorder Point Calculation Log	Table + Page	50301
Reorder Point Result Code	Enum	50300
Reorder Point Calculator	Codeunit	50300
Reorder Point Job Queue Run	Codeunit	50301
Reorder Point Demo Data	Codeunit	50399
Item Card Page Extension	PageExt	50300
Item List Page Extension	PageExt	50301
Reorder Point Permission Set	Permission Set	50300

Single-item action

On any Item Card, click Calculate Reorder Point in the Actions tab. The extension:

1. Checks whether the item is make-to-order; if so, it skips and logs the reason
2. Pulls Item Ledger Entries of type Sale for the history window (default 365 days)
3. Averages them across the calendar to get average daily demand
4. Works out the lead time: purchase receipt history, then the Lead Time Calculation field, then the setup fallback
5. Reads the item’s Safety Stock Quantity
6. Computes (Average Daily Demand × Lead Time) + Safety Stock
7. Rounds up to whole units if set
8. Shows you the number, the reason, and asks before applying

If you confirm, it writes to Item."Reorder Point" and, when the item had no reordering policy yet, switches it to Fixed Reorder Qty. so the engine actually reads the value. Every run is logged with the demand rate, the lead time and where it came from, the safety stock used, and a plain reason.

Bulk action

Open the Item List, filter to the set you want, and click Calculate Reorder Point (Bulk). It warns you up front how many of the selected items are make-to-order and will be skipped, then processes the rest and logs every one. No silent failures, no surprise reorder points on items that should not have them.

Job Queue

The included Reorder Point Job Queue Run codeunit (object 50301) takes a Parameter String, so you can schedule recalculation:

• Object Type: Codeunit
• Object ID: 50301
• Parameter String: FILTER=Item Category Code:FERT
• Recurring: monthly or quarterly

Reorder Point + Safety Stock + EOQ

This completes the set. Three numbers, three jobs, one tidy planning setup:

• Safety Stock answers how much buffer to hold against variability. Goes into Item.Safety Stock Quantity. That is bc-safety-stock.
• Reorder Point answers when to trigger the order. Mechanically (Average Daily Demand × Lead Time) + Safety Stock. Goes into Item.Reorder Point. That is this extension.
• EOQ answers how much to order. Goes into Item.Reorder Quantity. That is bc-eoq-calculator.

Populate all three on a make-to-stock item, set the Reordering Policy to Fixed Reorder Qty., and the Planning Worksheet has everything it needs. It triggers at the reorder point and orders the economic quantity, with the safety stock baked into the trigger. Every number on the card can be explained to an auditor or a sceptical operations manager, because every number came from the item’s own history, not from a guess made at go-live.

Practical Tips

Recalculate, do not set and forget. Demand drifts, suppliers get faster or slower, safety stock changes. A reorder point set last year is describing last year. Schedule the bulk recalc quarterly for your fast movers and once a year for the slow ones.

Match the window to the item. A full year smooths seasonality into a steady daily rate, which is what you want for most things. For an item with a sharp season, recalculate inside the season so the rate reflects the period you actually need to cover.

Trust measured lead time over promised lead time. The receipt-history lead time is usually longer than the number in your vendor agreement. The receipts are what really happened. Plan against reality.

Mind the manufacturing lead time on finished goods. For a produced item, the lead time is the time to make it, and that can be much longer than any purchase. A reorder point built on a vendor-style lead time will trigger too late on a manufactured item.

Fix safety stock first. The reorder point includes safety stock, so a bad buffer poisons the trigger. Run the safety stock tool before this one. Order matters.

When the Reorder Point Is the Wrong Tool

• Make-to-order and engineer-to-order items. Covered at length above. Use the Order policy and let demand peg supply. No reorder point.
• Brand-new items. No history, no demand rate. Use a category default until the sales accumulate.
• Intermittent or lumpy demand. A flat daily average hides the spikes. The reorder point will look fine and still stock you out on a burst. Lean harder on safety stock, or use a category rule.
• Items planned purely from forecast. If the demand signal is a forecast rather than a reorder level, use Lot-for-Lot. Mixing a forecast with a reorder point double-counts the same demand.
• Regulatory minimum stock. That floor comes from compliance, not from demand maths. Set it by hand.

Install It

Developer or sandbox:

git clone https://github.com/GmsoftLtd/bc-reorder-point

Open in VS Code with the AL extension. Confirm the object ID range (50300 to 50399) is free. Press F5. There is a Generate Demo Data (Sandbox) action on the Item Card that seeds a year of sales and a handful of receipts so you can watch a real number come out without touching live data.

Production tenant:

1. Download a release .app from the Releases page, or build from source
2. Upload via Extension Management
3. Open Search, go to Reorder Point Setup, check the history window and the make-to-order skip
4. Test on a single stocked item before running bulk

It writes at most two fields per item, the Reorder Point and, only when the policy was blank, the Reordering Policy. Safe to uninstall.

What’s Next

That is the trilogy done: Safety Stock, EOQ, Reorder Point. Three free extensions, three numbers, the full deterministic-replenishment maths for Business Central, none of them needing an AppSource subscription or a change to standard BC.

The next piece pulls them together: one combined walkthrough on choosing between Fixed Reorder Qty., Maximum Qty., and Lot-for-Lot, with all three numbers in play on the same item, and worked examples for a purchased product, a make-to-stock finished good, and a make-to-order machine with stocked components underneath.

Resources

• Code: github.com/GmsoftLtd/bc-reorder-point
• License: MIT
• Companions: bc-safety-stock · bc-eoq-calculator
• Microsoft Learn: Design details: Planning parameters
• My consultancy: GMSOFT Limited
• PRs welcome for component-level reorder points from consumption, routing-based lead times, and per-location SKUs

If your tenant has reorder points scattered across make-to-order items, or stocked items with no reorder point at all, install this in a sandbox and run the bulk action against a real category. The log will tell you, item by item, which ones should have a trigger and which ones never should have. That list alone is usually worth the ten minutes.

---

Questions, an edge case, or a planning behaviour you cannot explain? Get in touch.