Shipping document automation: from manual entry to AI extraction
At 2 a.m., three shifts of data entry staff key in bills of lading one by one. One container number wrong and the shipment stalls at customs. Shipping document automation doesn't fail on reading text. It fails on structure and compliance. Bills of lading, customs declarations, PODs each have different requirements. And validation is where projects actually break. Extracting data is routine. Getting it into production safely is the real difficulty. This is a practical guide to tying accuracy standards to business risk.
By
Tenten AI 交付團隊
產業交付
Published
October 31, 2025
Read time
6 分鐘

Last Wednesday at 2 a.m., I was still in a freight forwarder's office. Three data entry staff were working shifts, keying in the day's bills of lading one by one. A single bill has about forty fields: container number, seal number, quantity, gross weight, cubic meters, shipper, consignee, port codes. One character wrong and the entire shipment stalls at customs. A container on the dock for an extra day costs thousands in demurrage. Their error rate was around 3 percent. At eight hundred bills a day, that meant twenty or more needing rework.
That's the problem we're solving. Shipping document automation uses AI to extract fields from semi-structured documents (bills of lading, customs declarations, PODs) from scanned images or PDFs into structured data that systems can use, replacing manual entry. This brings a critical requirement along with it: verifiable accuracy standards that make it safe to deploy. Extracting data is routine. Getting it validated and trusted in production is harder.
Three document types, three different challenges
Most conversations about this start with 'just use OCR.' It's a dead end. OCR solves the character recognition problem, but that's not what makes these three document types difficult. Each one has different structures, variation patterns, and validation needs.
Bills of lading (B/L) are most problematic because there's no standard format. Maersk, ONE, Evergreen. Each carrier has different layouts. Within each carrier you also have variants: originals, telex-releases, sea waybills. Field positions shift. The consignee field often runs three lines of address plus contact details. Instead of forcing templates, we use semantic field extraction. We teach the model to understand 'this text is the consignee' rather than 'the text at this pixel coordinate is the consignee.' Switch carriers and you don't need to re-annotate.
Customs declarations are difficult because of compliance, not format. Product descriptions have to map to the correct HS Code. Get the tariff classification wrong and Customs either rejects the entry or levies penalties. We deliberately don't let the AI guess the HS Code. After extracting the product description, we cross-reference it against the customer's own historical records and tariff databases, surfacing candidate codes with confidence scores. Anything below the threshold goes to a person. AI handles speed. It doesn't carry regulatory risk. That line is clear.
Proof of delivery (POD) is the messiest data of the three. It's usually a phone photo from the driver. Skewed, reflective, signature covering the date. Reading the signature isn't the value. The value is matching this POD back to the right shipment and capturing the delivery time and exception notes (damage, shortage, refused). Extracting the delivery date and shipment number matters far more than decoding handwriting.
Validation is where it all matters
I've seen too many projects fail here. Demo five clean bills, hit 99 percent accuracy, sign the contract. Go live, hit a crumpled fax, and it breaks. So from day one we lock down validation standards with the customer. Field by field, document type by document type. Not some blanket overall accuracy rate.
| Document | Critical Fields | Validation Accuracy Threshold | Below Threshold Action |
|---|---|---|---|
| B/L | Container number, quantity, gross weight | ≥ 99.5% | Auto-match against carrier EDI for cross-verification |
| B/L | Shipper/consignee, terms | ≥ 97% | Low-confidence results routed to manual review |
| Customs Declaration | HS Code mapping | Recommended ≥ 95% | Manual confirmation required; AI provides candidates only |
| POD | Shipment reconciliation, delivery date | ≥ 99% | Failed reconciliation enters exception queue |
Why 99.5 percent for container number but only 97 percent for consignee? A wrong container number voids the entire entry. A typo in the consignee address, people spot and fix. Validation thresholds tie to business risk, not perfection. Chasing perfect accuracy means sending records that could pass automatically back to humans, which defeats automation.
We also insist on this: before going live, we replay three months of actual customer documents, not clean samples. We throw in crumpled ones, blurry ones, stamps misplaced. The accuracy from that replay is the real number. Demo results don't count.
What actually happened
After full implementation at the freight forwarder, B/Ls and PODs ran fully automated. Customs declarations moved to AI extraction with manual tariff verification. Data entry went from three shifts to one person handling exceptions and spot checks. Average processing time per shipment dropped from seven minutes to forty seconds. Error rate stayed below 0.5 percent, and every error landed in the exception queue. Nothing reached Customs.
One tradeoff worth mentioning: in the first month post-launch, manual review rates spiked to 20 percent, higher than we expected. One small carrier's B/L format wasn't in our replay dataset. Two weeks of collecting samples and tuning thresholds got it down to 8 percent. You won't see that on a proposal slide, but it's part of real implementation.
This is our approach: engineers arrive with your real, messy files for validation, lock accuracy thresholds to business risk, and stay through the ramp-up phase until your team runs it in production. A polished demo doesn't count. What counts is nobody manually keying bills at 2 a.m. anymore.

One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.