An editorial guide from the Akaen team. The project cited was led by Víctor Muñoz, now an Akaen partner.
A customer emails a PDF order. Someone opens it, finds the references in the ERP, checks prices, types the line items and confirms it. Multiply that by several hundred orders a month and you have one of the most commonly automated processes in manufacturing and distribution. The question is how.
There are three approaches. All three work in a demo. What sets them apart is what happens when a customer changes their order format, and who maintains the system as the customer base grows.
The problem is not reading the PDF, it's validating it.
Reading PDF text is easy. What takes the team’s time comes afterwards: recognising that “REF 42” means REF-042, that quantities are in cases rather than units, that the order price differs from the current price list, and that the delivery address is the Girona branch rather than headquarters. Any solution that does not validate against your master data merely shifts the work: someone corrects data instead of typing it.
Compare the three approaches on what happens with a new format, who maintains the system when twenty more customers join, and where exceptions go. Extraction alone tells you little, because the approaches end up looking similar there.
Option 1: OCR with templates
A template is defined for each order format: where the order number is, where the line items begin and which column contains the quantity. OCR extracts the text, and a rules engine maps it to ERP fields.
When does it fit?
- A few customers with stable formats, such as five large accounts always sending the same document generated by their systems.
- When the starting budget is minimal and someone is available to maintain the templates.
Where it breaks
- Whenever a customer changes their template, adds a column or sends a skewed scanned order. Maintenance grows with the number of customers rather than the number of orders.
- Validation usually relies on fixed rules. These handle predictable cases, but not similar-looking product references or prices that differ from the price list because of an agreed discount.
Option 2: customer portal or EDI
Customers are asked to change how they place orders: by using a portal or connecting their system through EDI. Orders arrive structured and require no interpretation.
When does it fit?
- Large accounts that already work this way with other suppliers often expect and request EDI.
- When one customer’s volume justifies an integration project with their system.
Where it falls short
- It rarely covers the whole customer base: medium-sized customers keep emailing PDFs, while small ones use WhatsApp. It captures the part of the volume that was already best organised.
- It depends on customers’ willingness to use it. A portal nobody uses is a completed project with the process still unresolved.
Option 3: AI interpreting the document
A language model reads the order as a person would: it understands the header and line items even in a new format and returns structured data. Every data point is then checked against ERP master data, and mismatches go to a review queue.
How the workflow works
Four phases. Sort: identify what arrived and who sent it, whether a PDF, Excel file, photo or text in an email body. Understand: extract the header and line items with a confidence score for each data point. Validate: reference against item master data, price against the current price list, quantity against the sales multiple, and address against the customer’s addresses. Integrate: record the order in the ERP and send confirmation to the customer. Only failed validations reach a person, with the document and the point requiring review clearly marked.
What it demands
- Designing exception handling as part of the system: who resolves exceptions, with what information and within what time frame.
- A way into the ERP: an API, a file import or, if neither is available, a robot that enters the validated order.
- Reasonably up-to-date master data, because validation is where the value lies and needs a reliable reference to check against.
Comparison of the three approaches
| OCR with templates | Portal or EDI | AI with validation | |
|---|---|---|---|
| Start | Quick and cheap | One project per client | Weeks, with a clearly scoped pilot |
| New client format | New template | Not applicable: customer adapts | Read without additional configuration |
| Maintenance as the customer base grows | Grows with every customer | Grows with each integration | Stable |
| Validation against master data | Fixed rules | Handled by the customer when selecting items | Mappings, price lists, multiples and addresses |
| Customer base coverage | Customers with a template | Customers who accept | Everything received by email |
| Exceptions | Template failure | Avoids them at the customer's expense | A purpose-built review queue |
What to look at before deciding
- Volume: below a few dozen orders per month, a well-configured import is enough.
- Heterogeneity: the more varied the formats, the less sense templates make.
- Status of master data: if it is very outdated, validation has no reliable reference; cleaning it must be part of the pilot.
- The ERP: SAP, Business Central, Business One, Odoo, Sage or A3 have different entry routes; they should be checked in the first week before building.
The three options can be combined. A medium-sized company will often use EDI with two or three large accounts, AI for the remaining emails and PDFs, and a file import for residual cases. Expecting every customer to change how they order does not work.
A real case: 15 minutes to 30 seconds per order
At a leading food and beverage corporation, B2B orders arrived in PDFs and emails with varying formats and were manually validated before entering SAP. Using an event-driven architecture on Azure, generative AI extraction and validation against SAP master data, time per order fell from 15 minutes to 30 seconds. The full case study is available.
Frequently Asked Questions
Does it work with scanned or photographed orders?
Yes. Current models read images directly. Scan quality affects confidence in each data point, and validation reflects this: uncertain data goes for review rather than being entered incorrectly in the ERP.
What about orders in an email body or sent through WhatsApp?
They are treated like PDFs: unstructured text to be structured and validated. The difference is how messages enter the workflow, which must be resolved first for messaging channels.
Do I need to train the model on my orders?
Not in the traditional sense. It is configured with examples and business rules. Confirmed mappings accumulate with use: a customer’s reference and yours, or their unit and your ERP’s sales unit. Once resolved, an exception no longer needs resolving next time.
How long before the first order is entered automatically?
A pilot focused on the highest-volume customers takes weeks. The first week checks ERP access and the state of master data, which determine the rest of the timeline.
How the complete workflow operates, what your company needs and when it pays off, in order entry automation. To see how it applies to your sector before speaking to anyone, request the free first look indicating “order entry”.