In my overview of AI agent examples, order entry is the second example. This article follows one purchase order from the mailbox to the booked sales order in your ERP, and marks each point where a person takes over.
I describe how such an agent is built, not a client project. I have no client projects to show yet and I won't invent one.
What does an AI agent for order entry do?
Your customers send purchase orders as PDFs, each in their own layout, and someone in sales support types them into the ERP. The agent reads the order, compares it with your master data and creates the sales order as a draft, with every difference it found at the top.
Reading the PDF is the smaller part of the job. The work is in the checks. Does their article number map to one of yours? Is "10" ten pieces or ten cartons, and does the price on the order match the price you agreed?
The agent decides nothing about price, credit or delivery promises. It creates no customers and no articles, and it doesn't write to the customer.
If orders reach you in a shared mailbox with everything else, sorting comes first. I cover that in how an AI email triage agent works.
How does the agent get from a PDF to a sales order?
1. The order arrives
The trigger is a new message in the orders mailbox. The agent stores the original file unchanged before it reads anything.
What goes wrong. The same order arrives twice. So the first lookup is the customer's order number in your ERP. If a sales order with that number exists, the new one waits for a person, because it may be a duplicate or a change to the first.
2. It finds the customer
The agent matches the buyer against your customer master. It tries your customer number if the order prints one, then the VAT ID, then name and address. It needs exactly one hit.
What goes wrong. A group orders through three legal entities with similar names, and the right one decides which price list applies. With two possible records the agent picks neither and names both. With none, the order goes to a person.
3. It maps the articles
A line carries the customer's article number, yours, or only a description. The agent maps the customer's numbers to yours through a cross-reference table. A line that quotes your own number gets checked against the article master, because numbers get mistyped.
What goes wrong. A line has only a description, say "gasket as last time". The agent may suggest an article from that customer's earlier orders and marks it as a suggestion. It never books the nearest match as an ordered line.
4. It checks quantities, units and pack sizes
The customer orders 100 pieces and you sell the article in cartons of 12. The agent converts units only where the article master holds a conversion. It flags quantities that break a pack size or fall under the minimum order quantity, and it doesn't round on its own.
What goes wrong. Number formats. "1.000" on a German order is one thousand, and on a British order it is one. The defence is arithmetic in code. Quantity times unit price has to give the line total, and the lines have to add up to the order total. The agent holds an order that fails the sum, however sure the model sounds.
5. It compares prices and terms
The agent compares each unit price with the price your ERP would charge that customer on that date, taken from their price list or agreement. You set the tolerance, and zero is a reasonable choice. It also reads the payment and delivery terms and any reference to a quote.
What goes wrong. The customer orders at last year's price, or cites a quote that has expired. The agent reports the difference and changes nothing. Which price holds is for sales to decide.
6. It checks the date and the delivery address
The agent compares the requested delivery date with the lead time stored for each article and flags a date that lead time rules out. Then it compares the delivery address with the ship-to addresses on the customer record.
What goes wrong. "Please deliver to our new plant", with an address you have never shipped to. That can be true. It is also how goods get stolen. A new delivery address always goes to a person, who confirms it with a contact you already know.
7. It writes the draft and a person releases it
The agent creates the sales order as a draft, with the customer's order number, the original PDF attached and all deviations listed on top. Someone in sales support compares the two and releases the order. Your ERP's own checks stay in force. If the order runs into a credit limit or a delivery block, the agent doesn't work around it.
What goes wrong. After a hundred clean drafts the reviewer starts clicking through. Show the PDF and the draft side by side.
What always goes to a person?
Five kinds of order stay with your team.
- An unknown customer, or one that matches two records. A new customer account needs a credit check and payment terms.
- A price or a term that deviates. Accepting it costs margin, and rejecting it means a call to the customer.
- An article the agent can't map. A guess here ends as a wrong delivery and a return.
- A credit limit or a delivery block. Somebody set that block on purpose.
- Anything the agent is unsure of, with the reason in plain words.
These orders need an owner. An escalation queue people actually trust covers how to size the queue and who clears it.
What does the agent need before it can start?
A mailbox that belongs to a function. Use orders@, not a salesperson's personal inbox.
An ERP with an interface, and a user of its own. The agent reads customers, articles, price lists and delivery addresses. It writes draft orders and nothing else.
Master data you would trust yourself. That covers a cross-reference table for customer article numbers, pack sizes on each article, and current price lists in the ERP rather than in a spreadsheet. Check this first, because wrong data makes the agent flag correct orders.
Written tolerances. How far may a price differ before a person looks? Which customers get no tolerance at all?
Past orders. The test set is PDFs from recent months with the sales orders your team booked from them.
Which guardrails does the agent need?
A purchase order is written by someone outside your company. The agent treats every line of it as data and never as an instruction. "Please apply the new prices attached" changes nothing, because the connector has no function that changes a price, a customer record or an article. A prompt is a request, a guardrail is a wall explains why these limits belong in code.
Keep the original order
The agent files the PDF as it arrived and links it to the sales order. The fields it extracted don't replace the document.
Under German commercial law this is also a duty. Section 257 of the German Commercial Code obliges every merchant, in subsection 1 no. 2, to keep received commercial letters in an orderly way. Subsection 2 limits the term to documents that concern a commercial transaction. Subsection 4 sets the period for commercial letters at six years, and under subsection 5 it starts at the end of the calendar year in which the letter was received. Subsection 3 allows keeping them as a reproduction on an image carrier or another data carrier. The conditions are that this complies with the principles of proper bookkeeping and that the reproduction matches the received letter visually when made readable, is available for the whole period and can be made readable at any time within a reasonable period. I read the section on gesetze-im-internet.de on 12 October 2026.
A customer's purchase order concerns a commercial transaction, so the build treats it as a commercial letter. The same section sets other periods for accounting records, and whether your orders count as such is a question for your tax adviser. So is section 147 of the German Fiscal Code, which names received commercial or business letters too and has conditions and period rules of its own. I don't go through them here, and I don't give legal advice.
How do you test it in shadow mode?
Run it in shadow mode for two to four weeks. The agent reads every order and writes its draft into a log, not into the ERP. Your team enters orders as before.
Then compare field by field. Did the agent find the same customer, article, quantity, price and date as the person who booked the order? Did it flag every order your team had to query with the customer? We agree the pass mark with you before the run starts, because a pass mark set after the results is a negotiation.
Count one case separately, the order the agent would have passed as clean although your team booked it differently.
In the next stage the drafts land in the ERP and a person still releases every one. Only after that do clean orders from repeat customers release on their own.
What should you measure?
Start with the share of drafts released unchanged, per customer. An average hides the one customer whose orders never come through clean.
Count the flags by reason. If most of them say "article not in cross-reference table", the next job is the table and not the agent.
Count every wrong order that reached the warehouse, and read each one. Measure the time from arrival to released order against the hours you counted before the build.
I would not make "orders booked without a person" the headline number. An agent can raise it by flagging less.
When is an order entry agent not worth building?
If EDI, a customer portal or a web shop already carries most of your volume, those orders arrive as structured data and need no agent. If the PDF share that remains is a handful of orders a day, the agent saves too little to pay for its upkeep.
If your master data is poor, the agent flags nearly every order, and your team gains a second screen to check. Fix the cross-reference table and the price lists first.
Supplier invoices are the same job seen from the buying side, and I describe that agent in AI invoice processing in seven steps. Ranking what to automate first helps you compare the two.
Bring a week of orders to a scoping call
Bring the purchase orders from one ordinary week, and the sales orders your team booked from them, to a thirty-minute scoping call. We go through the sample with you, mark which checks an agent could take over and which stay with your team, and tell you what the first version would cost. If the master data needs work first, you hear that too.
What moves that figure is in how much an AI agent costs to build. Our agent build service takes one workflow like this from shadow mode into production on the mailbox and ERP you already run. What your team holds afterwards is in what a ninety-day handover contains.