}

Case study: 50 PDF orders a day, no retyping into the warehouse system

By
Bodo Buschick
14/9/26
•
5 min
Case study: 50 PDF orders a day, no retyping into the warehouse system

A wholesaler, 50 orders a day, each one a PDF by mail. Before: three and a half hours of retyping, five to eight percent errors. After three months: under an hour, errors below one percent, 80 percent of orders booked before the clerk switches on her computer. He did not come to us to try something with AI. His clerk had threatened to quit.

That sounds exaggerated. It is close to the truth. Three to four hours a day typing article numbers, quantities and addresses. Nobody lasts more than a few months at that.

The starting point: 50 PDFs, eight formats, zero joy

The first thing we noticed is something we have since seen at almost every customer: nobody knew what the process really cost. The managing director guessed an hour and a half. The clerk said three. Measured: three and a half, four on days with many special orders.

We timed it for a week. Without numbers you automate by gut feeling, and gut feeling is almost always wrong about time.

The manual routine, step by step. Check the inbox and save the PDF. Open it, read the article number, search the WMS, type the quantity. Match the delivery address. Create and release the order. Call the customer if anything is unclear.

The minefield was in the PDFs. Eight customers sent eight formats. Article numbers sat top left, in a table, or in running text. One customer sent scanned, handwritten order slips.

The error rate was five to eight percent. At 50 orders that is two to four wrong orders a day. Each cost about twenty minutes of rework: cancellation, callback, new order. Plus the customer's irritation, which nobody could put a number on.

The pattern is common. Strategy& and BVL surveyed 115 logistics providers in November 2025. 96 percent have started digital transformation, 76 percent automate processes. Only 10 percent scale new technology successfully, and a quarter do not measure results at all. Order capture from mail and PDF rarely appears on the automation list. Too small for a project, too annoying to leave alone.

The decision: no new system

The managing director had checked two options. An extra person just for orders, about 45,000 euros a year. Or an ERP upgrade with an EDI module: six figures, six to twelve months, and his customers would have had to change their systems. None of them planned to.

We proposed a third way. The PDFs stay as they are. The customers change nothing. Between inbox and WMS we place a service that takes over the retyping.

We said it exactly like that, no robot arm on the slide. We build a service that reads PDFs and books the data into the WMS. Not rocket science. But it has to run every day, even when nobody is watching.

How it is built

Intake. The service reads the order mailbox every five minutes. Every mail with a PDF gets a case number. No PDF gets lost, not even in a crash mid-run.

Recognition per format. Each of the eight formats has its own reading rule: where the header data sits, how the line table looks. The service recognizes a format by sender and by the layout of the first page. If no pattern fits, the case goes to review instead of guessing.

Scans. Handwritten slips go through text recognition. The hit rate was about 80 percent. The rest lands with the clerk, scan and recognized text side by side. That is more honest than an automation that books wrong quantities.

Check against the master. Every line is checked against the article master. Does the number exist? Does the unit match? Is the quantity plausible for this customer? Every address is checked against the master addresses. Only then is the order booked.

Booking in the WMS. The warehouse system had an import interface. The service creates the order through it and reads back the order number. Without an interface we would have operated the screen. Slower, but it works.

Review cases. Anything unclear goes into a list: unknown article number, missing quantity, new address. The clerk sees PDF and proposal side by side and decides with one click.

Protocol and alarm. Every run writes three numbers: mails read, orders booked, open review cases. If a morning passes with mails in and no bookings out, an alarm reaches us. "Running" is not proof. "Booked" is.

Results after three months

  • Processing time from three and a half hours to under one hour a day. That hour is almost all review cases.
  • Error rate below one percent. The remaining errors come from the orders themselves, not from capture.
  • About 80 percent of orders are booked before the clerk starts her computer.
  • The clerk is still there. She now does purchasing and complaints.

A caveat: these are numbers from one operation with eight regular customers. If new senders with new formats arrive every week, it changes. Then the review list grows faster than the reading rules, and someone has to maintain formats.

What we would do differently

Measure format frequency earlier. Two of the eight formats made up 70 percent of volume. We could have gone live a week earlier with those two.

Plan review cases from day one. We built the review list in week two. It is the reason the clerk trusts the service.

Put the alarm on the result, not the run. A service can run and deliver nothing for days if a step before it fails silently. We have seen that elsewhere. Since then only the number of bookings counts.

Do orders, transport orders or advice notes arrive at your company as PDF or mail, and does someone retype them? Send me one anonymized example file. I will show you the protocol of the service reading it, line by line. Ask for a process check: 30 minutes, no sales pitch.