Some lines keep running out and others keep going in the skip, and someone has told you that better forecasting would stop both. It is a reasonable thing to believe. The forecast is the input everyone can see, and it is wrong every week by some amount. But the route from inventory forecast to purchase decision passes through four other figures and a rule, and each of them can be wrong by as much as the forecast. In a food business that does its weekly buy from a spreadsheet, that is usually where the stockouts come from.

A forecast is an input to the purchase decision. The decision itself is a rule: expected demand until the next order could arrive, plus the buffer you choose to hold against being wrong, minus what you already hold and have on order once promised stock is taken off, rounded to the supplier’s pack and pallet constraints and capped by shelf life. On the chilled cheese line worked through below, a forgotten allocation moves the order by exactly as much as a ten percent forecast error does. Once you can see that, you can sort your own stockouts into forecast, position and rule failures before you spend anything.

From inventory forecast to purchase decision

The forecast is the expected demand per period from customer orders that have not yet been placed. It is a point estimate, and the true figure lands somewhere around it every week. Whether it comes from a moving average in a spreadsheet or from forecasting software, it remains an estimate with error around it, and the rest of the decision has to work with that error.

Lead time is the time from placing an order to the goods being usable in stock, including receipt and any acceptance check. The review period is how often you place orders with that supplier. If the buyer orders from a supplier every Monday, the review period is a week.

Together these set the cover horizon, which is lead time plus review period. An order placed today arrives after the lead time. The next chance to correct it is one review period later, and that order arrives one lead time after that. So today’s order has to cover demand across both periods, because nothing ordered later can arrive sooner. Anything short in that window stays short. Buyers who cover lead time alone under-order by a review period’s worth of demand every week, and the shortfall looks like a forecast problem.

The inventory position is the quantity the decision works from. It is stock on hand, plus stock on order and not yet received, minus stock already committed to customer orders that have been taken and are awaiting picking. The on-hand figure on its own is the wrong input. It ignores what is already on its way, and it counts cases that are already promised as if they were free to sell. The record chain that produces these three figures, from goods received through to stock you can promise, is described in inventory management.

The buffer, usually called safety stock, is the extra quantity you hold against forecast error and late deliveries. It is a choice about the cost of running out weighed against the cost of holding stock, and on a perishable line the cost of holding includes throwing product away. A forecasting model cannot make that choice for you. It should differ by line: a core line for a retailer who charges for short deliveries deserves a bigger buffer than a slow line with a short life.

The target, sometimes called the order-up-to level, is expected demand over the cover horizon plus the buffer. The raw order quantity is the target minus the position. That raw figure is then rounded up to the supplier’s minimum order quantity and pack or pallet multiples, because you cannot order 180 cases from a supplier who ships 48 to a pallet.

Last comes the shelf-life cap. Stock arriving must be sold within the life your customers will accept on delivery. If product lands with 42 days of life and your retail customers require 21 days remaining at their door, you have three weeks to sell it, so there is no point holding more than three weeks of demand whatever the forecast or the buffer suggests. Customer terms set this cap. Will this batch have enough shelf life at delivery? covers how the same check runs through production and dispatch.

The rule produces a purchase proposal: a computed quantity with the reasoning that produced it. The purchase order is the approved commitment. Once approved, the order runs through receipt, acceptance and invoice, which is the subject of procurement software and needs no more than that sentence here.

Why the position is the weak link and the rule is invisible

The five inputs live in five places. The forecast sits in the buyer’s spreadsheet or a forecasting tool. Stock on hand is in the warehouse system. Open purchase orders are in the purchasing or finance system. Allocations are in the order book. Supplier multiples and minimums are in the buyer’s head or on a supplier’s price list. Bringing them together every week is the buyer’s job, and in most operations it takes a Monday morning of exports and pasting.

Of the five, open purchase orders are the weakest. A supplier confirms 90 of the 130 cases ordered, a delivery arrives a week late, an order is closed short at receipt, and none of those events is written back to the figure the buyer is using. The purchasing system still says 130. Allocations are the input most often left out altogether. They sit in the order book, they change through the day as orders come in, and leaving them out makes the position look healthier than it is.

The rule itself exists nowhere except in the buyer’s habit. The cover horizon, the buffer per line, the pallet rounding and the shelf-life cap are applied from memory, so nobody can review whether they are right, and nobody can tell when the buyer has changed one without mentioning it. When a customer tightens its shelf-life requirement or a supplier changes its pallet size, the rule changes in no system at all. When the buyer is on holiday, the rule goes with them.

