How to Automate Purchase Orders with AI: A Practical Guide for Distributors

Most distributors don't have a purchasing problem. They have a timing problem.

The stock runs low. Someone notices. They pull a report, check with the warehouse, figure out what to order, and send a PO to the supplier. By the time that cycle completes - assuming nothing falls through the cracks - they've either overordered to be safe, or they're already out of stock and scrambling. Neither is good.

We worked with a retail distributor based in Saudi Arabia who was running this cycle manually, across hundreds of SKUs, with a purchasing team spending most of their week on POs that could have been automated. After building them an AI-powered inventory prediction and auto-ordering system, 90% of those POs now generate and send themselves. The team shifted from doing the work to reviewing exceptions.

Here's exactly how we built it.

The Problem With "Just Check the Inventory Reports"

Before we built anything, we spent time understanding what the operations team actually did every day. The honest answer was: a lot of gut-feel decision-making disguised as process.

They'd look at current stock levels. They'd think about what they sold last week. They'd factor in an upcoming promotion, or a supplier who's been slow lately, or the fact that Ramadan is coming and certain SKUs always spike. Then they'd decide how much to order.

That's not a bad process. It's actually a pretty good one - when a human with five years of experience is doing it. The problem is it doesn't scale, it doesn't run on weekends, and it walks out the door when that person leaves.

What we needed to build was a system that could learn those patterns and make the same decisions - faster, more consistently, and without anyone needing to be in the loop for routine orders.

What We Built: XGBoost for Prediction, Django for Orchestration

The system has two main layers. The first is the prediction model. The second is the automation layer that acts on those predictions.

The Prediction Model

We used XGBoost - a machine learning algorithm that's particularly good at finding patterns in tabular data like sales history, stock movements, and dates. For non-technical readers: think of it as a system that looks at two or three years of historical data and learns to answer one question extremely well: given everything we know right now, how much of this SKU will we sell over the next 14 days?

The model was trained on the distributor's historical sales data, broken down by SKU, location, day of week, and month. We also fed it external signals: Saudi public holidays, promotional calendar flags, and supplier lead time data pulled from their ERP.

What came out was a demand forecast per SKU - not a single number, but a range, with a confidence score. That matters because a SKU with volatile demand needs a different reorder buffer than one that sells at a dead-steady pace.

Dynamic Reorder Thresholds

This is the part most off-the-shelf tools get wrong. They let you set a static reorder point - "when stock drops below 50 units, order more." That works fine until your sales pattern changes, which it will.

Our system calculates reorder thresholds dynamically, per SKU, based on the current forecast. If the model predicts a 40% demand spike over the next two weeks (Ramadan, a promotion, a competitor going out of stock), the reorder threshold rises automatically. If it's a slow period, it drops. The business doesn't have to manually adjust anything - the model handles it.

The Django Backend

The orchestration layer was built in Django. Every few hours, it runs a job that does three things:

1. Pulls current stock levels from the ERP via API
2. Runs each SKU through the prediction model
3. Compares current stock against the dynamically calculated reorder threshold

If a SKU falls below its threshold, the system generates a draft purchase order - supplier, quantity, delivery window - and either sends it automatically (for pre-approved suppliers and routine SKUs) or routes it to a reviewer dashboard for anything above a spend threshold or flagged as unusual.

The entire PO, from detection to generation, takes under a minute. No human involved unless the system decides one is needed.

What Triggers an Auto-Order

The trigger logic was one of the most important things we calibrated carefully.

A lot of systems fail here because they trigger on raw stock level alone. That leads to phantom urgency - you reorder something that's "low" but actually has three weeks of supply left based on current demand. It wastes cash and clutters the purchasing queue.

Our trigger is based on days of supply remaining, not units. The model takes the current stock level and divides it by the forecasted daily demand rate. If a SKU has fewer than 12 days of supply remaining (configurable), and the supplier lead time is 7 days, the system flags it. That 5-day buffer is what gives the ops team room to breathe.

For fast-moving SKUs with volatile demand, we tightened that buffer. For slow-moving ones with long shelf life and consistent demand, we loosened it. These were all decisions made collaboratively with the client's purchasing team - they knew their suppliers and their cash flow constraints better than we did, and the system needed to reflect that.

What the Operations Team Actually Stopped Doing

Before this system, the purchasing team's week looked roughly like this: daily stock checks, weekly demand review meetings, manual PO creation in their ERP, chasing supplier confirmations, updating spreadsheets to track what's been ordered versus what's arrived.

After: they review a dashboard every morning that shows them the exceptions. Orders that were blocked because spend was above threshold. A new supplier that hasn't been pre-approved yet. An SKU where the model's confidence score was low because the sales pattern suddenly changed. The stuff that genuinely needs a human.

The 90% reduction in manual POs isn't a made-up benchmark - it's what happened when routine reordering became automatic and human attention got reserved for decisions that actually benefit from human judgment.

The team didn't shrink. They moved up. Instead of processing routine orders, they're now managing supplier relationships, running the exception queue, and spending time on procurement strategy they never had capacity for before.

What This Kind of System Costs to Build

There's no flat answer, but there are clear variables. The more fragmented your data sources are - ERP here, spreadsheets there, supplier lead times in someone's email - the more the data pipeline work dominates the project. The model itself is often the fastest part.

For the KSA distributor we built this for, the biggest lift was getting clean, reliable historical data out of their legacy ERP. Once that was solved, the ML and automation layer came together quickly.

A system like this is typically appropriate for distributors managing 100+ SKUs with meaningful sales history. Below that, simpler rule-based reorder logic is often faster and cheaper to implement. We'll tell you honestly which camp you're in.

Where to Start If You're Evaluating This

Don't start with the model. Start with your data.

Pull 12–18 months of sales history by SKU and ask yourself: is this clean? Are there gaps? Is the same product recorded consistently across locations? Most companies find problems here they didn't know existed, and fixing them is what makes the downstream system actually work.

If you want to know whether your data is in good enough shape to support a system like this - and what the realistic ROI looks like for your SKU volume and order frequency - we're happy to work through it with you.

Get in touch with O2Devs and tell us what you're working with. We'll give you a straight answer.