In the morning there are 40 emails waiting in the orders@ inbox. Some are PDFs generated by customers' systems, some are scans, some are plain email text along the lines of "same as last week, plus 2 pallets of adhesive". Two people in customer service retype it all into the ERP until noon, and a wrong item code only surfaces when the complaint comes in.
AI vendors promise that a model will read these orders on its own. That is partly true. This post lets you decide whether your order stream is a fit for AI automation, what it actually costs, and when the cheaper answer is a plain CSV file from the customer.
Count before you buy
Reading a sales order is the same mechanism we described for AI invoice processing: the model reads the document, extracts fields, a person approves. There is one difference. An invoice has a legally defined set of fields; a customer's order has their item codes, their product names and their units of measure.
Before you talk to any vendor, collect three numbers from the last 4 weeks:
- Volume. How many orders per day arrive by email or as PDFs. Below 15–20 a day, automation rarely pays back in under 2 years.
- Spread. From how many different customers. If 3 customers send 80% of orders, the problem is solved by talking to them, not by a model.
- Time per order. Time 20 consecutive orders with a stopwatch. We typically see 4–10 minutes for an order with 10–30 lines.
If you get more than 30 orders a day from more than 50 customers at 5+ minutes each, you have a candidate. If not, read the section on when this makes no sense before you spend anything.
Where the work really is: code mapping
The mistake we see most often: a company judges the project by how well the model reads the PDF. The model reads well. The problem starts a moment later, when the order says "RUR-PP-20x2,8 / 4m" and in your ERP the same product has item code 100245 and the name "PP20 PN20 pipe 4 m".
Without a mapping table "customer code → your item code", every line needs a manual lookup. AI then saves you retyping the header, not the work. In the projects we have run, building and cleaning this table was 50–60% of the total effort.
What it looks like in practice:
- You pull 12 months of order history from the ERP and match customer codes to your item codes automatically wherever possible.
- The rest is filled in by someone in customer service who knows the range. Usually 1–3 weeks at 2 hours a day.
- Every manual correction after go-live is added to the table. After 2–3 months, the share of lines needing manual matching usually drops below 5%.
The second issue is units of measure. The customer orders "10 packs", you sell individual pieces at 25 per pack. Conversion factors must live in the item master, not in one employee's head. If the item master is a mess, start by cleaning it: one product, one item code, correct conversion factors.
Example: distributor, 24 people, Comarch Optima
At one of our clients, a 24-person distributor of plumbing and installation supplies, around 60 orders a day came in from roughly 140 active customers. 70% arrived as PDFs or email text. Two customer service staff spent about 7 hours a day in total retyping them, 7 minutes per order on average. Their ERP is Comarch Optima, one of the most common ERP systems among Polish small businesses.
What we did:
- the orders@ mailbox in Microsoft 365 forwards attachments to a service that extracts header and lines using a language model,
- lines go through the mapping table (about 3,200 "customer code → item code" pairs),
- a draft order lands in Comarch Optima as a document awaiting approval, with unmatched lines highlighted,
- nothing enters the system without a person clicking approve.
The project took 6 weeks and cost about PLN 38k (approx. EUR 9k), of which 2 weeks went into the mapping table alone. Model and hosting cost them PLN 150–300 (approx. EUR 35–70) a month. After three months, average handling time per order fell from 7 to about 1.5 minutes — from 7 to about 1.5 hours a day. Item code errors dropped from about 3 a week to fewer than 1.
What we would do differently: start building the mapping table before choosing the tool. It is the only piece that is useful regardless of whether you end up with AI, a CSV import, or nothing.
When it makes no sense
The second example went worse. A packaging manufacturer, 35 people, running enova365 (another widely used Polish ERP). Around 15 orders a day, but 80% from 8 large customers. Some orders referred to technical drawings and carried notes like "same as last time, only with the new print version".
After 10 weeks and about PLN 22k (approx. EUR 5k), the model read about 70% of lines correctly. Customer service still checked every order line by line, so the saving came to about 30 minutes a day. It turned out that 5 of the 8 large customers had an order export to CSV or XML in their own systems. Someone only had to ask. A simple file import cost PLN 6k (approx. EUR 1.4k) and covered more than half of the volume.
AI makes no sense when:
- a few customers send most of the orders. Ask them for a CSV, XML or EDI export. Retail chains will demand EDI anyway, as we cover in the post on EDI for small suppliers.
- the order needs interpretation, not transcription. Drawings, technical variants, "same as last time". That needs a person, or a configurator on the customer's side.
- your item master is in poor shape. The model will read the customer's code correctly but miss your item code, because you have three codes for one product.
- you have fewer than 15–20 orders a day. At 5 minutes per order that is under 2 hours a day. A PLN 20–40k (approx. EUR 5–9k) project then pays back in 2–3 years, if everything goes well.
Data is a separate issue. Orders contain names, delivery addresses and phone numbers, so you are sending personal data to the model provider. Use a business tier with a data processing agreement, not an employee's private account. For example, Microsoft states that in Azure OpenAI prompts and outputs are not used to train models, but with a "Global" deployment they may be processed outside the EU (source: Microsoft Learn — Data, privacy, and security for Azure OpenAI). Check this in your own provider's contract.
Realistic ranges for a 10–50 person company: PLN 15–40k (approx. EUR 3.5–9k) and 4–10 weeks for an AI-based setup, PLN 4–10k (approx. EUR 1–2.3k) and 1–3 weeks for a file import from a few customers. On top of that, 1–3 weeks of a customer service person's time on the mapping table, whichever option you choose.
What to do this week
None of these steps requires buying anything or hiring a vendor:
- Count orders from the last 4 weeks: how many by email or PDF, from how many customers, what the top 10 customers look like.
- Time 20 consecutive orders with a stopwatch and note how many lines needed an item code lookup.
- Email your 3 largest customers and ask whether their system can send orders as CSV, XML or EDI.
- Export 12 months of order history from the ERP and check how many customers use their own product codes.
- Set aside 30 sample orders from different customers, worst scans included. That is your test set for any vendor.
If after these five steps most of the volume can be handled by a file from the customer, do that first. Add AI for the long tail of small customers later, if it still pays.
AI will read a customer's order. But the return on the project depends on the table that maps customer codes to your item codes, not on the model.