The reorder point (ROP) is the inventory level at which a new purchase order should be placed. It is sized so that the order arrives just before existing stock is depleted, with a safety buffer for variability.
The formula
ROP = (consumption rate × lead time in days) + safety stock
where:
- consumption rate = average daily demand
- lead time = days from order placement to receipt
- safety stock = z × σ × √(lead time), per the standard formula
Worked example
A retailer sells 12 units of a SKU per day. The supplier ships in 4 days. Daily-demand σ is 3 units. Target service level is 95% (z = 1.65).
- Lead-time demand = 12 × 4 = 48 units
- Safety stock = 1.65 × 3 × √4 = 9.9 units
- ROP ≈ 58 units
When inventory drops to 58 units, place an order.
ROP vs PAR level
These are related but not the same.
- Reorder point is the level .
- PAR level is the level you order up to.
In a continuous-review system, you reorder whenever inventory hits ROP, ordering up to PAR. In a periodic-review system (e.g. you order every Tuesday), you reorder up to PAR regardless of whether ROP was crossed. Most SMBs run periodic.
The two replenishment modes
LineNow supports both:
- Continuous review: orders triggered by inventory crossing ROP. Best for high-velocity items where stockout cost is high.
- Periodic review: orders triggered by the calendar (e.g. weekly). Best for items where consolidation onto a single supplier truck matters more than tightness.
The replenishment trigger types LineNow supports include below_threshold, out_of_stock, always, below_days_of_stock, below_lead_time_coverage, and reorder_point. Each maps to a different operational pattern.
Why ROP is often wrong in practice
The artisanal procurement stack rarely calculates ROP — the operator just orders "when it looks low." This is fine for items with stable demand and a forgiving lead time. It fails badly when:
- Lead times spike (supplier delays, port congestion)
- Demand spikes (a viral mention, a holiday rush)
- Consumption rate drifts (seasonal swings, trend changes)
A real ROP, recomputed daily from POS data, catches all three.
