The challenge: paperwork moving slower than the freight
A Tier-1 GCC logistics provider operating out of Riyadh came to us with a problem that had nothing to do with trucks, ports, or warehouse capacity. Their freight was moving. Their paperwork wasn't. Every cross-border shipment across the six countries they served required a stack of customs declarations, commercial invoices, certificates of origin, and carrier manifests, each formatted differently depending on the destination country's customs authority, and each one keyed in by hand by a documentation team that had grown from four people to seventeen over two years without the process itself changing at all.
The real cost wasn't visible on a single shipment. It showed up in the aggregate: documentation errors that triggered customs holds, holds that cascaded into missed delivery windows, and a headcount curve that was scaling faster than shipment volume, because more volume simply meant more people re-typing the same categories of information into slightly different forms. Leadership's stated goal was to stop hiring documentation staff at the same rate the business grew. That's an operations-efficiency problem, not a headcount problem, and it's the kind of problem AI automation is actually good at solving, as long as the workflow respects how customs data really behaves across jurisdictions.
The approach: a custom LLM pipeline, not a generic OCR tool
Off-the-shelf OCR and document-extraction tools exist, but they treat every document as a flat text-extraction problem. Customs and trade documentation isn't flat. A commercial invoice line item means something different depending on whether it's feeding a Saudi customs declaration, a UAE manifest, or an Omani certificate of origin, and the same source data needs to be reshaped, not just copied, for each destination format. So instead of bolting a generic extraction tool onto their existing process, we built a custom LLM pipeline trained specifically on the client's own historical documentation and the regulatory formats of the six countries they operate across.
The pipeline does three things in sequence: it extracts structured data from incoming shipment paperwork and supplier invoices regardless of source format (PDF, scanned image, or existing ERP export), it validates that data against country-specific customs rules before anything gets submitted, and it generates the destination-format documents automatically, flagging only the genuine edge cases, an unusual HS code, a mismatched weight declaration, for human review rather than routing every document through a person by default. Python orchestrates the pipeline stages, and the whole system runs on Azure, which mattered for this client specifically because of existing data-residency commitments tied to Saudi regulatory requirements.
Implementation: proving it on the hardest lane first
Rather than rolling the system out across all six countries simultaneously, we picked the single trade lane with the most document variability, a corridor that touched three different customs authorities with three different formatting conventions, and ran the pipeline in shadow mode alongside the existing manual process for several weeks. Every automated output was compared against what the documentation team actually produced by hand, not just for accuracy, but for whether the automated version would have actually cleared customs. That constraint mattered more than raw extraction accuracy: a document that's 98% correct but wrong on the one field customs cares about is a failed shipment, not a 98% success.
One decision made mid-implementation was to deliberately under-automate certain document types at first. Certificates of origin, which carry real legal weight and vary the most by bilateral trade agreement, stayed in a human-review-required state even after the core extraction and generation logic was working reliably, specifically because the cost of a wrong certificate is disproportionately high compared to the time it saves. That's the kind of constraint that doesn't show up in a demo but matters enormously in production, and it's part of why the rollout to the remaining five countries went faster than the first lane: the team trusted the system's judgment about what it should and shouldn't fully automate.
Results: less manual work, meaningfully faster operations
Once live across all six countries, the documentation team's manual workload dropped by 42%, measured in person-hours per shipment rather than headcount, since the goal from the start was to stop that curve from climbing further rather than to cut existing staff. That freed the team to focus on the genuine edge cases the pipeline correctly flagged, rather than re-typing routine data that followed predictable patterns.
The second, and arguably more significant, result was operational speed: shipments that used to sit waiting on documentation now move through that stage at 3.2 times the previous rate, because the bottleneck of a five-person queue processing forms sequentially was replaced by a pipeline that processes in parallel and only escalates what genuinely needs a human. For a logistics operation, faster documentation turnaround compounds directly into faster delivery windows and fewer customs-hold penalties, which is the number that actually mattered to the client's board.