Drop a forecasting tool into this and the buyer receives a better number for one of the five inputs, then reconciles it against the other four by hand exactly as before. If the position is wrong, the improved forecast is absorbed by the error and the stockouts continue. The tool is blamed, because it is the visible new thing. The buyer compensates by ordering more, which on a chilled line turns stockouts into write-offs of short-dated stock. Because the buy is weekly, the same mistake repeats every week until the decision itself is fixed.

One cheese line, one week

The scenario that follows is illustrative. No customer’s figures are used, and the numbers are chosen to be consistent with each other. A chilled food distributor buys one cheese line in cases of twelve from a single supplier who ships in pallets of 48 cases. Lead time is two weeks and the buyer orders from this supplier every week. One convention holds throughout: the weekly forecast counts demand from customer orders not yet placed, and cases already allocated to taken orders awaiting picking come off the position rather than sitting in the forecast.

With every input right, the decision runs like this. Expected demand over the horizon is 3 × 120 = 360 cases. The target is 360 + 60 = 420 cases. The position is 150 + 130 − 40 = 240 cases. The raw order is 420 − 240 = 180 cases. Rounded to pallets, 180 ÷ 48 = 3.75, so the buyer orders 4 pallets, which is 192 cases.

Then the shelf-life check. Stock on hand when the order lands is roughly 150 + 130 − 240 + 192 = 232 cases, and lower still once the 40 allocated cases have been picked. The cap is three weeks of demand, 360 cases. The cap is not binding on this line this week. It has to be tested every time, because on a slower line it would be the constraint that decides the quantity, and a buyer working from memory would not notice the week it started to bind.

Now three ways the same decision goes wrong. They are not measured against the same baseline. In the first, the inputs are right and the buyer’s calculation is wrong, so 192 is the correct order and the buyer places fewer. In the second and third, the buyer’s calculation is right on the information they have and they place 192, but a fact they cannot see means the true correct order is larger.

First, the allocation is left out. The buyer takes on hand plus on order without removing the 40 promised cases. The position appears to be 150 + 130 = 280. The raw order is 420 − 280 = 140, rounded to 3 pallets = 144 cases. The buyer orders 144 against a correct order of 192, one pallet short.

Second, the purchase order is stale. The supplier confirmed only 90 of the 130 cases and nobody updated the figure. The buyer, working from 130, correctly computes 192 and places it. The true position is 150 + 90 − 40 = 200, so the true raw order is 420 − 200 = 220, rounded to 5 pallets = 240 cases. The buyer ordered 192 when 240 was needed, and is again one pallet short.

Third, the forecast is ten percent low. The buyer, working from 120 a week, correctly computes 192 and places it. Actual demand runs at 132 cases a week, so the true target is 3 × 132 + 60 = 456 and the true raw order is 456 − 240 = 216, rounded to 5 pallets = 240 cases. Actual order 192, correct order 240, the same pallet short as in the second case.

A forgotten allocation of 40 cases, an unrecorded short confirmation and a ten percent forecast error each cost the same pallet. Forecasting software that cut this line’s forecast error from ten percent to five would have its whole gain undone by either of the position errors, and the buyer would never see why, because the position error does not announce itself the way a demand spike does. On a chilled line, one pallet is either a short delivery to a retailer who penalises shorts or 48 cases of short-dated cheese looking for a home. The shelf-life check carries the second lesson: part of the decision is a rule of the operation that no forecast can supply, and it can override the arithmetic entirely.

Three tests to run this week

Each of these follows from the example, and none of them requires buying anything.

Ask the buyer to produce the inventory position for one line from your systems, without opening the spreadsheet. They need three figures: stock on hand, open purchase orders at the quantity the supplier actually confirmed, and cases allocated to taken orders. If the on-order figure needs a phone call to the supplier or a search through emails, that is your weakest input, and no forecast will fix it.

Ask whether the buying rule is written down anywhere with its parameters per line: cover horizon per supplier, buffer per line, minimum and pallet multiples, and the shelf-life cap per customer. If the answer is that the buyer knows it, the rule is a habit. A habit cannot be reviewed when a customer changes its terms, and it cannot be handed over.

Take last quarter’s stockouts and sort them. For each one, was actual demand higher than the forecast by more than the buffer, or was the position wrong at the time of the order because of a short confirmation, a late delivery or an omitted allocation? Where most of them fall tells you what to fix first. If a meaningful share sits in the second group, the arithmetic above argues for fixing the position before the forecast, because until the position is trustworthy any improvement to the forecast is spent covering position errors of the same size. That ordering is a judgement, and your own sort is the evidence for it.

