TL;DR: Most manufacturers do not have AI running their purchase orders. The real opportunity is not making a PO document faster. It is reading supplier replies, chasing missing acknowledgments, identifying date changes, and writing clean updates back into the ERP after the PO has already been sent.
Watch enough vendor demos and you'll see the same four seconds. Someone types a plain-English request, the system produces a formatted purchase order with the right vendor record, the right GL code, the right terms, and everyone nods.
Then a buyer in the back asks who tells her when it's late.
That question usually gets answered with a dashboard. Which is to say it doesn't get answered, because a dashboard reports what the ERP already knows, and the ERP only knows what somebody typed into it.
Why the Market Means "PO Generator"
Search the term and the results split into two camps, neither of which matches the daily PO work inside most manufacturing teams.
The first is document generation. Type a request, get a PO. That can be useful if your purchasing process runs on Slack messages and someone's memory. It is mostly irrelevant if your POs already flow out of MRP or ERP logic after a planning run. For many manufacturers, PO creation is not the bottleneck and not the AI problem worth solving.
The second camp is document capture, and it's the bigger one. Yooz, Stampli, and the broader intelligent document processing category grew up on accounts payable, where the volume is enormous and the documents are standardized enough to train on. Point that engine at a supplier invoice and it will pull vendor, line items, quantities, and prices with high accuracy. The technology is good and the accuracy claims are mostly fair.
It solves an AP problem, though. Those tools work the back end of the transaction, after goods have arrived and someone needs to pay for them. By that point the buyer's part has been over for three months.
So when the category says "AI purchase order," it often points at the endpoints: create the document or read the invoice. The operational problem sits in the middle, where the buyer is still chasing suppliers, interpreting replies, updating dates, and keeping planners from working off stale information.
The Stretch Nobody Sells You Software For
Here's the part of a PO's life that consumes your team. You send the order. You wait for an acknowledgment that may never come. You confirm the ship date, then confirm it again six weeks later because the first confirmation is stale. A supplier emails to say line 4 slipped, and that email lands in one buyer's inbox and nowhere else. Engineering revises the drawing, so the PO gets changed, and now the supplier is working from a revision that crossed your change notice in flight. Partial shipment arrives. Someone has to decide whether the balance is still coming or quietly dead.
None of that is document processing. All of it is correspondence, and correspondence is where the hours go.
Supplier acknowledgment reaches a buyer through one of three channels: an EDI 855 transaction, a supplier portal login, or a plain email reply. The first two produce structured data automatically. The third covers most direct-materials suppliers and produces nothing structured unless something reads the message and pulls the fields out of it.
We wrote about the open PO list and what it hides, and the through-line is the same. The data in your ERP is only as current as the last time a human read an email and typed something in. Automate the typing and you've automated a keystroke. Automate the reading, the chasing, and the writing back, and you've automated the job.
Why the Middle Went Unbuilt for Twenty Years
This wasn't an oversight. For most of the history of procurement software, there were exactly two ways to get structured data out of a supplier, and both of them worked by making the supplier produce the structure.
EDI was the first. It's excellent, and it requires the supplier to run a translator, hold a VAN contract or an AS2 connection, and map their fields to yours. That investment pays back at volume. A shop doing eleven POs a year with you will never make it.
Portals were the second, and they moved the same burden into a browser. Cheaper to deploy, worse to adopt, because now the work is manual again and it's the supplier doing it for free on your schedule. Ariba, Coupa, and every OEM that built its own supplier portal all discovered the same thing: your top 50 suppliers by spend log in, and the long tail doesn't.
Both approaches share an assumption that once looked like physics. If you want machine-readable data, someone has to make it machine-readable, and it may as well be the party sending it. Reading a free-form email and reliably pulling a date, a quantity, and a price out of it wasn't something software could do, so the industry designed around the limitation for two decades.
That constraint is the thing that actually lifted. Extracting structured commitments from unstructured supplier correspondence went from unsolved to routine in a few years, which means the burden can finally sit on the buyer's side of the wire where it belongs. Your supplier writes an email the way they always have. The structure gets manufactured after it arrives.
Most of the category hasn't repriced around that yet. A lot of tooling still assumes supplier adoption is the way in, which is why so many roadmaps lead back to a portal.
A Stage-by-Stage Read
A purchase order passes through six operational stages between request and close: ERP creation and release, transmission to the supplier, acknowledgment, in-flight status and date management, receipt and matching, and change handling. Existing systems cover the transactional steps better than the communication steps.
PO stage | What existing systems usually cover | Where the work still lives |
|---|---|---|
PO creation and ERP release | ERP/MRP workflow and approval logic | Usually not the bottleneck for direct teams |
Sending to supplier | Yes | Wrong contact, wrong thread, attachments stripped |
Acknowledgment capture | Only via EDI or portal | Most direct-materials suppliers use neither |
In-flight date and status updates | Rarely | Lives in email; nothing writes it back |
Receipt and 3-way match | Yes, within tolerance | Partial and over-shipments fall out to manual |
Change orders and revisions | Partly | Supplier and buyer versions cross constantly |
The coverage clusters at the transactional ends of the process. Everything in the middle depends on supplier communication, and that is where most teams still rely on buyers reading, interpreting, chasing, and updating by hand.
The receipt row deserves a caveat, because "automated within tolerance" hides a lot. Three-way match works cleanly when the PO, the receipt, and the invoice agree inside your configured limits. Every exception outside those limits routes to a human, and on direct materials the exception rate is not small: short shipments, substituted parts, freight billed separately, price changes the supplier never flagged. The 3-way match is automated in the sense that the easy cases clear themselves.
Where AI Still Fails on Purchase Orders
Start with the replies themselves, because a lot of them don't say anything. "Should ship end of month" is not a date. "We're working on it" acknowledges nothing. A model can flag those as non-answers, which is useful, but it cannot invent a commitment the supplier declined to make. Treating a vague reply as a confirmed date is worse than having no date at all, so the correct behavior is to escalate rather than resolve.
Unit-of-measure mismatches remain a trap. The quote came back priced per thousand, the PO is written per each, and the supplier's acknowledgment restates their own convention. Reconciling that requires the conversion rule for that specific part, pulled from your item master rather than inferred from context. Get it wrong and you've silently multiplied a price by a thousand.
Partial shipments cause more trouble than they should. A line for 500 units with 180 received is not 36% complete in any way that matters, because the remaining 320 might be scheduled, might be short-shipped and closed, or might be waiting on raw material the supplier hasn't mentioned yet. Which of those is true is usually buried in an email thread, and sometimes in a phone call that never got logged anywhere.
Then there's thread hygiene, which sounds trivial and isn't. Suppliers reply to whatever email sits nearest the top of their inbox, and that is regularly the wrong PO. Any system reading supplier mail has to reconcile the stated PO number against part numbers and thread history, and when those three disagree it should ask rather than guess. Write-back is the place this gets expensive, since a bad extraction becomes a bad planning input, which is why the write needs to be scoped, logged, and reversible.
The common thread across those four is that extraction is dependable when a supplier states a fact and unreliable when a supplier states an intention. A confirmed ship date parses. An expression of intent does not. Any system handling PO correspondence needs a confidence threshold and a defined escalation path for everything that falls below it.
What Stays With the Buyer
Work that's repetitive, high-volume, and sitting between two systems belongs to software. The judgment calls belong to your buyers.
The judgment list is shorter than people assume but it carries the weight. Choosing between a supplier who can hit the date at a higher price and one who can't. Deciding whether an eleven-day slip means you resource the part, expedite freight, or move the build. Accepting risk on a single-source part when there's no second source to be had. Telling a supplier their quality escape has consequences, which is a relationship question as much as a commercial one.
Reading 60 supplier emails to find the four that contain a real date change is a different kind of task. It requires context, matching, confidence, and a clean write-back path, and it takes up a large part of the week precisely because most systems do not handle it.
What a procurement team does with the hours it gets back is a genuinely open question, and the answers we hear vary a lot by company.
How to Tell Mechanism From Marketing
If you're evaluating anything in this space, the demos all look similar and the differences show up in a handful of questions.
Ask what happens when a supplier replies in an unstructured email with no PO number. If the answer involves the supplier logging into something, you're being sold a portal with an AI label, and portal adoption among small suppliers has been a solved-on-paper problem for fifteen years. Ask which fields it writes back to your ERP and whether you can see a log of every write. Vagueness there usually means the integration is read-only.
The one that separates products built by people who have run procurement from products built by people who have read about it: does it handle a PO revision that crosses a supplier reply in flight? Both sides now hold a document the other hasn't seen. Good answers involve version comparison and an explicit reconciliation step. Weaker answers involve the word "sync," and it's worth pushing until you understand which one you're looking at.
Then ask what it does when it isn't sure. A system with no escalation path will confidently write a wrong date into your planning run.
We've laid out a fuller version of this evaluation in our look at AI purchase order management software, including which tools stop at PO creation.
The Short Version
PO creation got attention because it is clean to demo. PO follow-through did not, because it means working through messy correspondence from suppliers who will never adopt your systems, then deciding what is safe to update in the ERP. That is the hard part, and it is the part most teams still do manually.
If you're assessing AI for purchase orders, measure the tools against the middle of the lifecycle. Ask what happens on day 40 rather than day zero, and press on the specifics of acknowledgment capture, in-flight date changes, and ERP write-back. Much of the category has nothing to say about that stretch.
Lumari works the middle stretch: it requests acknowledgments, chases the ship date, reads whatever the supplier sends back, flags the replies that dodge the question, and writes confirmed dates into your ERP with a record of every change. Suppliers keep using email, and buyers get a system that can manage the follow-through instead of leaving every update trapped in an inbox. If you want to see it against your own PO follow-up workload, we'll run it on your open orders.
