Business Central inventory forecasting: a reorder point that is recalculated, not typed once
Business Central plans well once its parameters are right. The weak spot is where the numbers come from. We read your item ledger entries through the API, forecast each SKU at each location, and send back reorder points, safety stock and maximum inventory, or lines for the demand forecast. Your planner decides.
Book a 30-minute demoHow it works
Read-only connection · Tested on your own data first · Data hosted in the EU · Demos in English or Spanish
The short answer
Business Central inventory forecasting means feeding its planning system with reorder points, safety stock and forecasts that match current sales. Microsoft’s Sales and Inventory Forecast extension predicts sales in aggregate across locations and variants, and does not turn them into planning parameters. Arume reads item ledger entries and inventory by location through the Business Central API, forecasts every SKU, and proposes reorder parameters or demand forecast lines for a planner to approve.
By Manuel Gómez González, founder of Arume · Reviewed on
What it does
Forecast per SKU and location
Each stockkeeping unit is forecast with its own sales history and its own lead time, then the locations are compared.
Reorder parameters that move with sales
Reorder Point, Safety Stock Quantity and Maximum Inventory are recalculated every week and written back only where you allow it.
Transfer orders before purchases
If a product is idle at one location and short at another, the system proposes a transfer order first and shows the comparison with buying.
Demand forecast without typing the matrix
For items planned on a forecast, we fill the demand forecast page with calculated values at the cadence you choose.
A reason on every line
Sales pace, lead time, stock on hand and on order, and risk are written next to each proposal.
Replay before write access
Past weeks are decided again with what was known at the time and compared with your actual parameters.
How does Business Central replenish out of the box?
Business Central replenishes through its planning system. According to Microsoft Learn, it takes all demand and supply into account, nets the results and creates suggestions for balancing supply to meet demand. Supply is inventory, purchase, assembly and production orders and inbound transfers. Demand is sales orders, outbound transfers, component needs and forecasts. The suggestions are action messages that appear on the planning worksheet or the requisition worksheet: create an order, change its quantity, reschedule or cancel it.
What decides when and how much to reorder is the set of planning parameters on each item, or on each stockkeeping unit (SKU) if you hold the item at several locations. The main one is the reordering policy, and Microsoft lists four: Fixed Reorder Qty., Maximum Qty., Order and Lot-for-Lot. The first two work from a reorder point. The other two react to actual demand. The Replenishment System field on a SKU adds whether the item is purchased, transferred from another location or produced, which tells Business Central whether to propose a purchase order or a transfer order.
- Fixed Reorder Qty.: when projected inventory drops below the reorder point, order the same quantity every time.
- Maximum Qty.: when it drops below the reorder point, order the gap up to maximum inventory.
- Order: buy or produce for a specific demand, with no stock of its own.
- Lot-for-Lot: accumulate real and forecast demand inside a lot accumulation period and order that.
- Order modifiers on top: Minimum Order Quantity, Maximum Order Quantity and Order Multiple.
What is a reorder point in Business Central, and why does it go stale?
Microsoft defines the reorder point as demand during lead time: when projected inventory is about to pass below that level, it is time to order more. It is the classic definition and it is correct. The problem is where the number comes from. Someone types it on the item card or the SKU, often during a migration from Navision or another system, and from then on nobody touches it.
Meanwhile three things move. Sales have seasons and trends. The vendor’s lead time slips from 7 to 15 days without anyone updating the field. And the range changes, with new items inheriting the reorder point of a similar one. A company with 1,500 items and four locations has 6,000 SKUs. Nobody reviews them one by one, so purchasing corrects the few it knows from memory and the rest stay as they were.
There is a second detail in the documentation. For Fixed Reorder Qty., Microsoft says a forecast is not needed because anticipated demand is already expressed in the reorder point, and recommends Lot-for-Lot if you want to plan on a forecast. In other words, if the reorder point is wrong, no forecast will repair it. That is why recalculating the reorder point is where the value is.
What does the Sales and Inventory Forecast extension do, and where does it stop?
It is a Microsoft extension that uses Azure AI to predict sales from your history. According to Microsoft Learn, it takes item ledger entries of type Sale (posting date, item number and quantity), groups them by the period type you set, and returns a forecast. Microsoft suggests forecasting by month with a 12-month horizon. On the Items page, the Item Forecast pane shows expected sales, and when you create a purchase order the extension can suggest restocking other items from the same vendor that are about to run out.
The documentation is also frank about its limits. The forecast is aggregated for all locations and variants, so if each location is a store you cannot get a forecast per store and must distribute amounts afterwards. It does not support filtering, so you cannot split the catalogue into batches. Microsoft estimates it processes about 50,000 items in 12 hours. And if there is not enough data, or the data varies a lot, the service does not make a prediction.
The extension also stops before the parameters. Reorder point and maximum inventory stay as they were. That is the missing step between predicting and replenishing, and it is the one we add.
What do we read from Business Central, and what do we write back?
We connect through the Business Central API v2.0, the REST interface Microsoft publishes for reading and writing data. We ask for permissions limited to what is needed: read access to items, ledger entries, inventory and open orders, and write access only to what we agree. If you run Business Central on-premises, the API has to be enabled on the server, and your partner can confirm that quickly.
We read item ledger entries of type Sale by location with posting date, inventory by location, open purchase and transfer orders, lead time per item or SKU, and the planning parameters currently in force so we can compare them with the proposed ones. With the ledger entries and today’s inventory we rebuild the stock of every past day, so the model knows which days an item did not sell because there was none to sell.
What we write, in the form you choose: Reorder Point, Safety Stock Quantity and Maximum Inventory per SKU, so that Business Central plans with them; or lines on the demand forecast carrying the weekly proposal. If a field you want is not available in the standard API, a small custom API page can be added, kept separate and reviewable by your partner.
- Reads: item ledger entries, inventory by location, open purchase and transfer orders, lead times, current planning parameters.
- Writes: reorder point, safety stock and maximum inventory per SKU, or demand forecast lines.
- Never touches: accounting, prices, customers or orders already released.
How do multiple locations, SKUs and transfer orders fit in?
Many Business Central companies have a central warehouse and several branches, or one location per store, each with its own SKU and reorder point. We forecast each location with its own sales and its own lead time: the vendor’s for the central warehouse, the internal truck’s for the branches. Then we look at all of them together.
Before proposing a purchase for Bilbao we check whether the product is idle in Seville. If moving it costs less than ordering, we propose a transfer order, and Business Central treats it like any other. If you use forecasts by location, which Microsoft exposes as the Use Forecast on Locations field in Inventory Setup, the forecast we load is by location too.
One detail from the planning documentation is worth knowing. When no SKU exists for a location, Business Central follows the Missing SKU Planning Policy on the Location Card. A quick audit of which locations lack SKUs often explains why some items never get proposals. We list those in the first report.
Can it replace typing the demand forecast for MPS?
If you manufacture or assemble, you probably use the demand forecast page for master production scheduling. Microsoft describes forecast entries as having an item number, a date and a quantity, with the forecast type Sales Item, Component or Both, and only one forecast can drive planning at a time. With 300 items and 12 months, that is 3,600 cells that somebody fills and nobody reviews.
We calculate that forecast from your sales, place it on the page with the type you use and refresh it monthly or weekly. Business Central then plans with it exactly as with a typed one. For those items the policy that fits is Lot-for-Lot, which is what Microsoft recommends when the plan is based on a forecast.
What does it not do, and how do we start?
It does not replace Business Central or its planning system. It does not release orders on its own: the proposal comes back as parameters or demand forecast lines, and a planner decides. It does not touch accounting, prices or released orders. And it does not guarantee that you will never run out; it lowers the risk and tells you what the risk is for each item.
We start by replaying your past months. Each week is decided again using only what was known that week, and compared with what Business Central did with your parameters: demand served, stock-outs, orders, units and money tied up. Then one or two months in shadow mode, and only then write access. The free analysis needs an export of item ledger entries and inventory by location, and returns a short report on what we would change first.
Frequently asked questions
Can Business Central forecast demand on its own?
Partly. The Sales and Inventory Forecast extension predicts sales using Azure AI, but Microsoft documents that it forecasts in aggregate for all locations and variants, supports no filtering, and does not change reorder points. You can also type a demand forecast by hand. We calculate it per SKU and location and feed the planning system.
Do we have to install anything in Business Central?
No. We use the standard API v2.0 with limited permissions. Microsoft notes that standard APIs cannot be extended with extra fields; if one is needed, a small separate API page is created and your partner can review it.
Which reordering policy works best with this?
For stable items, Maximum Qty. with recalculated reorder points. For items you plan on a forecast, Lot-for-Lot, as Microsoft recommends. Microsoft advises against combining a forecast with Fixed Reorder Qty., since anticipated demand is already in the reorder point.
Does it work with Business Central online and on-premises?
Yes. In the online version the APIs are active by default. On-premises they need to be enabled on the server, which your partner can do.
What if we already use the forecast extension?
Keep it for the overview. We add the per-location detail it cannot give and write the parameters it leaves untouched.
Who maintains the connection when Microsoft updates Business Central?
We do. Microsoft versions the API, and any change is checked against a test environment before it reaches production.