The same sorting gives you the question to put to any forecasting software or platform before it touches the buy: can the decision that uses the forecast see a trustworthy position, drawn from live purchase orders and allocations, and apply your rule with the reasoning visible? That is a question about the connection to your stock and order records. Some forecasting tools compute proposals and answer it well. Others produce a number and leave the reconciliation with the buyer. The model’s quality is a separate question, and the less important one until the first is answered.

How the weekly buy runs on Keel

Keel is an operations platform for running buying, receiving, stock and dispatch the way your business already works, with its own rules built in. For a food operation the jobs are the weekly buy, goods receipt and acceptance, stock by batch and date, allocation to customer orders, and dispatch with the shelf life each customer requires. The pressure is the buyer spending Monday morning rebuilding the position from four exports, and an operations director who cannot tell whether last week’s stockout was the forecast, the position or the rule. What they want is a decision they can see and trust each week, and the freedom to change the rule deliberately when a customer’s shelf-life requirement or a supplier’s pallet size changes.

Suppose the distributor in the example ran its buying on Keel. The weekly buy becomes a queue of purchase proposals, one per supplier, in the buyer’s task list. Each proposal shows the forecast used, stock on hand, stock on order taken from the live purchase orders at confirmed quantity, stock committed to taken orders, the buffer applied, the rounding to pallets and the shelf-life check, so the buyer can see why the quantity is what it is. On the cheese line the proposal reads 192 cases and shows the 40 allocated cases coming off the position. Had the supplier confirmed 90 instead of 130, the on-order line would say 90 and the proposal would read 240, with the short confirmation visible as the reason. The buyer approves or adjusts, and the approved quantity becomes the purchase order that receipt, acceptance and invoice then follow. Goods receipt updates the position on arrival, and allocations come off it as orders are taken, which is the record chain described in the inventory management article above.

What makes this possible is that the reorder rule is the operation’s own rule expressed in code on the platform, alongside a buyer’s view built for this buyer. Keel supplies the connected records for stock, purchase orders and allocations, the task queue, permissions such as who may approve a proposal above a value threshold, and reporting on proposed against ordered against actual demand. Business rules in code are what let the cap be set by each customer’s delivery requirement rather than by a configuration choice the software happened to offer. Code needs implementation, testing and maintenance, and that is the cost of the exactness.

The implementation must build the rule’s parameters per line and supplier, the supplier constraints, the shelf-life cap by customer requirement, the proposal screen, and the forecast method itself. Keel does not ship a demand model. The forecast can be a simple moving average built in the implementation, or a figure imported from a forecasting tool the operation already trusts. Keel leads the implementation and agrees the handover with your team. Your buying rule is built on the platform; there is no ready-made replenishment module to switch on.

One place AI could sit within this workflow, as an illustration rather than a shipped feature: a model could draft the buyer’s note on why this week’s proposal differs from last week’s, for the buyer to read and correct before approval. The proposal, the position and the rule stay as they were. The model saves the buyer some typing on the explanation.

When you do not need Keel

If your ERP already computes reorder proposals from live purchase orders and allocations, lets you set the buffer and multiples per line, and shows the buyer the proposal with its reasoning, the smaller change is to feed it a better forecast and tighten the discipline around supplier confirmations and receipts. Check that it does all of those before assuming it does.

If you buy a small number of lines with stable demand from a few suppliers and everything is in one system, a spreadsheet with a disciplined weekly pull of the position is enough. The discipline is the part that matters: confirmed quantities on open orders, and allocations taken off every week without exception.

Stockouts that trace to supplier reliability rather than to the decision are upstream of everything in this article. Supplier management covers approval and the conditions a supplier must hold on the delivery date.

Keel fits when the rule includes things the packaged system cannot express, such as a shelf-life cap set by each customer’s delivery requirement or a client-specific cover rule in 3PL replenishment, or when the position is spread across systems that are not going to be consolidated. The trade is an honest one. A rule in code needs implementation, testing and maintenance. A packaged tool’s rule is available on the day you buy it, and if it is close enough to yours, that is the cheaper route.

If you want to see how your own rule would run as a proposal, bring one line’s forecast, stock on hand, open purchase orders and customer shelf-life requirement to a requirements conversation with Keel. We will walk through the position, the rule and the rounding for that line, and you will know by the end whether the decision or the forecast is where your pallets are going.