Situation
At the time of engagement, the client was processing between 750 and 900 cargo documents per day — Bill of Lading, CMR waybills, Delivery Orders, Packing Lists, and customs declaration documents arriving from carriers across 14 countries in multiple languages and formats.
Six experienced document specialists handled this workload manually. Each specialist reviewed incoming documents, extracted key data fields (container numbers, cargo weights, consignee details, Harmonised System codes, seal numbers), checked them against the TMS, and routed exceptions to the operations team.
The average end-to-end processing time per document was approximately [DATA: confirm baseline — approximately 4 hours from receipt to system record]. At peak periods — typically Monday mornings and post-weekend vessel arrivals — backlogs reached 200+ documents, causing downstream delays to gate release and cargo handover.
- Document error rate of approximately [DATA: confirm baseline] % — primarily missed fields and transposition errors on HS codes — generating an average of [DATA: confirm] correction cycles per error
- Each correction cycle delayed cargo release by a minimum of [DATA: confirm] hours, at an estimated cost of €[DATA: confirm] per delayed unit
- Six FTEs dedicated primarily to data entry and document routing — a bottleneck that was expected to worsen as throughput grew
- Vendor lock-in risk: the client was evaluating a commercial document processing SaaS product that would have required uploading cargo manifests to servers outside the Netherlands — rejected on data residency grounds by their legal team
The data residency requirement was the immediate trigger for the engagement. The client had short-listed a US-based document AI vendor but could not pass legal review because cargo manifests contain personal data of named consignees. They needed a solution where all processing occurred within Dutch Azure infrastructure.
Task
IITS was engaged to design and deploy a production-grade document intelligence pipeline that met four non-negotiable criteria set by the client:
- All processing on Azure Netherlands (West Europe region) — no data to external APIs, no public LLM submissions
- Integration with the existing TMS via API — no replacement of operational systems, no data migration
- Extraction accuracy sufficient to reduce manual review to exceptions-only — targeting fewer than [DATA: confirm] % of documents requiring human intervention
- Full audit trail on every document: model version, extraction date/time, field confidence scores, human review flag, and TMS write confirmation
Secondary objectives: reduce processing backlog to near-zero under peak load conditions, enable the team to redeploy specialist capacity from data entry to higher-value exception handling and carrier relationship management.
Action
Phase 1 — Document Taxonomy and Training Data (Weeks 1–3)
We began with a structured document audit. Working with the client's document specialists, we catalogued all document types (14 distinct formats across the two primary document classes), identified the 40 key extraction fields required for TMS population, and collected a representative sample of historical documents — [DATA: confirm sample size] labelled examples — covering the full range of carrier formats, languages, and quality levels.
The label set was validated by two senior document specialists who had handled the client's document flow for more than five years each — ensuring that edge cases (damaged documents, partially legible fields, non-standard carrier formats) were represented in the training corpus.
Phase 2 — Azure Infrastructure and Private Deployment (Weeks 3–6)
We provisioned a dedicated Azure environment within the West Europe region under the client's existing Enterprise Agreement. Key architectural decisions:
- Azure OpenAI deployed as a private endpoint within the client's virtual network — zero internet egress from the processing pipeline
- Azure AI Document Intelligence (custom model) fine-tuned on the labelled document corpus for structured field extraction
- Azure API Management as the integration layer between the extraction pipeline and the existing TMS — handling authentication, rate limiting, retry logic, and audit logging
- All credentials, API keys, and connection strings stored in Azure Key Vault — never in code or configuration files
- Azure Monitor and Log Analytics configured for end-to-end observability: extraction latency, confidence score distributions, exception rates, and TMS write success rates
Phase 3 — Integration and Parallel Running (Weeks 6–10)
The integration with the client's TMS was implemented via a REST API wrapper we developed in cooperation with their internal IT team. The API contract was designed to be non-breaking — existing manual processing workflows remained fully operational during the parallel-running period.
During parallel running, the automated system processed every incoming document alongside the manual team. Document specialists reviewed AI extraction outputs against their own work and logged discrepancies. This generated a rich error dataset used to fine-tune the extraction model in two iteration cycles.
The parallel running phase identified a consistent failure pattern on one carrier's Bill of Lading format — a non-standard column layout that the base model misclassified. Two additional labelled examples from this carrier's documents resolved the issue and brought extraction confidence on that format from 71% to 97%.
Phase 4 — Exception Routing and Production Handover (Weeks 10–14)
Before switching to automated-first processing, we built and validated the exception routing logic. Documents with one or more field confidence scores below the agreed threshold (configurable, initially set at 85%) were automatically flagged for human review and routed to a dedicated exception queue — visible in a lightweight dashboard built on Microsoft Fabric.
The exception dashboard was designed with the document specialists, not for them. Each flagged document showed: the extracted fields, confidence score per field, the source document image with the relevant region highlighted, and a one-click TMS confirmation path. Specialist review time for flagged exceptions dropped from approximately 12 minutes (manual processing) to under 3 minutes (verification-only).
Result
Four weeks after going live, the client confirmed the following production outcomes:
The six document specialists were not made redundant. Four were redeployed to exception management and carrier onboarding — handling the growing volume of new carrier integrations as the terminal expanded routes. Two were upskilled into the terminal's new data operations team, monitoring the Microsoft Fabric dashboard and managing the extraction model's ongoing performance.
The legal team confirmed data compliance sign-off within two weeks of go-live — specifically noting the private Azure endpoint architecture, the complete absence of data transfers to third-party services, and the audit log coverage as factors enabling the approval.
"We had been trying to solve this for three years. Every vendor we spoke to wanted us to send our data to their cloud. IITS built the whole thing inside our own Azure environment. The data residency problem disappeared because the architecture made it impossible to have one." — Head of Operations, [CLIENT NAME WITHHELD]
Lessons and Replication
This project is now the basis for our Automated Maritime Document Extraction productized solution — a fixed-scope 14-week programme applicable to any logistics operator processing structured cargo documentation at volume.
- The parallel running phase is non-negotiable. It is the primary mechanism for domain adaptation and it is where the real accuracy gains are made.
- Exception routing design should involve the specialists who will handle exceptions — not just the technical team. The dashboard that gets used is the one designed with the people processing exceptions daily.
- Private Azure endpoint architecture is not a premium add-on. It is how we build every document processing system for logistics clients. The data residency risk of sending cargo data to public LLM APIs is not theoretical — it is a concrete procurement blocker.
- Model performance monitoring post-go-live is mandatory. We configure confidence score distribution monitoring in Azure Monitor for every deployment. Drift in confidence scores on a specific document type is an early signal of a carrier format change that needs labelling.