How AI reads a purchase order, and where it still needs a person
Not long ago, automating order entry meant writing a template for every customer: this field is in this position on this PDF. It worked until a customer changed their layout, and it never worked for orders typed into an email.
Large language models changed that. They can read a purchase order the way a person does, whatever the layout. But using them well in a business process takes more than sending a PDF to an AI and trusting the answer.
Step one: gather everything
An order is rarely a single document. The PO might be a PDF, the delivery instructions in the email body, and an extra line added in a reply. So the first step is to bundle the email and all of its attachments together, converting spreadsheets and Word documents into a form the model can read alongside the PDF.
Step two: extract to a fixed structure
The model isn’t asked to “summarise the order”. It’s asked to fill in a specific structure: customer, PO number, order date, contact details, delivery address, delivery date, delivery instructions and a list of lines with product, quantity and unit price.
Asking for a fixed structure makes the output predictable and easy to check. If a value isn’t in the order, the field stays empty. It shouldn’t be guessed.
Step three: score the confidence
Alongside each value, the model gives a confidence score. A PO number printed clearly in a header scores highly. A quantity read from a blurry scanned table, or a delivery date written as “next Thursday”, scores lower.
We treat anything below 7 out of 10 as a warning. It doesn’t stop the order. It tells the reviewer exactly where to look.
Step four: check with code, not AI
This part is often missed. Once the data is extracted, ordinary code checks it against your ERP. These checks are deterministic, meaning they give the same answer every time:
- Does this product code exist?
- Is there enough stock?
- Does the price match the price in the ERP for this customer?
- Have we already received this PO number from this customer?
- Which customer account does this sender belong to?
AI is good at reading messy documents. Code is better at checking facts. Using each for what it’s good at gives you a far more reliable result than either on its own.
Where it still needs a person
Even with good extraction and thorough checks, some things need judgement:
- Poor scans and handwriting. The model will usually read them, but with less certainty.
- Customer product codes. A customer may use their own part numbers or descriptions instead of yours.
- Units of measure. “10 x copper pipe” might mean ten lengths or ten packs of ten.
- Relative dates. “Thursday” in an email sent on a Friday is ambiguous.
- Commercial decisions. Whether to honour an old price, or ship part of an order when stock is short.
None of these is a failure of the technology. They’re the same questions a new member of staff would have to ask.
Why we keep a human in the loop
For these reasons, every order we process waits for a person to approve it before it goes anywhere. The reviewer sees the extracted order next to the original email, with every warning shown against the field it relates to. Most orders need a quick check and a click. A few need a correction or a call to the customer.
Over time, once you’ve seen how reliably clean orders come through, it can make sense to approve some of them automatically. For example, orders from known customers where every field scores highly and every check passes. We build that capability in from the start, switched off until you decide you want it.
What about data privacy?
Orders are sent to the AI model through a business API rather than a consumer chat app. With OpenAI’s API, data isn’t used to train their models by default. The order data, the original emails and the attachments are stored on your own server, and the extraction step is the only point where order content leaves it.
If you’d like to see how your own orders would come through, send us a few real examples, the messier the better. Get in touch.