.jpg)
.png)
Inventory replenishment decisions are made every day in manufacturing and distribution. The inputs are straightforward: current stock levels, reorder points, lead times, and demand signals. The problem is that in most mid-market operations, turning those inputs into action requires a person to look at a report, decide something needs to be ordered, and manually initiate the process.
That's not a judgment call. It's a pattern match. And pattern matching is exactly what automation handles well.
This post walks through how to build an automated inventory replenishment workflow that monitors stock levels, applies your replenishment logic, and initiates the right action, without a person doing the routine monitoring work.
Manual replenishment workflows depend on someone checking inventory reports regularly and acting before stockouts occur. The failure modes are predictable:
Each of these produces the same outcome: either a stockout that disrupts production or customer fulfillment, or excess inventory from over-ordering to compensate for uncertainty.
Automation doesn't make better judgment calls than an experienced buyer. It makes the routine judgment calls consistently, at the right frequency, and flags the exceptions that genuinely need human review.
An automated replenishment workflow needs four inputs:
If these exist in your ERP, the automation can read them. If they're inconsistent or out of date, that's a prerequisite cleanup task before automating the workflow.
Inventory replenishment automation can be triggered in three ways, depending on how your ERP handles inventory updates.
Pattern 1: Event-driven (preferred)
The ERP fires a webhook when an inventory adjustment occurs (a sale is processed, a transfer is completed, a receipt is recorded). n8n receives the event and immediately checks whether the adjustment pushed any affected SKUs below their reorder point.
This is the most responsive approach. The check happens the moment inventory changes, not on a schedule.
Pattern 2: Scheduled polling
If the ERP doesn't support webhooks for inventory events, n8n runs a scheduled query (every 15 or 30 minutes) against the ERP's inventory API, comparing current levels to reorder points and identifying any items below threshold.
This introduces a small lag but works with any ERP that has a queryable inventory API.
Pattern 3: Batch (fallback)
For ERP systems with limited API access, n8n processes a daily inventory export file (CSV or similar) and applies the replenishment logic against it. Less responsive than the first two patterns, but still more consistent than manual report checking.
Most modern ERP systems support Pattern 1 or 2. Pattern 3 is the fallback for legacy systems.
Once the inventory check identifies an item below its reorder point, the workflow applies the replenishment logic:
Item below reorder point detected
↓
Is there already an open PO for this item?
YES → Is the open PO sufficient to cover the gap?
YES → Log, no action needed
NO → Alert buyer: open PO may not be sufficient
NO → Apply order quantity logic
↓
Calculate order quantity (EOQ, min order, or fixed quantity)
↓
Identify correct supplier from item master
↓
Does this PO require approval?
YES → Route to approval (Retool interface or email)
NO → Generate PO automatically and send to supplier
↓
Log PO creation, update ERP, notify relevant buyer
The "does this require approval" branch is where most operations want human oversight. Typically:
These rules live in the workflow logic and can be adjusted without rebuilding the integration.
Step 1: Set up the inventory trigger
Configure a webhook in the ERP to fire on inventory adjustment events, or create a scheduled workflow in n8n that polls the ERP's inventory API at a defined interval.
In n8n, this is the trigger node. For scheduled polling, use the Schedule Trigger node. For webhook-based triggers, use the Webhook node and configure the ERP to POST to the n8n endpoint.
Step 2: Query current inventory and reorder points
Using the HTTP Request node (or a pre-built ERP node if available), pull the current quantity on hand and the reorder point for each item that triggered the check.
For scheduled polling, this is a single query that returns all items below their reorder point. For event-driven triggers, it's a targeted query for the specific item affected by the inventory event.
Step 3: Check for existing open POs
For each item below reorder point, query the ERP's open purchase orders to see if a replenishment order already exists. This prevents duplicate orders from being generated.
If an open PO exists but the quantity won't fully cover the deficit, flag it for buyer review rather than automatically generating a second PO.
Step 4: Apply order quantity logic
For items that need a new PO, calculate the order quantity using a Google Cloud Function if the logic is complex (variable MOQ tiers, multi-supplier optimization, demand-weighted order sizing), or directly in n8n using the Code node for simpler rules.
The output of this step is: item, supplier, quantity, and whether approval is required.
Step 5: Route for approval or auto-generate
Items requiring approval are sent to the Retool approval interface (see next section). Items below the auto-approve threshold have a PO generated via the ERP's API and sent to the supplier automatically.
Step 6: Log and notify
Every replenishment event, approved or auto-generated, is logged in the ERP with a timestamp and method. A summary notification goes to the buying team showing what was triggered, what was auto-generated, and what's pending their approval.
For replenishment POs that require human approval, a Retool app provides a simple, functional interface without requiring the buyer to log into the ERP:
When the buyer approves in Retool, the app writes back to n8n via webhook, which then generates the PO in the ERP and sends it to the supplier.
This keeps the approval step efficient without making the buyer do ERP data entry.
A replenishment automation is only as reliable as its exception handling. Common exceptions to build for:
Supplier lead time change If a supplier's lead time increases, existing reorder points may no longer trigger early enough. The workflow can flag this when a supplier confirmation comes back with a longer-than-expected lead time and alert the buyer to review affected reorder points.
Demand spike If consumption velocity increases significantly (a large order depletes inventory faster than the reorder point anticipated), the workflow should detect this and either trigger an emergency replenishment or alert the buyer, depending on the item's criticality.
Supplier minimum order not met If the calculated order quantity falls below the supplier's minimum, the workflow flags it rather than sending an order the supplier will reject. The buyer sees the exception and decides whether to order the minimum, source from a different supplier, or delay.
Item on hold or discontinued If an item is flagged in the ERP as discontinued or on purchasing hold, the replenishment workflow skips it and notifies the buyer to review the reorder point configuration.
For buyers and procurement teams, the shift from manual to automated replenishment changes the nature of the work:
Before: Monitor inventory reports, identify items approaching reorder point, manually create POs, send to suppliers, track confirmations.
After: Review the exception queue, approve high-value POs, handle supplier exceptions, and focus on strategic sourcing decisions that automation can't make, like evaluating new suppliers, renegotiating terms, or adjusting safety stock for demand seasonality.
The routine work runs automatically. The buyer's time goes to the decisions that require judgment.
.png)
