Document Processing Agent for Logistics Operations

⚠ This case study is anonymised under a non-disclosure agreement. The client name, logo, system screenshots, and business figures are not published. What is described below is the engineering scope of the work.

The problem

The operations team received shipping documents as PDFs and scans from dozens of partners, each with its own layout. Every document was read by hand and its fields retyped into the operations system. The step became a bottleneck whenever volume rose, and typing errors only surfaced at the invoicing stage.

What we built

One document processing service sitting between the inbox and the operations system:

1. An incoming document is classified into one of three supported flows.
2. A language model extracts structured fields along with a confidence score.
3. A validation layer checks the extraction against business rules and reference data in the internal database.
4. Documents that pass go through automatically. Documents that fail validation or come back low-confidence enter an operator review queue with the uncertain fields highlighted.

Engineering decisions

We rejected the “one prompt for every document” approach. Each document flow has its own extraction schema and its own evaluation set, built from 400 real documents labelled by the operations team. Every prompt change and every model swap runs against that set first, so an improvement to one flow cannot quietly break another.

The operator escalation path was built before the automation was. This system was never designed to run without people; it was designed to hand over the cases it is unsure about, and that is what makes it trustworthy for the rest.

Handover

Code, infrastructure configuration, evaluation sets, and the operational runbook were handed to the client’s repository. Their internal team runs and extends the system now.