Guide

How do you process customer orders that arrive by email and PDF?

How to turn purchase orders that arrive as email attachments into orders in your ERP without re-keying, and what happens when the system isn't sure.

The short answer

An AI agent watches the orders inbox, reads each attachment into the fields your ERP expects, and checks the customer, products, quantities, prices and dates against your records. Orders that pass every check are created and acknowledged. Anything it can't read or match goes to a person with the original document beside the fields, so no order is created wrongly without someone looking.

Key takeaways

Most emailed orders come from a few customers in a few layouts. Start with those.
The agent reads every field with a confidence score and checks each one against your records before creating anything.
Anything it can't read or match goes to a person with the original document beside the fields.
Some orders always go to a person: new customers, unusual values and changes to orders in progress.
Measure cost per order, errors after creation and time to acknowledgement.

Written by: Clearmatic
Published: September 16, 2026
Share

Your customers send purchase orders however their own systems let them: a PDF attached to an email, a spreadsheet, an order typed into the body of a message, sometimes a photo of a printed form. Someone in your sales office or customer service team opens each one, finds the customer in the ERP, types in the lines, checks the codes against the product list and sends an acknowledgement. On a busy morning, orders queue behind everything else in the inbox, and the one typed in a hurry has a wrong quantity nobody spots until the delivery arrives.

The documents vary, but what you need from each one stays the same: who is ordering, what, how many, for when and to where. That fixed set of fields is what makes order intake a good job for an AI agent.

What the agent reads, and how

The agent watches the orders inbox. For each new message it saves the attachment, records the sender and the time, and reads the document into fields: the customer and their order reference, the delivery address, the requested date, and each line with its product code, description, quantity and any price the customer has stated.

Reading is a different job depending on the document. A PDF generated by the customer's own system has the same layout every time and reads reliably. A scan or photo is read as an image first, which works for printed text and is less certain with stamps, handwritten notes and a quantity someone corrected in pen. The agent gives every field a confidence score, because that score decides what happens next.

The fields it's sure of are checked and ticked. The one it can't read goes to a person with the original.

Check every field before creating the order

Fields read from a PDF still have to be checked before they become an order. Each one is compared with what your systems already hold.

The customer matches an account in your ERP or CRM, by name, account number or the email domain the order came from.
Each product code matches your list, or it's a customer code someone on your team has mapped to yours before.
The quantity makes sense: a pack size you sell, and a volume in line with what this customer usually orders.
Any stated price matches your price list or the customer's agreed terms.
The delivery date is possible, and the address is one you've delivered to or one the customer has given you before.

When every check passes, the order is created in your system with the original document attached, and the customer gets an acknowledgement generated from the order itself. When a check fails, or a field was read with low confidence, the agent doesn't create the order. It asks a person.

What the person sees

The person gets the original document on one side and the fields the agent read on the other, with the doubtful ones marked and a reason: date unreadable, product code not found, quantity unusually large for this customer. They correct what's wrong and confirm, and the order is created from there. Each one takes a minute or so, and they only see the orders that needed them.

Their corrections improve the process. When someone maps a customer's product code to yours, the next order with that code passes on its own. When they confirm a new delivery address, it's known from then on. The share of orders that need a person falls over the first months, and the ones left are the real exceptions.

The rule that keeps the process trustworthy is that the agent never creates an order it isn't sure of. A wrong order created with nobody looking does more damage than one a person mistyped, because nobody expects it to be wrong.

Orders that should always go to a person

Some orders should go to a person even when every field reads cleanly, because a wrong one costs far more than the minute saved. Write this list down before anything goes live.

The first order from a new customer, or from one who hasn't ordered in a long time.
An order above a value you set, or a quantity well beyond what that customer usually takes.
A price below your floor for that product, which usually means the customer is working from an old price list.
A change to an order that's already being picked or shipped.
Instructions in the email body that don't fit a field: a different delivery window, a request to hold, a note about packaging.

These orders still arrive with every field read and checked, so the person confirms instead of typing. Review the list after a few months. Some items can come off it once you've seen how the agent handles them.

What your customers notice

Acknowledgements arrive within minutes instead of hours, and they're accurate, because they come from the order that was created. When a customer emails to ask where their order is, the answer comes from the same record, which is why order intake and support triage often end up sharing a system.

Orders that arrive as spreadsheets or in the body of an email are handled the same way. Phoned-in orders are a separate process. Leave them until the written ones run well.

How to start

Collect a month of incoming orders and sort them by how they arrived and what they look like. Most companies find that a handful of customers and layouts make up most of the volume.
Take a baseline: orders received, hours spent entering them, and orders corrected after they were created.
Start with customers whose orders arrive as system-generated PDFs. They read most reliably and are usually the biggest senders.
Run for a few weeks with every order going to a person to confirm. This is where product code mappings get built and where you see how often the reads are right.
Switch on automatic creation for orders that pass every check, and keep the person step for the rest.
Add scanned and emailed orders once the first group is steady.

This is the kind of agent we design and set up in our build work, connected to the ERP and inbox you already use.

What to measure

Cost per order: hours spent on order entry each month, costed, divided by the number of orders.
Errors: orders corrected after creation, wrong quantities shipped, and credit notes raised because of an entry mistake.
Time from order received to acknowledged, which is what the customer feels.
Orders created without a person, as a share of the total, tracked month by month as the mappings build up.

What to do this week

Export last month's orders inbox and count the orders by customer and format.
Pull ten recent orders that had to be corrected and note what went wrong in each.
Draft the list of orders that should always go to a person.
Ask the team how long a typical order takes to enter, start to finish.

Questions

Does the agent need access to our ERP?

Yes, but only to what the job needs: read access to customers, products and prices, and permission to create orders. Every order it creates is logged with the original document, so you can see what it did and why.

What if one email holds several orders, or one order spans several attachments?

The agent reads the whole message, splits or combines the documents into orders, and links each one to the email it came from. If it can't tell how the pieces fit together, the message goes to a person.

Does this replace our order entry team?

It replaces the typing. The team's time goes to the orders that need judgment, to customers with questions, and to work the typing was crowding out. As order volume grows, the same team can handle more of it.

What happens if the agent stops working?

Orders stay in the inbox where they arrived, so nothing is lost, and your team can enter them by hand as they do today. Someone should be named to notice when the agent stops creating orders and to raise it.

Get the next article when it's published.

More on agents.

All guides