Inventory optimisation & automated replenishment

Too much stock ties up cash and ends in write-offs; too little causes stock-outs and lost sales. Inventory optimisation replaces static min/max rules and spreadsheets with probabilistic demand and lead-time forecasts plus a solver or policy that sets safety stock, reorder points and order quantities per SKU and location, and then proposes or places the orders. Humans review exceptions and set service-level and budget policy.

Problem & value

• Today: buyers and planners use ERP min/max values, fixed safety-stock formulas (often assuming normally distributed demand) and manual overrides. Parameters go stale, intermittent "slow movers" and new products are handled poorly, and the same rule is applied to very different items.
• AI value: distribution-based forecasts (not just point forecasts) capture uncertainty in demand and supplier lead time; the optimiser trades off service level against holding cost across thousands of SKU-location pairs; automation removes routine ordering so planners manage exceptions.
• Benefits: vendors report lower inventory at equal or higher service level, but figures are self-reported and highly dependent on the baseline. Treat them as hypotheses and verify with a back-test or A/B pilot on your own data [1][2].

Variants

• Retail and e-commerce: store/DC replenishment, fresh-food ordering with shelf life, promotion and weather effects (see OPT-016, OPT-017).
• Manufacturing and MRO: raw materials, components and spare parts with very intermittent demand; coordination with production planning (OPT-002).
• Distribution and wholesale: large assortments, supplier price breaks, multi-echelon networks (OPT-008).
• SMB: webshops and craft/trade businesses using built-in ERP or shop-system reorder suggestions, typically a few hundred to a few thousand SKUs.

How it works

1. ERP/WMS/POS data (sales, stock, POs, lead times)
2. data cleaning (stock-out censoring, returns, outliers, new/phase-out items)
3. probabilistic demand forecast + lead-time distribution per SKU/location (PRED-001)
4. inventory policy optimisation (service-level target, cost, MOQ, shelf life, budget, capacity)
5. order proposals (PO lines, transfers) with explanations
6. planner review of exceptions / auto-release within guardrails
7. PO sent to supplier (EDI/API/e-mail)
8. actuals feed back into forecast and parameters

• Forecasting: gradient-boosted trees or global deep/foundation time-series models produce quantile or sample forecasts; intermittent items use dedicated models (Croston/TSB, count distributions).
• Optimisation: analytic newsvendor and (s,S)/(R,Q) policies, stochastic or mixed-integer programming for constraints such as budget, container fill and MOQs; multi-echelon allocation across DC and stores. Reinforcement learning is used in research and some products for policy tuning.
• LLM role: supporting only: what-if queries, exception explanations, supplier e-mails (OPT-018, AGENT-005).
• Human-in-the-loop: planners set service-level classes, approve high-value or new-item orders and can override with a reason, which is logged and used to judge forecast quality.

Data preparation

Needed: sales and consumption history per SKU and location, current stock, open purchase orders, supplier lead times, MOQs and pack sizes, promotion and price calendars. This usually lives in the ERP or WMS, plus Excel sheets of buyers, supplier e-mails and paper delivery notes.

Typical gaps: item master data that is duplicated or inconsistent (units of measure, pack sizes), stock-outs recorded as zero demand, lead times that exist only in the buyer's head, promotions not documented, and bookings corrected in bulk.

Preparation steps: - Export 2-3 years of order and stock history via ERP reports or connectors (see PREP-005). - Clean the item master, merge duplicates and fix units; tidy Excel lists into tables (PREP-011). - Mark stock-out periods, promotions and one-off orders so the model does not learn them as normal demand. - Measure real supplier lead times from order and goods-receipt dates instead of master-data values. - Agree on KPI definitions (service level, stock coverage) with a short glossary (PREP-012).

Rough share of effort: 40-60 percent of the project, mostly master-data clean-up. Run the checklist in GUIDE-003 before choosing a tool.

Implementation paths

Which path for whom

• SMB: Path A. Mature inventory-planning SaaS and ERP add-ons with EU hosting exist at SMB prices and replenishment is a standard process.
• Enterprise: Path B. Replenishment is core to margin and service level, so tuning forecasts and policies on own ERP/WMS data via APIs and a solver pays off more than seat licences.
• Developer: Path C. Open-source forecasting and optimisation libraries (e.g. statsforecast, OR-Tools) run on HW1 and can be embedded into own products.

