iosys - AI Agents in Order Intake: What Works Today

Purchase orders arrive as PDFs in an inbox, and somebody types them into the ERP. This is the process AI agents in manufacturing handle most reliably today. This article walks through the sequence in detail and through the point where a person decides.

Key points

A language model reads, fixed tools do the routing.
Six deterministic checks decide on automatic approval.
The model is never asked how sure it is.
Passed means nothing contradicted the extraction.
Five checks look at the document, one at the customer.
The system "learns" per sender from approved examples.
Every extraction is versioned and traceable.
Purchase orders are shipped, other document types are not.

What an agent in order intake does

A Swiss CNC contract manufacturer receives more than 50 orders a week, all as PDFs by email. The managing director entered them into the ERP himself, 20 hours a week. After automation it is 2 hours, at a 90 percent automation rate (case study). The analysis that led to the project is described in How to Get AI Going in Manufacturing.

The sequence behind it has four stages. A service watches the inbox. A language model classifies which of the incoming emails are purchase orders. From the attachment it reads the structured details: buyer and vendor, the addresses with their respective roles, and each line item with article, quantity, price and delivery date. The checked result is then handed to the ERP system.

The AI agent is this sequence as a whole. Extraction is one component inside it, and it makes no decisions.

The split that makes the sequence checkable

A language model is strong at interpreting and unreliable at calculating. It copes with an unfamiliar form variant, and it does not necessarily return the same result on a second run (a lack of determinism). So it takes on only the unclear part: classifying and reading.

Everything that can be described precisely goes to deterministic tools. The routing, the comparison against your master data, the call to your interface. It is exactly this split that makes the sequence verifiable, and it is the part that articles about AI agents usually skip.

Why the reading is the hard step rather than the character recognition is set out in Which AI Tools Pay Off for Manufacturing SMEs?. Where the same split sits within a whole architecture is shown in The Model Comes Last.

Where the person decides

A language model error looks different from a text recognition error. OCR produces garbled characters that anyone spots immediately. A language model produces a plausible number in the wrong place.

The research here is clear. A paper in ACL Findings 2026 examines hallucination in vision-language models and finds higher rates on numerical content than on textual content. Quantity, price, date and article number are exactly the fields that matter on a purchase order.

The obvious answer would be to ask the model how "sure" it is about an extracted value. The same line of research shows that self-reported confidence is not a reliable criterion for this. From our own product development: we never ask the model that question, because a language model cannot and should not judge this. It is like asking someone who misheard a phone number how confident they are. The answer comes out of the same misunderstanding as the number.

Instead every extraction runs through six fixed checks that are plain code rather than model judgement. They check the reading, not the order itself: commercial rules such as price, credit limit or availability are evaluated later, against your ERP data. Five of them apply to the document:

Schema: are all required fields present and correctly typed?
Critical fields: does the order number appear in the document?
Totals: does the extracted total match the printed one?
Line items: does quantity times unit price give the line total?
Dates: do the delivery dates appear in the document?

The sixth applies to the sender: are there enough approved learning examples for this customer? For an established customer that condition holds permanently, for a new one it does not hold at first.

If all six pass, the order moves on automatically. If one fails, it goes to a person for review and approval.

The character of these checks matters. They look for contradictions. If the totals check finds no printed total in the document text to compare against, it counts as passed, because nothing contradicts it. Passed therefore means that nothing contradicted the extraction. For the sample checks you plan yourself, that is the decisive difference.

What the system "learns" over time

Every order a person approves becomes a learning example for that customer. The system "picks up" a sender's particularities that way: where the delivery date sits on the form, which column carries the article number.

That also explains the sixth check. A new sender has no approved examples yet. Their first documents therefore go to a person in every case.

Every extraction is versioned and stays traceable. Who approved which order and when can be answered later. For an audited company that is a requirement rather than a detail.

What does not work today

For extraction from purchase orders there is no independent benchmark measuring German-language documents at the layout diversity of an SME. Public benchmarks measure the parsing of documents, not your suppliers' order confirmations. Any accuracy figure quoted holds first of all for the documents it was measured on.

Extraction does not work on its own. It reads, checks and submits. Where the boundary to automatic approval sits is set in advance and does not grow with use.

Other document types are a separate project. For purchase orders the sequence is shipped, for invoices and delivery notes it is not.

Order intake in four stages, with human approvalWatch the inboxA service checks incoming email.Recognise the orderThe language model classifies the email.Read the detailsArticle, quantity, price and delivery date, out of the PDF.Between reading and handoverSix deterministic checksSchema: required fields present and typedCritical fields: order number in the documentTotals: extracted total matches the printed oneLine items: quantity times unit price adds upDates: delivery dates appear in the documentCustomer: enough approved learning examplesPlain code, not model judgement. A pass means nothing contradicted the extraction.All six passThe order moves on automatically.One failsA person reviews and approves.Handover to the ERPThe structured result lands in the system of record.

Building it yourself: what gets underestimated

The parts are lying around in the open. Open models, text recognition libraries, a workflow engine such as n8n. A capable person has a prototype within days that reads the first purchase order correctly.

The prototype is rarely the problem. From the project above: connecting to the ERP interface was more complex than expected. Special formats from individual suppliers needed rework, and migrating the ERP to the cloud became a project of its own. A few days turned into three months to the result, plus two more for the ERP migration.

The real question arrives afterwards. A supplier changes their form, extraction breaks, and order intake stalls on a Tuesday morning. Who looks at it? In a company whose core business is not IT, that person also has a day job.

The stakes are higher than for most internal tools. A quantity read wrongly goes into production and turns into material, machine time and a complaint.

Conclusion

Of the AI categories, automating order intake pays off fastest for a manufacturing SME. The process is clearly bounded, it repeats, and its result can be checked against the document. Straight-through processing is the more useful measure here, because it counts how much work is actually left over.

We build this sequence with factorIQ and connect it to your existing ERP, without a system change. On request we run it on-premises, in Switzerland or in the EU. Arrange a conversation if you would like to work through your own order intake.

More on this: AI agents for manufacturing and automated order processing.

Sources

ACL Findings 2026, Perceptual Hallucination in Vision-Language Models: Definition, Analysis and Verification, 2026 - aclanthology.org
Ouyang et al., OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations, CVPR 2025 - arxiv.org/abs/2412.07626
Brown et al., Language Models are Few-Shot Learners, NeurIPS 2020, examples in the prompt rather than changes to model weights - arxiv.org/abs/2005.14165
Dong et al., A Survey on In-context Learning, EMNLP 2024 - aclanthology.org
iosys case study, From 20 to 2 Hours: AI-Powered Order Processing - Read case study
iosys blog, Which AI Tools Pay Off for Manufacturing SMEs? - Read article
iosys blog, Engineered AI: How Process Automation Redefines Manufacturing in 2026 - Read article