Min/Max is the replenishment setting everyone configures at go-live and almost nobody revisits, and the most expensive mistakes I see with it aren't about picking the wrong numbers — they're about people misunderstanding what the mechanism actually does, especially once MRP is in the picture. This is a practical walkthrough of how Min/Max replenishment triggers in Acumatica Inventory, how the parameters get set, and the MRP-versus-Inventory-Replenishment mix-up that causes more confused support tickets than any bad formula.
How Min/Max actually triggers a replenishment calculation
Acumatica's Inventory Replenishment supports the Min/Max method as one of its replenishment approaches, and the model is a threshold, not a forecast: it keeps stock for an item at a given warehouse somewhere between a minimum quantity (the reorder point) and a maximum quantity. When the available quantity for that item at that warehouse hits or falls below the reorder point, the system calculates a replenishment quantity — sized to bring the item back up to the maximum by filling the gap between the max, the on-hand quantity, and whatever is already on supply (on order but not yet received). It doesn't add a flat amount and it doesn't ask why the level dropped; it just closes the gap to Max.
That's the entire trigger logic. It's deliberately simple, and the simplicity is the point for the right items: a stable, low-variability SKU doesn't need anything smarter than "reorder to Max when you hit the floor," and a planner can sanity-check the numbers on sight. Where it gets people is treating a fixed Min/Max pair as permanent — demand shifts, and a Min sized for last year's average gets blown through in one large order.
Manual entry versus forecast-driven auto-calculation
The three numbers that drive this — safety stock, maximum quantity, reorder point — can be entered two ways. You can type them in manually per stock item, which is the default at go-live and remains the right call for items with erratic or one-off demand where no formula should be trusted over a planner's judgment. Or they can be auto-calculated from a demand forecast model built on sales history, which is where Acumatica's forecasting can save a planner from re-tuning hundreds of SKUs by hand every quarter.
The catch with forecast-driven auto-calc is the obvious one, but it still catches people: it only works with enough sales history behind it. A brand-new item, or one that just went through a supplier or packaging change that resets its sales trail, has nothing for the forecast model to learn from — auto-calculated parameters on a thin history are garbage in, garbage out, and will hand you a Min/Max pair that looks calculated and authoritative but is really just noise. For new items, start with manually entered parameters based on a comparable existing SKU or a manager's estimate, and only let the forecast model take over once there's a real sales history to calculate from.
Manual or forecast-driven, these parameters go stale. A vendor lead-time change or a demand shift won't update a manually entered Min/Max on its own, and a forecast model retrains on a rolling window that can lag a sudden shift too. Put a recurring review on the calendar rather than assuming either method is "set and forget."
MRP versus Inventory Replenishment: not the same subsystem
This is the distinction that causes the most confusion, and it's worth being explicit about because the two subsystems look like they should behave the same way and don't. Material Requirements Planning (MRP) in Acumatica does support safety stock and a reorder point — but MRP does not reorder up to a maximum quantity the way Inventory Replenishment's Min/Max method does. They are two separate subsystems with different behavior, not two views onto the same calculation.
Concretely, here's what breaks: someone configures Max on a stock item, assumes MRP will "top up to Max" once the reorder point is breached the same way Min/Max replenishment would, and then is confused when an MRP-generated purchase suggestion comes back sized differently than expected — sometimes smaller, sometimes not generated at all when they expected one. MRP is netting demand against safety stock and reorder point across sales orders, forecasts, and existing supply; it isn't reading Max as a fill target the way the Inventory Replenishment engine does. If your planning process runs through MRP Preview and MRP Recalculation, the Max field on the stock item is not driving MRP's suggested quantities the way it drives a Min/Max replenishment run outside of MRP.
The practical takeaway: know which subsystem is actually generating your purchase suggestions before you tune parameters to influence it. Tuning Max to shape MRP output is tuning a number that subsystem doesn't use for that purpose.
A quick way to check what needs attention
A generic inquiry over the item's site status joined to its replenishment settings is a fast way to surface items where available quantity has dropped to or below the reorder point, without waiting for the next scheduled replenishment or MRP run:
SELECT
iss.InventoryID,
iss.SiteID,
iss.QtyOnHand,
iss.QtyOnOrder,
(iss.QtyOnHand + iss.QtyOnOrder - iss.QtyAllocated) AS AvailableQty,
ic.ReplenishmentMethod,
ic.MinQty,
ic.MaxQty,
ic.ReorderPoint,
ic.SafetyStock,
ic.LeadTime
FROM INSiteStatus iss
INNER JOIN INItemSiteSettings ic
ON ic.InventoryID = iss.InventoryID
AND ic.SiteID = iss.SiteID
WHERE ic.ReplenishmentMethod IN ('M', 'R')
AND (iss.QtyOnHand + iss.QtyOnOrder - iss.QtyAllocated)
<= CASE ic.ReplenishmentMethod
WHEN 'M' THEN ic.MinQty
ELSE ic.ReorderPoint
END
ORDER BY AvailableQty ASC;
Treat the field and table names as illustrative — verify the actual DAC and generic-inquiry field mappings in your build before wiring this into a dashboard, since exact naming can shift slightly by version.
Wrapping up
| Question | What decides it |
|---|---|
| Should this item use Min/Max? | Stable, low-variability demand — the threshold-to-Max model is simple and good enough |
| Manual or forecast-driven parameters? | Forecast-driven only once there's enough sales history; manual for new or erratic items |
| Is MRP generating the suggestion, or Inventory Replenishment? | Know which subsystem runs first — MRP nets safety stock and reorder point but does not fill to Max |
| Why does the PO look wrong? | Check which subsystem produced it before assuming the Min/Max/reorder point numbers are broken |
Min/Max replenishment in Acumatica Inventory is a simple mechanism — hit the reorder point, fill the gap to Max — and it's a good fit for stable demand whether the parameters are typed in by hand or calculated from a forecast with enough history behind it. The mistake that costs the most time isn't a badly tuned number, it's assuming MRP behaves like Inventory Replenishment's Min/Max method. It doesn't: MRP nets demand against safety stock and reorder point, but it will not top a stock item up to Max the way the Min/Max method does. Know which subsystem is actually producing your purchase suggestions before you tune parameters expecting it to behave like the other one.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.