Path A — Buy (recommended for most)

• Dedicated inventory/supply planning suites: RELEX Solutions (Finland, EU), Slimstock (Netherlands, EU), Lokad (France, EU, probabilistic forecasting with quantitative supply chain approach), Wahupa (Germany, EU), ToolsGroup (Italy, EU), Blue Yonder, o9 Solutions, Kinaxis, SAP IBP, Oracle, Netstock, Inventory Planner and Cin7 for SMB webshops.
• ERP-embedded: SAP S/4HANA and IBP, Microsoft Dynamics 365 Supply Chain Management planning optimisation, Oracle NetSuite, Odoo (EU) reordering rules, Microsoft Business Central.
• Choose A when: standard replenishment processes, existing ERP, no unique constraints. Check ERP connectors, forecast accuracy transparency (can you see the quantile forecasts?), explainable parameters, EU data hosting and how overrides are handled.

Path B — Build on cloud APIs

• Forecasting services: Amazon Forecast is closed to new customers, so use SageMaker/AutoGluon-based stacks, Google BigQuery ML or Vertex AI forecasting, Azure ML/Fabric, or Databricks and Snowflake with pretrained time-series foundation models via API (EU regions).
• Solvers: Gurobi, FICO Xpress, Hexaly (France, EU) or CP-SAT via managed compute; policy logic in Python.
• LLM layer: a frontier model with tool calling (Claude, Gemini, GPT, Mistral) for what-if questions and exception explanations, calling the solver as a tool, never inventing numbers (OPT-018).
• Orchestration: Airflow/Dagster, dbt, or n8n/Power Automate for PO release and e-mail/EDI.
• Choose B when: you have data engineers, special rules the suites cannot model, or want the forecast embedded in your own product.

Path C — Self-host (open source)

• Forecasting: Nixtla StatsForecast/MLForecast/NeuralForecast, Darts, GluonTS, AutoGluon-TimeSeries; pretrained open time-series models such as Chronos / Chronos-Bolt (Amazon), TimesFM (Google), Moirai (Salesforce), Lag-Llama and TiRex, evaluated zero-shot against your baseline.
• Optimisation: Google OR-Tools, HiGHS, Pyomo, PuLP, SCIP; open libraries such as the stockpyl package for classic multi-echelon inventory models.
• Stack: PostgreSQL/DuckDB, Dagster or Airflow, Metabase/Superset; ERP integration via REST/OData.
• Hardware: HW1 suffices (CPU server) for most catalogues; a GPU (HW2) only helps for large neural or foundation-model forecasting over millions of series.

Path D — Custom training

Worth it for very large or unusual networks (hundreds of thousands of SKU-locations, perishable goods, strongly censored demand) where own deep or reinforcement-learning models beat packaged forecasts. Needs two or more years of clean history with stock-outs flagged, a simulator of the supply chain for policy testing, and MLOps for continuous back-testing. M5 results show tree/neural ensembles are hard to beat, so start from open baselines [3].

State of the art (2026)

• Probabilistic forecasting is the norm: the M5 competition (Walmart data) and later work showed gradient boosting and global neural models beating per-series statistical methods on retail data, and evaluation moved to quantile (pinball) loss and service-level outcomes rather than MAPE [3].
• Foundation models for time series (Chronos, TimesFM, Moirai) give strong zero-shot baselines for series with little history, useful for new products; they are still often matched by well-tuned local or boosted models on stable SKUs, so benchmark before replacing [4].
• End-to-end "forecast + decide" learning: decision-focused and reinforcement-learning approaches optimise order quantities directly and show gains in papers and some products, but are harder to govern than classic policies [5].
• Agentic replenishment: LLM agents handle exceptions around a deterministic optimisation core; keep the solver as source of truth.
• Limits and failure modes: censored demand (stock-outs look like low demand), promotions and cannibalisation, cold starts, supplier lead-time shifts, phantom inventory (book vs physical stock, see VIS-019), bullwhip effects from over-tuned parameters, and a "black box" that planners distrust.

Shared resources & combinations

