Deciding what to reorder in Magento without fooling yourself
An average of last month's sales looks like a forecast, but empty shelves and seasons make it lie. How to work out reorders properly, by hand or with a module.
It is Monday and the reorder is due. You export last month's sales, divide by four to get a weekly figure, multiply by the supplier's lead time and order that. One jacket looks quiet: only six sold in four weeks, so you order a few. What the export does not say is that the jacket was out of stock for three of those four weeks. It sold six in the one week it was available. You order too little, it runs out again, and next month's numbers look even quieter.
That loop is the most common mistake in reordering, and it is easy to make because zero sales and zero stock look the same in a sales report.
The short answer: a reorder needs a forecast of demand, not an average of sales. Days when you could not sell have to be left out, not counted as zero. Weekly patterns and seasons have to be taken into account, and the order has to cover the lead time plus a safety margin based on how wrong your forecasts usually are. You can do that in a spreadsheet for a small range. Our AI Demand Forecast module does it for the whole catalogue inside Magento.
What Magento tells you today
Magento's product reports cover what has already happened. Bestsellers and Ordered Products list quantities ordered in a period, and the Low Stock report lists products whose stock is within a range you choose1. In the inventory settings, "Notify for Quantity Below" sets the stock level at which you get a notification2.
These answer "what sold" and "what is low now". They do not tell you when a product will run out, how much to order, or whether last month was unusual. The reports also have no record of the days a product could not be bought, so they cannot separate a quiet week from an empty shelf.
Doing it properly by hand
For a few dozen products, a spreadsheet does the job if you are strict about a few steps:
- Use daily sales per product, and mark the days it could not be bought. Leave those days out of every average; do not treat them as zero.
- Look for a weekly pattern and, with more than a year of data, a seasonal one. A product that sells mostly at weekends or in December needs its forecast shaped that way.
- Note promotion days separately, or they make normal demand look higher than it is.
- Forecast demand over the lead time plus the time until your next order.
- Add safety stock based on how far your past forecasts were off, not a round number.
- Subtract what you have, then round up to the supplier's case size and minimum order.
Say a product sells about four a day on days it is in stock, the supplier takes 14 days and you order weekly. That is roughly 84 units of expected demand to cover, plus safety stock, minus stock on hand. This is a made-up example, but the arithmetic is the whole method.
It gets hard quickly. Products that sell once a fortnight break simple averages. Options of a configurable product each need their own numbers. And you only know whether your method works if you check old forecasts against what really happened, which is slow and dull to do in a spreadsheet.
What our module does
AI Demand Forecast collects the data first. A cron job records daily sales and returns per product (configurable products as the product and per option), price history and promotion days. An hourly check notes which products cannot be sold; a day counts as a stockout day when the product was unavailable in at least half of that day's checks. Those days are treated as unknown demand, never as zero. With Multi-Source Inventory, every stock linked to a website is tracked separately.
The forecasting runs inside PHP on your server, without an external service. For each product it tries several methods that suit the shape of the data: Holt-Winters with weekly and, given a year of data, yearly seasons; damped trend; Croston and SBA for products that sell now and then; a moving average. It holds back the last one to four weeks, forecasts them, and picks the method that came closest. That backtest is shown on every product page, so you can see how reliable a forecast is before you trust it. Promotion uplift, public holidays, an optional temperature effect and price sensitivity are measured from your own history and only applied when the history shows them.
From the forecast it works out days of cover, the date a product is expected to sell out, a reorder point, safety stock from a service level you set (95% by default) and the forecast error, and a suggested order quantity. That uses a lead time per product or supplier (14 days by default), the minimum order quantity and case pack. Purchase Suggestions lists products at or below their reorder point, most urgent first, with a CSV export for your purchase order.
It also makes price suggestions: markdowns for overstock and slow movers, increases when stock will run out before new stock can arrive, and moves towards competitor prices. They are only suggestions. Nothing changes until you approve one, approved changes are logged and can be reverted, and no suggestion goes below your cost plus minimum margin or outside the price floor and ceiling you set. Competitor prices come from product page URLs you enter. The module reads them once a day, takes the price only from the page's schema.org data, respects robots.txt and skips sites that block automated access rather than working around them.
The AI part is optional and small. With it switched on (through our AI Core module, with your own Anthropic or OpenAI key), it writes a weekly summary and can explain a suggestion in plain words. Only aggregated product figures are sent, never customer or order data. The forecasts themselves do not use AI.
Limits, and when a spreadsheet is enough
The module knows about stockouts only from the day it is installed. You can load two years of order history, but for that older period it cannot tell an empty shelf from a quiet week, and it does not know the prices from before installation either (discounts are inferred from what customers actually paid). Magento does not know your open purchase orders, so suggested quantities do not subtract stock that is already on its way. Bundles are forecast as the bundle, grouped products are not forecast, and price suggestions are not made for configurable products. A new product with little history gets a forecast with little behind it.
A forecast is an estimate with a range, not a promise, and we do not claim any particular accuracy. The dashboard shows how close the forecasts were on recent weeks for your own data, which is the only figure that matters.
If you sell a small range and restock every week, Magento's Low Stock report and a careful spreadsheet are probably all you need. Forecasting starts to pay when you have many products and options, long or varying lead times, seasonal ranges, or products that keep running out without anyone noticing why.
AI Demand Forecast is not on sale yet. We are testing it on our demo store, and will write about it again when it is available.
Sources
- Adobe Commerce Admin documentation, "Product reports", https://experienceleague.adobe.com/en/docs/commerce-admin/start/reporting/product-reports, checked 10 October 2026. ↩
- Adobe Commerce Admin documentation, "Catalog > Inventory", https://experienceleague.adobe.com/en/docs/commerce-admin/config/catalog/inventory, checked 10 October 2026. ↩