Your ERP cannot read a customer order because it only accepts structured fields, while customers write orders as prose: an email, a PDF, a spreadsheet in their own layout. Someone has to translate one into the other. You can automate order processing without replacing your ERP by putting an AI agent in front of it to do that reading.
At Lleverage we think the ERP is rarely the problem. It does the job it was built for: holding the record, checking it and running the business on it. The gap sits one step earlier, between the words a customer writes and the fields the system expects. A new ERP closes none of that gap, because the new one wants structured fields too.
That is the work our AI order processing agents take off the order desk. They read the order, check it against your customers, items and prices, and create the sales order in the system you already run, through integrations built onto your existing systems. If you want to see it on your own inbox, book a demo.
What does an ERP actually need to create a sales order?
An ERP needs a known customer number, valid item codes, quantities in the right unit, a price it can check and a delivery date in its own format. Every field must match a record that already exists. The system is strict on purpose: that strictness is what keeps stock, invoices and margins correct.
A typical sales order screen asks for a handful of things:
- A customer account that exists, with a delivery address on file.
- An item code for every line, from your own catalogue.
- A quantity in a unit the item is sold in.
- A price, or a price list the system can apply.
- A requested delivery date, plus references such as the customer's purchase order number.
None of these fields can be vague. "The usual", "same as last time" and "100 metres of the white one" mean nothing to a database. They mean a great deal to the person at the order desk who knows the customer.
Why can't an ERP read an email or PDF order?
An ERP reads data that arrives in a fixed structure: a screen, an import file, an EDI message or an API call. An email is free text written for a human. A PDF is a picture of a page. Neither tells the system which words are the customer, which are item codes and which are quantities.
This is the core of the problem. The ERP was designed to receive fields, and customers send sentences. A customer writes "please send 40 boxes of the 12mm, same address as March, need them before the 24th". A person reads that in seconds. The system sees one block of text with no fields in it.
Most ERPs offer an import route, but every import expects a fixed layout. A customer who changes their spreadsheet, adds a column or pastes the order into the email body breaks it. With hundreds of customers, each sending in their own way, nobody keeps those mappings current. So the order desk retypes.
ERP is already common. According to Eurostat's 2025 figures on e-business integration, 46.45% of EU enterprises used ERP software applications. Having the system is not the same as feeding it. The orders still arrive in the inbox.
What does a customer order look like in practice?
A customer order is usually a short email, a PDF exported from the customer's own system or a spreadsheet in their own layout. It often carries the customer's article names instead of yours, missing references, and context that only makes sense if you know the account.
SIG Benelux, a building materials distributor, measured it. Around 3% of its orders carried an article number. Roughly 47% had only a description. The rest arrived as a WhatsApp message, a photo pasted into an email or a sentence that only makes sense if you know the customer. Every one of them was retyped into Dynamics 365.
Microtechniek, a mechanical engineering firm, saw the same thing from another angle. Its shared inbox received 20 to 30 emails a day, and not all of them were orders: timesheets, quote requests and service notifications arrived in the same place. Each purchase order needed more than 20 fields extracted and resolved by hand.
| What the customer writes | What the ERP needs |
|---|---|
| "Same delivery address as last time" | A delivery address code on the customer account |
| "The white panels, 12mm" | An item code from your catalogue |
| "40 boxes" | A quantity in the unit the item is sold in |
| "Before the 24th" | A requested delivery date in the system's format |
| A buyer's name in the signature | A contact linked to the right customer account |
| "Our usual price" | A price checked against the contract or price list |
Every row in that table is a judgement call. That is why order entry has resisted automation for so long.
Can you automate order processing without replacing your ERP?
Yes. You can automate order processing without replacing your ERP by adding an AI agent that reads each incoming order, turns it into the fields your ERP expects, checks them against your data and creates the sales order there. The ERP stays the system of record and checks the order as it would a typed one.
Buyers ask this in different words: how to automate back-office work without a migration, or how to stop moving information between email, Excel and the ERP by hand. The answer is to automate the reading. The ERP keeps doing the work it already does well.
Our integrations page states the principle plainly: nothing is migrated and nothing is copied into a second database. The agent fills the same fields your team fills, and the system checks them the same way. Turn it off and your systems are as they were the day before.
Older systems are part of the job too. At Microtechniek, the on-premise ERP had no route in for outside systems, and other automation projects at similar companies had stopped at that point. A specialist installed the API module on site, and the Lleverage team made it work with the on-premise environment. Around 60 orders a week now land in Ridder IQ without anyone typing them. Where there is nothing to call at all, the agent can work the screen, with the access a person has and nothing beyond it.
How does an AI agent turn an order into structured data?
An AI agent reads the order the way an experienced colleague does. It classifies what arrived, picks out the customer, lines, quantities and dates, and matches each one to your own records. Lines it cannot place with confidence go to a person, with the reason attached.
The steps follow the shape of a good order desk:
- Classify. Decide whether the email is an order, a quote request, a change or something else, and route it.
- Read. Pull the customer, lines, quantities, dates and references from the email body, PDF or spreadsheet.
- Match. Find the customer account, the delivery address and the item code for every line in your own data.
- Check. Compare price, stock, delivery date and credit status against your rules.
- Create. Write the sales order into the ERP and send the confirmation once the ERP accepts it.
The matching step is where the knowledge lives. At SIG Benelux, the order history did the translation: this description, from this customer, means that article. Order lines now match the correct article on the first try for 88% of lines, and 73% of order emails reach Dynamics 365 on their own as a draft order, ready to review. The desk approves instead of types.
That knowledge has to sit somewhere your team can see and correct it. In Lleverage it sits in a company brain: which customer calls which product by which name, which address "the usual" means. Every correction your desk makes is kept.
"I knew the technology made this possible. My biggest question was the quality of our data. It was a positive surprise to see the order history was enough of a base to get results this fast." Ditte Smit, Marketing Director, SIG Benelux
Which orders should still go to a person?
Orders outside your rules should go to a person: a price off contract, an unknown item code, a credit hold, a delivery date you cannot meet or a line the agent is unsure about. You set the line. Everything inside it is created on its own, and everything outside it waits with the reason attached.
Each check gets its own setting. A price mismatch might go to sales, a credit hold to credit control and an unclear line to the order desk. Every action is logged with what the agent read and why it acted, which is what our control and audit trail is for.
Topa Bathroom Products, a wholesaler with around 700 customers, runs this way in Business Central. More than 90% of incoming orders are processed without manual input. When an article code is unrecognised, the agent flags it for review. When a commission number is missing, it drafts the reply email. Customers receive their order confirmation within 30 seconds.
How does this compare with EDI, templates or a new ERP?
EDI, import templates and a new ERP all depend on the order arriving in a fixed structure. They work well for the customers who can send one. An AI agent handles the rest: the orders written as prose, in each customer's own way.
| Approach | What it needs from the customer | What happens to a free-text order | Changes to the ERP |
|---|---|---|---|
| EDI | A fixed message standard, set up per trading partner | Not covered, retyped by hand | A connection per partner |
| Import templates or OCR rules | The same layout every time | Fails when the layout changes | An import route |
| A new ERP | Structured data, like the old one | Still retyped by hand | A full migration |
| AI agent in front of the ERP | Nothing new, customers keep their habits | Read, matched and checked | None, the ERP stays the system of record |
EDI stays the right answer for large trading partners who already send it. Our post on the orders EDI cannot handle covers where it stops. For the mechanics of the full flow from inbox to sales order, see sales order automation from email to ERP.
Frequently asked questions
Why can't my ERP import customer orders from email?
An ERP only imports data in a fixed structure, such as an import file, an EDI message or an API call. A customer email is free text written for a person. Without something that reads the text and turns it into fields, the ERP has nothing it can process, so someone retypes the order.
Do I need a new ERP to automate order entry?
No. A new ERP expects structured data just like the old one, so free-text orders would still be retyped. An AI agent in front of your current ERP reads each order and creates the sales order in the fields the ERP already uses. Your ERP stays the system of record throughout.
What if my ERP has no API?
Many older or on-premise ERPs have no open route in. Sometimes a module can be installed, as Microtechniek did for its on-premise ERP. Where there is nothing to call, an agent can work the screen with the same access a person has, keying the fields a person would key.
Will customers have to change how they send orders?
No. Customers keep sending orders as they do today: in the email body, as a PDF, as a spreadsheet or as a portal export. The agent reads each format and learns each customer's way of writing over time, so the change happens on your side. It reads them the way your order desk does.
How accurate is AI at reading customer orders?
It depends on your data and your rules, which is why every extraction carries a confidence score. Orders above your line are created on their own and the rest go to a person. At SIG Benelux, 88% of order lines match the correct article on the first try.
Start with one inbox and a week of real orders
The quickest test is your own order mailbox. Pick one inbox and one ERP, and bring a week of real orders, including the awkward ones. We read them with you, show which would be created on their own and which would wait for a person, and why. Our engineers build the first flow with your order desk, so orders come off the desk in the first weeks. Book a demo and bring the orders your team dreads.