AI for supply chain when the function is two people and a spreadsheet
AI for supply chain means software that reads your supply and demand records and drafts what to buy, what to promise and what to stock. Most of what is published about it assumes a planning department: a planner, several stocking locations and a suite the reader already runs. A forty-person distributor has none of that, and two people cover buying and order entry between other work. This page sorts the published use cases into the ones that survive at that size and the ones that need a department. It then names what has to be true in your own systems first.
What AI for supply chain means at this size
Software reads the supply and demand records a company already keeps, then drafts the decisions that follow from them. The vendors ranking on this query describe it in roughly that shape, and Kinaxis sets out three generations of it at length. The top result in Canada is an eight-hour online course, which answers how to study the subject.
At an enterprise the supply chain is a function with a head, a planning cycle and a suite bought to serve it. At 20 to 200 people it is a set of desks. Somebody buys. Somebody enters orders. Somebody answers the customer asking where an order is. AI lands on those desks or it lands nowhere.
Canada had 1.10 million employer businesses as of December 2024. Of those, 98.2 percent employ 1 to 99 people and 1.5 percent employ 100 to 499. The counts come from Key Small Business Statistics 2025, published by Innovation, Science and Economic Development Canada. The pages ranking for this query are written for the smaller share of that count.
The same rule holds inside a plant, and what AI does at each desk inside a plant works through it module by module.
The published use cases, and which ones survive
What follows is the enterprise list, taken from what the vendors publish and sorted by whether each item still works without a planning department. One suite alone publishes more than twenty AI capabilities inside its supply chain product, from shipment transit prediction to shift-note generation, per Oracle.
| Use case | What it needs to work | At 20 to 200 people |
|---|---|---|
| Demand forecasting by item | Several years of clean order history per item and steady volume | Thin. It refuses more often than it answers |
| Multi-echelon inventory optimization | Three or more stocking locations and somebody to run scenarios | No. One warehouse has no echelons |
| Route and transport optimization | An own fleet, or more than 50 outbound shipments a week you route yourself | No. The carrier already does this |
| Warehouse slotting and vision counts | A warehouse management system, instrumented racking and more than 500 picks a day | No. It is a different purchase |
| Supplier risk monitoring | External data feeds and one full-time person to act on them the same day | No. Nobody is watching the screen |
| Reading supplier quotes and confirmations | A mailbox and an item master | Yes |
| Order entry from emailed purchase orders | A price file and a catalogue | Yes |
| Checking a purchase line against the price last paid | Purchase history that can be exported | Yes |
| Promise dates from the span you actually ran | Dated release and ship records | Yes, if the dates are recorded |
| Asking one question across the ERP, the mailbox and the files | One reconciled record | Yes |
The survivors share one shape. Each reads a record already inside the company: the mailbox, the item master, the price file, the purchase history and the dated ship records. No rack, truck or scanner has to be instrumented before the work starts.
The rows that fail need either a volume this company does not have or a person it does not employ. The counts in the middle column that carry no link are my own rules of thumb at this size. No vendor publishes a floor of its own.
Forecasting is the honest exception among the survivors. It is the least proven of them at this size and the one to build last.
What does not work at this scale, and why
Three failures are worth spelling out. One is a row in the table above. The other two sit underneath it, in the headcount the enterprise answers assume and the unit the licence is charged in.
Forecasting by item fails on data. A model needs repeated demand to find a pattern. A distributor carrying 4,000 items, where most move a handful of times a year, has intermittent demand. A forecast built on four data points is a guess with a decimal point on it. The right behaviour is to refuse and name the items whose history is too thin to read.
The planner saving fails on headcount. Kinaxis reports that planners often spend more than half their time sorting through dashboards and filters to track down late supplies and coordinate fixes. Capgemini research in 2025 found that AI adoption in supply chains reduced fulfillment costs by 23 percent on average, as reported by Kinaxis. Those are real savings at a company with planners and a fulfillment operation measured that way. There is no planner here.
Price fails on the unit it is charged in. Microsoft lists Dynamics 365 Supply Chain Management at 210 US dollars per user per month paid yearly, with a premium tier at 300. The benefit of a planning suite is sized for a department, and the licence is charged per seat. Two seats buy a department's tool to cover two people's desks.
The enterprise answers work where they were designed to work, on the volumes and the org charts they were built against.
The three desks worth doing first
The survivors from the table collapse into three desks, and all three run on records the company already holds. The plant-side version of the same list appears in what AI does at each desk inside a plant.
Order entry
A customer purchase order arrives as an email attachment in that customer's own layout. Somebody retypes it into the ERP line by line. Software reads the attachment and matches each line against the price file and the catalogue. It drafts the order with every mismatch called out on the line it belongs to. The desk accepts the draft or corrects it.
This desk can go early, because the work is legible and the volume is daily.
At a machine shop, requests arrive in the mailbox and leave as drafts. A draft estimate lands in the accounting system and a draft reply lands in the mailbox. Nothing is sent. The end-to-end run-through is still outstanding.
Which desk carries the whole function
Name the two people who cover buying and order entry, and what the ERP is. I will tell you what it would take to read it.
Start a conversationBuying against the price last paid
Supplier quotes arrive as PDFs and somebody retypes them into a purchase order. The price last paid sits in the ERP, and checking it by hand takes longer than trusting the quote. Software reads each PDF, matches every line to the part it is for, and sets the quoted price against the price last paid. Lines that moved are flagged with the size of the move and the date of the last purchase. A line it cannot match is named rather than dropped. The mechanics of reading a supplier PDF into fields are a problem of their own.
Promise dates you can defend
Dates get made from optimism. Metal fabricators run about 84 percent on-time delivery industry wide, against better than 90 percent in the top quartile. The benchmark comes from a Fabricators and Manufacturers Association survey cited by Infor in August 2026. Roughly one order in six lands after the date somebody promised. Software reads the span the company ran between release and ship for work of that shape. It checks the customer's contract term against that span and shows the conflict. Nothing auto-fills. The desk types the date it is willing to commit to.
The record underneath all three
None of the three desks runs on a chat window pointed at the ERP. Each one needs a single record of the business, assembled out of the systems already owned. That means the ERP, the mailbox, the supplier documents, the shared drive and the spreadsheets. All of it is copied into one data warehouse. Nothing is replaced and nothing is migrated.
Reconciliation comes next. The same item has to mean the same thing in every file. The code in the ERP, the code on the supplier's sheet and the code in the price file often differ. The difference is a suffix, a space or a revision letter. Until that is settled, a number assembled across two files is a guess. Once it is settled, where an order stands is one query rather than three screens.
Every value keeps a line back to the record it came from, so a disputed price opens to the invoice behind it. When the record cannot answer, the system says so and names what is missing, because a silent zero gets quoted. A named person approves every order, every message and every write-back. That shape is what one record of your own business, on your own server describes in full.
At a distributor, 39 GB across more than 14,000 files disagreed with each other. One catalogue now feeds four systems, and most values carry a recorded origin. The verification queue is deployed and its backlog has not been worked yet.
Derik at Thrive was instrumental in taking incredibly messy data we inherited in a business we acquired and, through using AI, organized it in record time in a way that made it reviewable by our team for final review and approval. He proposed solutions that were effective to implement and everyone on our team was impressed and happy to work with him.
Rios-Karim Mercier, Belmont Capital.
Where the data sits, and where the model runs
Supply data carries the customer list, the supplier prices and the margins, which is why the question comes up before the second meeting.
Your data stays at rest on your own server in Canada, one dedicated machine for your business. Inference runs one of two ways and you pick. It runs on that same server with an open-weight model, so nothing leaves the box. Or it runs through a frontier model under a written zero-data-retention control, with the model tier named in the contract. Zero retention is not available for every tier.
That is a description of a control and not an audited certification. There is no SOC 2 here and no compliance opinion about Loi 25 or any other statute. The control is written down so your own counsel can read it and draw the conclusion.
What to check before you spend anything
Four conditions decide whether any of the three desks can start, and all four are answerable from inside systems you already own.
- The ERP can export the item, customer, supplier, price and purchase history tables on a schedule. A nightly file drop, a read-only SQL connection or a published REST endpoint counts, and a screen you can only print does not.
- Purchase history carries the price actually paid and the date it was paid, rather than a standard cost set once and left there. Open one part and read its last three purchase lines.
- Release and ship dates are recorded per order, on the order rather than in somebody's memory. Pull last quarter's shipped orders and count how many carry both dates.
- Somebody owns the answer when two files disagree. Reconciliation is a decision, and a decision needs a name attached to it.
Check 1 is the one that varies by system. SAP Business One holds its tables in SQL Server or HANA and takes a read-only account. Dynamics 365 Business Central publishes OData and API endpoints per company. An older on-premise ERP usually has a report writer that can schedule a file to a folder.
When a managed service provider hosts the ERP, ask your account manager for a read-only login or access to the export scheduler. That is a permission conversation rather than a purchase.
The published explainers name data readiness as a prerequisite and then leave it there without a test. Your controller can answer all four of these in an afternoon, and none of them requires buying anything.
Where to start
Pick the desk where one person is the bottleneck and the record already exists. For most distributors that is order entry. For most custom manufacturers it is the purchase order or the quote behind it.
Plan on weeks rather than days between the first export and the first usable draft. The reconciliation above has to hold before a draft is worth reading.
Run it in draft beside that person for a few weeks while they keep working the way they work today. Compare the draft against what they did, line by line, on the orders that actually arrived. Widen only once the first desk is boring.
Judge the result against that desk's own output rather than against a vendor benchmark. The baseline that matters is what your two people produce this month. What building on your own data involves covers the rest of the mechanics.