Documents arrive at a distribution business in formats nobody chose. A warehouse sends packing slips as files to an FTP folder. A marketplace supplies labels with tracking numbers printed on them. Neither comes as structured data, and both contain information the order record needs.
The default handling is a person opening each document and typing what they find into the system. That works, it is slow, and it produces a particular failure: the order record is accurate for the documents somebody has got to, and silently incomplete for the rest.
Why the slip matters after the goods have gone
A packing slip is produced after the decision-making is over. The order was taken, the stock allocated, the carton packed. So it is tempting to treat the slip as paperwork.
It is actually the confirmation of what physically happened, which makes it the one document that can disagree with your system. The order says one thing, the warehouse did another, and the slip is the evidence. If it never reaches the order record, nothing reconciles the two.
That is also why the tracking number matters. Until it is attached to the order, nobody answering a customer question can say where the parcel is without opening another system.
The flow we build
On the ERP we built for a US consumer electronics brand, packing slips received over FTP are OCR-processed and matched to their sales order, with an exception queue for anything that does not match, and tracking numbers are read from marketplace-sourced labels.
There are four steps in that, and each one is worth separating.
Arrival. Slips land in an FTP folder on a schedule set by whoever sends them. An FTP drop is unglamorous and it is also reliable, which is why it is still how a great deal of logistics data moves. The system watches the folder rather than waiting to be told.
Extraction. OCR reads the document and pulls out the fields that identify it: the order reference, the items, the quantities. This is the step people assume is the hard part. It is not.
Matching. The extracted reference is resolved to the sales order that produced the slip. This is the hard part, and the next section is about why.
Attachment. Once matched, the slip and its data belong to the order, and the tracking number read from the label is attached to the same record. From that point, anyone looking at the order can see what shipped and where it went.
Matching is where the difficulty lives
Extraction gives you a string. Matching has to turn that string into one specific order, and the reasons it fails are mundane rather than technical.
The reference on the slip is not always the reference in your system: a warehouse may print its own number, a marketplace its order ID, and your ERP a third. Characters get misread, and a zero read as an O turns a valid reference into a non-existent one. The same reference can appear on more than one document when a shipment splits. And sometimes the slip genuinely refers to an order that was cancelled or amended after the document was produced.
Each of those needs a decision: match confidently, or do not match at all. What it must never do is match approximately, because an incorrect match attaches shipment evidence to the wrong order and that error is harder to find than a missing slip.
The exception queue is the point
This is the part that gets left out of automation projects and then determines whether anyone trusts them.
Every document that fails to match goes to an exception queue for a person to resolve. Not a log file, not an email that gets filtered, a queue that someone owns and works through.
The queue does two jobs. It guarantees nothing is lost, which is what lets you automate the confident cases aggressively. And it tells you where the automation is weak, because a pattern in the exceptions is a specification for the next improvement: one partner’s layout changed, one reference format was never handled, one document type always fails.
A pipeline with no exception path has to be conservative everywhere, because any failure is silent. A pipeline with a good exception path can be confident on the clear cases and honest about the rest.
Where this sits alongside EDI
If you exchange EDI documents with trading partners, it is fair to ask why packing slips are being read by OCR at all. The answer is that not every partner sends structured documents, and the ones that do not are usually the ones you cannot compel.
So the two coexist. Structured documents come in as transaction sets and need no extraction. Everything else arrives as a file and needs reading. Both end up on the same order record, which is the only outcome that matters for the person answering the phone.
That is the argument for doing this inside the ERP rather than in a separate document tool. The slip has nowhere useful to go except the order, and the order is already here.
Where to start
Count the documents arriving as files rather than as data, and for each one ask what field on the order record it is supposed to populate. That list is the project.
Then build the exception queue before the extraction, not after. It sounds backwards and it is the step that makes everything else safe to switch on.
We build this as AI and OCR document automation inside the system that holds the orders, alongside structured partner documents as EDI integration. The wider system is described in our multi-marketplace ERP case study. If documents are currently being re-keyed into your ERP, get in touch and tell us which document costs your team the most time: what field on the order is it actually there to fill in?
Common questions
What happens to a slip that cannot be matched?
It goes to an exception queue for a person to resolve, rather than being guessed at or silently dropped. The queue is the part that makes the automation safe to trust.
Does OCR need a fixed document template?
It helps, but documents in practice vary between partners and change without notice. Treat the layout as something that will drift and build the exception path accordingly rather than assuming a stable template.
Why not just have staff enter the tracking numbers?
They can, and many do. The cost is not the typing, it is that the data arrives late and unevenly, so the order record is incomplete exactly when a customer asks where their parcel is.