Automating order entry: PDF and email orders into the ERP without retyping them

What retyping costs: a worked example

A customer emails a purchase order as a PDF. Someone on the order desk opens it beside the ERP screen and keys in the header and every line. That takes a few minutes per order, so hardly anyone multiplies it out over a year.

Here is that multiplication as an example. I made up every figure so the arithmetic comes out even. Swap in your own.

The assumptions:

• 36 orders a day arrive as a PDF or in an email, on 250 working days a year.
• An order has 6 lines on average and takes 5 minutes to enter.
• An hour on the order desk costs the business €40 fully loaded.
• One entered line in 200 carries an error, mostly a wrong quantity or item number.
• A third of those errors only surface at the customer and cost €80 each for collection and reshipment. The business catches the rest and fixes each in 10 minutes.

That is 180 minutes a day, three hours of keying. The €38,400 is also the ceiling. Automation can't save more than that in this example, and some of it stays, because someone still checks the exceptions.

How time, errors and delay feed each other is the subject of Media breaks: what retyping that PDF really costs.

Three ways to get an order into the ERP without typing it

Software vendors call the result sales order automation. There are three routes to it. Two of them change how your customer orders. The third leaves the customer alone and starts at your inbox.

EDI. The customer's system and yours exchange structured messages. In the EDIFACT standard the purchase order message is called ORDERS. It is the cleanest route and the one with the most effort per customer, because message format, field mapping and testing start over for each connection. EDI pays for the customers who send the most documents. Nobody sets it up for a customer who orders three times a month.

Customer portal or web shop. The customer enters the order and it arrives in the ERP as structured data. That works for catalogue items and for customers without their own purchasing system. A buyer who raises the order in his own ERP won't happily type it a second time into your portal. You have moved the retyping to the customer, and he goes on sending his PDF.

Extraction from PDF and email. The customer orders as before. Software reads the document and proposes an order. There are two kinds.

The older kind works with templates. For each customer layout, someone defines where the order number sits and where the line table starts. For scans, optical character recognition, OCR for short, first turns the picture into characters. This is dependable while the layout holds. When the customer changes the form, the template reads the wrong spot until someone adjusts it.

The newer kind uses AI models that read a document without a template. They cope with unfamiliar layouts and with an order written as plain text in an email. You pay for that in certainty. A model can misread a number and the result still looks plausible. So every AI extraction needs a check against master data and an approval step for anything ambiguous.

The routes combine. EDI for the largest customers and extraction for everyone else is a sensible split.

Order entry from PDF and email in six steps

1. Capture. All orders go to one dedicated mailbox. The software collects email body and attachments and opens a case per order. Anything that isn't an order goes to a person.
2. Extract header and lines. The header gives the customer, their order number, the delivery address and the requested date. Each line gives item number, description, quantity, unit and price. A PDF generated by the customer's ERP already contains its text. A scan needs OCR first.
3. Match customer and items against master data. The software finds the customer by customer number, sender address or VAT number. The item number on the order is usually the customer's own. A cross-reference table translates it into yours. A line without a match becomes an exception.
4. Check price, quantity and delivery date. The software compares the ordered price with the agreed one. The quantity has to fit the pack size and the range this customer normally orders. It checks the requested date against your lead time.
5. A clerk approves the exceptions. The clerk sees the original next to the proposal, with the doubtful fields marked. The clerk corrects the field, asks the customer, or approves. The system stores every correction so you can work out the error rate later.
6. Write to the ERP. The checked order goes into the ERP through an interface and becomes a normal sales order with the original attached. First the software checks whether this customer order number already exists. Otherwise the customer's reminder email creates a second order.

The clerk's work moves from typing to checking exceptions. Steps 3 and 4 decide how many exceptions land on that desk, and both depend on your master data.

Why order confirmation in wholesale takes four days shows where the days go after entry.

What has to be true first

A clean item master. Duplicates, discontinued items nobody blocked, and descriptions only the warehouse understands turn one clear match into several candidates. All the software can do then is ask. Master data: the quiet error source shows how to recognise master data in that state.

Customer item numbers mapped. The customer orders with his number. Today the translation lives in the clerk's head or in a private spreadsheet. For automatic matching it has to be in the system, per customer and item. Dull work, and it pays twice, because the same table speeds up manual entry too.

Units of measure settled. The customer orders 10 cartons and your ERP holds the item in pieces. Without a stored conversion factor, that becomes a delivery of 10 pieces or a phone call.

Where it fails

Handwriting and scanned faxes. No software reliably reads a skewed fax with a quantity changed by hand. Send those straight to a person and count which customers they come from. With a handful of senders, ask them for a PDF from their system.

Free-text lines. "Same as last week, but 20 more" relies on knowledge that isn't in any document. The same goes for specials without an item number. These lines stay manual.

Call-offs against framework contracts. A call-off often states only the contract number, a quantity and a date. Price and item are in the contract, and the quantity counts against what is left on it. The flow has to find the contract in the ERP and book against it. That can be solved, but it doesn't belong in the first attempt.

None of these is a reason to drop the idea. Decide before you start which orders stay with a person.

Start small: one customer, one order type

Begin with one customer or one order type. A good candidate orders often, always sends the same PDF and rarely orders anything without an item number.

First measure today's state for two weeks, in minutes per order and errors per line. Without that baseline you can't tell later whether anything improved.

In the first phase the clerk approves every order, including the ones that look fine. That costs time on purpose. It shows you which errors your checks miss. Back to the example, with one more assumption: checking a proposal takes 2 minutes. For 9,000 orders that is 18,000 minutes, or 300 hours instead of 750.

Two measures are enough at the start:

• The touchless rate is the share of orders that go through without any correction. If the clerk in the example approves 27 of a day's 36 orders unchanged, it is 75%.
• The error rate is the share of lines that were still wrong after posting. You find those lines through complaints, queries from the warehouse and credit notes.

Before you start, set the values at which this customer's orders may skip approval. The next customer comes on when this one reaches them.

The next step

Keep a tally for one week. How many orders arrive as a PDF or email, from which customers, and how long does entry take? That gives you your own numbers for the example above.

If you would rather have someone from outside map the path from inbox to posted order, that is the scope of our process analysis. We map one of your core processes end to end, show where time and money are lost, and hand over a prioritised list of actions. Fixed scope, fixed duration, fixed price.