• Forecast layer shared with PRED-001 (demand forecasting), PRED-011 and PRED-016; one time-series platform (HW1/HW2) serves all of them.
• Solver layer shared with OPT-002 (production planning), OPT-006 (slotting), OPT-008 (network design / S&OP), OPT-012.
• Upstream/downstream: OPT-016 and OPT-017 (promotions, assortment) change demand and stock needs; AGENT-005 (procurement agent) and AGENT-004 (order entry) automate PO communication; ANOM-011 (supplier risk) feeds lead-time and risk buffers; VIS-019 verifies physical stock; OPT-001 (routing) consumes the resulting shipments.

Effort, cost & KPIs

• Path A: 2-6 months to roll out including master-data clean-up; subscription pricing mostly by SKU/location count or revenue; SMB tools can start within weeks.
• Path B: 3-6 months for a first production pipeline; costs are engineering time plus modest cloud compute and solver licences.
• Path C: 3-6 months; mainly engineering and operations; no licence cost.
• Path D: 6-12+ months with a data-science team.
• KPIs: service level / fill rate, stock-out rate, inventory value and days of supply, inventory turns, obsolescence and write-offs, forecast bias and quantile loss, share of auto-released orders, planner overrides and their value-add, working-capital release.

People & change

Involve management early for goals (service level versus tied-up capital) and budget, and the department lead (purchasing or logistics) as process owner. Buyers and planners are the end users: let them co-define exception rules and keep the final say over proposed orders, at least during the pilot. IT and the data owners of ERP and item master are needed for exports and interfaces; key suppliers should be told if order rhythms will change.

Works council: usually no, as the data is item-level, not person-level. It becomes relevant if the tool logs or ranks individual buyers' overrides (§87(1) no. 6 BetrVG), and §90(1) no. 3 requires timely information when work processes change with AI. Clarify this up front. Personal data is generally not involved, so a DPIA is not expected; still inform the DPO and sign an AVV with SaaS vendors.

AI literacy: support buyers with short training on reading probabilistic forecasts and safety stock (GUIDE-006). Pilot with one product group and compare against the manual process (GUIDE-009). Typical concern: "the system replaces my experience". Address it by showing overrides are possible and tracked as learning input, and by starting with proposals, not auto-orders. See GUIDE-008 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: minimal risk. Inventory data is not an Annex III use; AI literacy (Art. 4) applies. It would become relevant only if embedded in critical-infrastructure safety components, for example medicines or emergency supply, where sector rules apply [6].
• GDPR: mostly no personal data (SKU-level data). Store-level or loyalty-card based demand signals and supplier contact persons can be personal data: aggregate, minimise and cover with a data-processing agreement.
• Sector rules: pharma and food need batch, expiry and traceability (GDP/GMP, HACCP); public procurement law applies for public bodies; accounting standards (HGB / IAS 2) govern valuation of write-downs.
• Business risks: wrong parameters causing stock-outs or excess; supplier concentration; auto-ordering loops. Mitigations: order-value limits and approval tiers, back-test before go-live, monitoring of forecast bias, kill switch to fall back to previous min/max rules, audit log of proposals versus actions.

Getting started

1. Baseline: current service level, inventory days, write-offs and the share of manual orders per product class (ABC/XYZ segmentation).
2. Extract 2-3 years of sales, stock and PO history; flag stock-outs and fix lead-time master data.
3. Back-test a probabilistic forecast (open-source baseline such as StatsForecast, plus one vendor tool) and compare simulated service level versus stock on your own data.
4. Pilot on one category or location with auto-release disabled; planners review proposals.
5. Enable auto-release for low-value, stable items within guardrails; review KPIs monthly.

Sources

1. RELEX Solutions - inventory optimisation documentation - https://www.relexsolutions.com/
2. Lokad - quantitative supply chain / probabilistic forecasting - https://www.lokad.com/probabilistic-forecasting-definition/
3. Makridakis et al. - M5 accuracy competition: results, findings and conclusions (Int. J. Forecasting, 2022) - https://doi.org/10.1016/j.ijforecast.2021.11.013
4. Ansari et al. - Chronos: Learning the Language of Time Series - https://arxiv.org/abs/2403.07815
5. Stockpyl - Python inventory optimisation library - https://github.com/LarrySnyder/stockpyl
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Nixtla StatsForecast - https://github.com/Nixtla/statsforecast
8. Google OR-Tools - https://developers.google.com/optimization