Skip to content
All field notes
From practice24 July 20265 min read

Automating packing lists: the real lesson is in the exceptions

Automating packing lists tends to go faster than expected. What people underestimate is not the implementation itself, but what goes wrong afterward: the exception nobody saw coming. The lesson that keeps coming up in document automation is not a technical one. It is about how you design the process around documents that are just a little different from the rest.

By Yeslin Beljaars

Automating packing lists: the real lesson is in the exceptions

Photo: TruckRun on Unsplash

Why automating packing lists looks attractive

Packing lists are repetitive. They always come from the same suppliers, always contain the same columns, and processing them is pure manual work: copying lines into your WMS, ERP, or inspection software. For a company handling hundreds or thousands of packing lists a year, that is a clear candidate for automation. The volume is high enough, the process is defined, and the added value of manual data entry is zero. HDG, active in food and quality inspection, processed 200,000 packing lists per year and eliminated 90% of the manual work after automation was introduced. That sounds like a smooth transition, but the picture is only partly accurate.

What goes wrong when you only build for the standard case?

Most packing lists arrive neatly as PDFs or Excel files with a fixed structure. The automation process is built around that. But then a supplier sends a packing list as a screenshot from their own system, or another party uses a slightly different column order, or a document arrives as an attachment in the wrong format. Anyone who has not designed an exception process has a problem: the document is not processed, no one receives a notification, and only later does it become clear that something slipped through the cracks. The lesson is simple and yet keeps being learned the hard way: automation works for the standard case. But your process stands or falls on how you handle the exceptions.

How do you design the exception process correctly?

Three principles help. First: make deviations visible, not invisible. A document that could not be processed automatically must immediately land in a queue that someone actually monitors, not disappear into a folder nobody opens. Second: have a person review uncertain cases. Not as a bureaucratic step, but as a genuine safety valve. When a system cannot read a field with sufficient confidence, it routes the document back for human review. That is not a failure of automation; that is the system working correctly. Third: track which exceptions recur most often. If one supplier consistently sends documents in a non-standard format, that is input for a targeted adjustment, not a reason to question the entire system.

Is the quality of your source document also a factor?

Absolutely, and this is the point where honesty pays off. When packing lists are structurally poor, think handwritten additions, partially printed PDFs, or documents scanned at an angle, automation delivers less value until that problem is resolved. No system reliably extracts data from a document that is unreadable to a person with good eyesight. The question you need to ask upfront is not only: how many packing lists come in? But also: how many of them are consistent enough in quality to be read reliably? The answer to that second question largely determines what you can expect from automation.

What does automating packing lists actually deliver when it is set up correctly?

When the volume is high enough, the process is defined, and the exception handling is in place, most of the manual entry disappears. Employees who previously spent their time copying lines into inspection software or a WMS are freed up for the work they were hired to do: checking, flagging, deciding. At HDG, that meant a freed-up FTE returning to the inspection work itself. That is the real gain, not the time saved on a single document, but the structural shift in what people do with their workday. The lesson that keeps coming back: start with high volume and good document quality. Expand from there. Anyone who tries to automate the entire document landscape at once will get stuck on exceptions they did not anticipate.

Seeing this in your own document flow?

Book a demo on your own documents

Frequently asked questions

What are the benefits of automating packing lists?

The manual work of copying lines into ERP, WMS, or inspection software largely disappears. Employees are freed up for checking and decision-making tasks. With sufficient volume and consistent document quality, the time savings are significant.

When does automating packing lists not make sense?

When the volume is too low, the process is not clearly defined, or the source documents are structurally poor quality, such as unreadable scans or inconsistent formats, the return does not justify the setup effort.

How do you handle suppliers who send packing lists in non-standard formats?

Make sure non-standard documents automatically land in a recognizable queue for human review. Track which deviations occur most often and adjust the configuration for structural cases.

Does a person always need to be involved in automated packing list processing?

Not for every document, but for uncertain cases, yes. A well-configured system flags uncertain readings and presents them to an employee. This keeps the decision with a person and keeps the output reliable.