Here is the build order for order capture from email and PDF. This is how we build it. No model comparison. No product pitch. A reading agent, a review queue, one column with the reason. That column decides whether the system is still trusted after three months.
Forwarders receive orders as mail text. Or as a PDF attachment. Or an Excel sheet. Or a portal export. One customer sends a fixed template. The next sends a photo of a delivery note. A third types the order into the mail body, no attachment at all. Every variant is solvable on its own. The problem is variant number 37. Nobody has seen that one yet.
Reading alone has become a commodity. In February 2026, LIS extended its WinSped Web platform. The new part is AI-based capture. It reads PDF, scanned fax, delivery notes and even handwritten orders. No fixed template needed (LOGISTRA, 09.02.2026). Once that sits inside a standard TMS, reading stops being a differentiator. The real difference sits elsewhere. It sits in what happens to an order the system could not read with confidence.
That is exactly the documented weak spot of the industry. Strategy& and the BVL surveyed 115 logistics providers in autumn 2025. 96 percent had started digital transformation. Only 10 percent scale it beyond single projects. 54 percent name data availability and quality as the biggest hurdle. Ahead of budget and staff (Verkehrsrundschau, BVL study report Trends und Strategien 2025/26). That matches what we see in projects. Extraction is rarely where things break. Master data does not know the loading point. Or the customer number in the document does not match the TMS.
A reading agent takes every order through three steps.
First, extraction. The agent reads the mail text, the attachment or the portal export. It pulls out the fields: customer, loading point, unloading point, date, reference, quantity. Every field carries its own confidence score. Not just the whole document, each field on its own. A document can be confident on the customer number and unsure on the date. Sometimes two dates appear in the same text.
Second, master data reconciliation. Every field gets checked against the TMS. The customer number has to exist. The loading point has to match the customer address. Or sit stored as a known exception. Our knowledge net holds a matching reference case. A converter pulls a dispatch plan for a contract carrier straight out of the mailbox. It imports the plan into the TMS, with nobody retyping a line. Reading the file was never the failure point. Reconciliation was. Exactly when a driver or customer name did not map cleanly to a master data ID.
Third, the decision. If every field clears its threshold, the agent creates the order in the TMS. If a threshold fails, the order goes into the review queue. The exact reason comes in plain text. Loading point not matched. Layout unknown. Quantity deviates. Reference already exists. No order disappears without one. None gets created while the system itself is unsure.
Every order leaves a trail. Arrival, extraction with per-field confidence, the master data check, the decision. For review cases, the message back to dispatch too. The monitor shows one line per order. Not a daily summary. If an order was created wrong, the log points straight to the spot. That is where the system was too confident. That is the difference from a plain OCR tool with no log attached. There, nobody sees why one order went wrong. Until the customer calls.
When a customer changes their PDF layout, confidence for their orders drops overnight. The agent does not start creating wrong orders. It routes more of them to the review queue. Tagged "layout unknown" or "extraction uncertain." Dispatch sees the spike the same day. Not a week later, buried in wrong delivery notes.
An automation rate is a nice number for management. For dispatch it is close to useless. It does not say what to do next. The reason column in the review queue does. It shows which customer regularly sends a layout the agent cannot place with confidence. It shows whether a loading point is missing because it is new. Or because it was never set up properly. It shows whether an error is systematic or a one-off.
That is exactly what turns the reason column into a conversation. Before the agent, nobody knew how often a customer sent a broken PDF. Every case got absorbed into manual work without a trace. With the review queue, the frequency is visible. With date and customer attached. That is a sales conversation: "Your PDF export changes roughly every three weeks. Can we agree on a fixed template?" Nobody asked that question before. Nobody had the data for it.
What disappears is the retyping. Every order the agent reads with confidence, and that clears the master data check. Depending on the customer mix, that is most of the volume. What stays is the review queue. It is work with context, not work without. Instead of reading a PDF from scratch, a dispatcher sees which field was uncertain. And why. She confirms or corrects one field, not the whole order again.
The order of the working day changes too. Instead of working through orders by arrival time, dispatch works the review queue by reason. Tight deadlines first. Then unclear quantities. Then the layout cases, batched and handed to sales anyway. That sorting only exists once the reason sits in the system.
A high rate without a reason breakdown can describe two very different systems. In one, the review queue shrinks because master data improves. Fewer orders are genuinely unclear. In the other, it shrinks because the confidence threshold was set too low. The agent creates orders it should have flagged instead. Without the reason column, you cannot tell the two apart from outside. With it, you can. If the share of wrongly created orders rises afterward, while the rate stays flat, the threshold is the problem. Not the data quality.
Does order capture from email and PDF cost your dispatch the most time? Send us one anonymized sample PDF your system does not process cleanly today. We show you the log of our reading agent for that exact case. With confidence score, master data reconciliation and the reason it would write into the review queue. Our dispatch plan import from Excel and SharePoint works on the same reconciliation logic, one layer up.
