The Complete Guide to
Shipping & Freight Document Extraction

The Shipping Document Ecosystem — Five Documents, One Shipment

Before extraction begins, a logistics team needs a map of what they're extracting and how the documents relate. A typical FCL (full container load) ocean shipment generates these five core documents:

The shared-field problem is visible immediately: container number appears on the BOL, manifest, packing list, and freight invoice. BOL number links the manifest, commercial invoice, and freight invoice. Gross weight is declared on the BOL, manifest, and packing list — but rarely in the same unit (the BOL may show kilograms, the packing list pounds, and the manifest metric tons). An extraction process that reads each document in isolation produces five datasets that don't match. An extraction process designed for the shipping packet reads them together and flags the discrepancies.

For a deeper look at how semantic AI extraction handles these documents differently from traditional OCR, see our OCR for logistics guide and the fundamentals of what AI OCR is.

Bills of Lading — The Master Document

A bill of lading is the most legally complex document in the shipping packet. It is simultaneously a receipt for goods, a contract of carriage, and — in its negotiable form — a document of title. The field count alone explains why extraction here is non-trivial: a typical ocean BOL carries 30-40 data fields spread across 3-5 pages, governed by multiple international standards.

We have published a dedicated complete guide to BOL data extraction that covers BOL types (straight vs ocean vs multimodal, master vs house), extraction pipelines, and validation in full depth. Here, we focus on what matters for the cross-document packet: the fields that every other shipping document references.

The SCAC code is worth a closer look because it is the most commonly mis-extracted field in logistics. A BOL may print the carrier name as "Maersk Line" while the TMS expects MAEU. Another carrier may list their name alongside a SCAC that looks like a reference number. Semantic AI extraction handles this by recognizing the standard code pattern (2-4 uppercase letters, often in proximity to the carrier name or a SCAC label) and extracting it as a separate field from the full carrier name — but not all extraction tools are designed to look for SCAC codes at all. Many treat the carrier field as free text and output "Maersk Line" when their system needed MAEU.

For a field-level accuracy breakdown on shipping labels and their data points, see our companion article Can AI Extract Shipping Label & Manifest Data?

Cargo Manifests — The Shipment-Level Inventory

A cargo manifest is a complete list of all shipments loaded onto a conveyance — a vessel, a truck, an aircraft, or a train. Unlike the BOL, which is a single-shipment contract, the manifest is a multi-shipment inventory used primarily by customs authorities, port operators, and terminal handlers.

An ocean manifest typically contains one row per BOL on the vessel, with these key columns:

• Master BOL number — the carrier-issued BOL that covers the consolidated shipment
• House BOL number(s) — forwarder-issued BOLs for each underlying shipper, if applicable
• Container number(s) — all containers associated with each BOL
• Commodity description — often abbreviated or grouped (e.g., "General Department Store Merchandise" for a consolidated container)
• HS Code — 6-10 digit classification for customs
• Gross weight and volume — total per BOL
• Port of loading and port of discharge — in UN/LOCODE format
• Shipper and consignee — names and addresses
• Vessel name and voyage number — for maritime manifests

The format challenge with manifests is that they come in two fundamentally different structures. CBP-compliant ACE manifests for US-bound shipments follow the CBP 1301 (Inward Cargo Manifest) or CBP 1302 (Outward) format, with specific required fields for ISF filings. Commercial manifests used by freight forwarders internally may use completely different layouts, grouping fields per container rather than per BOL. An air cargo manifest (AWB manifest) uses a different header structure than an ocean manifest — flight number instead of vessel name, MAWB/HAWB instead of MBL/HBL.

The extraction challenge is that manifest data must reconcile with BOL data at the container level. If the manifest says container MSCU 234781 6 carries 500 cartons and the BOL says 480, that 20-carton gap is either a manifest entry error or a BOL error — and it will be flagged by customs or the receiver. Semantic extraction that reads both documents and compares their shared fields during processing catches this mismatch before it becomes a customs hold.

Packing Lists — The Item-Level Breakdown

A packing list is the most granular document in the shipping packet. While the BOL shows total weight and total piece count, the packing list breaks down what is inside each package — carton by carton, pallet by pallet. For LCL (less-than-container-load) shipments, the packing list is the document that tells the freight forwarder how to consolidate cargo from multiple shippers.

Standard packing list fields include:

The packing list's role as the item-level truth document means it is the anchor for one of the most important cross-document checks in shipping: the quantity reconciliation. The commercial invoice says 2,000 units at $12.50 each. The packing list says 2,000 units in 40 cartons of 50. The BOL says 40 cartons. If any of these numbers disagree, the customs broker must decide which document to trust — and an extraction tool that reads all three can flag the mismatch in a single reconciliation column.

Packing list formats are surprisingly variable. A manufacturer's packing list may be a multi-page Excel export with 50 line items per container. A freight forwarder's house packing list may condense the same information into a single row per commodity. A consolidated container packing list must map multiple purchase orders into a single container — a format that traditional OCR tools struggle with because line-item borders cross PO boundaries.

Commercial Invoices — The Customs Valuation Document

A commercial invoice is the document that customs authorities use to assess duties and taxes. Unlike the packing list (which focuses on physical cargo) or the BOL (which focuses on carriage), the commercial invoice is about value: what was sold, for how much, under what trade terms, and where it originated.

The field structure is closer to a standard sales invoice but with additions specific to international trade:

• Seller and buyer — name and address (may differ from shipper/consignee on the BOL if a third-party logistics provider is involved)
• Invoice number and date — the exporter's reference, often cross-referenced on the packing list
• Shipment reference — PO number, BOL number, container number, booking number
• Line items — description, HS code, quantity, unit price, total value per line
• Incoterms — the trade term (FOB Shanghai, CIF Rotterdam, EXW Factory, DDP Buyer's Warehouse) that determines who pays for freight, insurance, and duties
• Country of origin — where the goods were manufactured or substantially transformed
• Total declared value — the basis for duty calculation
• Currency and payment terms — USD, EUR, JPY; Net 30, T/T, L/C

HS code extraction on commercial invoices deserves special attention because it is the field most likely to cause customs delays if incorrect. A six-digit HS code (the minimum under the Harmonized System) classifies a product into a specific chapter, heading, and subheading. An incorrect HS code can mean the wrong duty rate is applied — or worse, the goods are flagged for inspection because the code does not match the description. Extraction tools that treat the HS code as a generic alphanumeric field miss the opportunity to validate it against the first six digits of the WCO classification. A semantic extraction setup that knows the HS code pattern (XXXX.XX or XXXXXX.XX) and cross-validates it against the commodity description catches this before the customs broker sees it.

The commercial invoice also carries the single most important cross-document reference field: the Incoterm. The Incoterm determines whether freight charges are prepaid or collect on the BOL, who arranges insurance, and where the risk transfers from seller to buyer. An extraction that reads "FOB Shanghai" from the commercial invoice and "Freight Collect" from the BOL without flagging the inconsistency (FOB is collect under most carrier interpretations) misses a reconciliation that costs time at customs.

Freight Invoices and Shipping Labels

Two additional documents round out the shipping packet.

Freight invoices are the carrier's bill for transportation services. They reference the BOL number and container number and itemize charges: line-haul rate, fuel surcharge, chassis rental, detention, demurrage, pick-up and delivery fees, and accessorials. The extraction challenge with freight invoices is not reading the charges — it's matching each charge to the correct BOL and checking whether it was contractually agreed. A carrier might bill $250 for a lift-gate service that was not requested. The freight invoice extraction must preserve enough reference data (BOL number, container number, dates) to enable the AP team to cross-reference against the rate confirmation or booking. A computed column in the extraction setup — comparing the line-haul charge against a known contract rate and flagging any variance above 5% — turns a passive extraction output into an active audit tool.

Shipping labels are the last-mile touch point. A carrier-printed label carries tracking number, barcode, sender and recipient addresses, service level, package weight, and reference fields. Our shipping label and manifest extraction article breaks down field-by-field accuracy rates for thermal labels vs inkjet labels vs handwritten corrections. The key point for packet extraction is that the tracking number on the shipping label should resolve to the BOL number or a cross-reference in the manifest. When it doesn't, the shipment's last-mile tracking breaks.

Batch Processing the Full Shipping Packet

Reading a single BOL or packing list is table stakes. The efficiency gain comes from batch-processing a full shipment's document packet — all five (or more) documents — in one operation, with cross-document fields mapped to the same output columns.

Here is how a typical shipping packet batch processing workflow looks:

This workflow is what batch-first processing was designed for: the ability to upload a mixed-format packet of 5-15 documents, define your column schema once, and get a single output table with validated, cross-referenced data. No per-carrier template setup, no per-document-type reconfiguration.

Field Validation — From Raw Text to TMS-Ready Data

The difference between a useful extraction output and a generic text dump is the validation layer. Shipping documents use code systems that have built-in validation rules — an extraction tool that applies these rules catches errors that would otherwise reach your TMS or customs filing.

A validation pipeline that applies these rules during extraction does more than catch errors — it builds a dataset that is ready for downstream systems without a manual cleanup pass. The container number that passes ISO 6346 check-digit validation can be sent directly to a carrier's tracking API. The UN/LOCODE that passes the UNECE lookup can be loaded into a TMS routing table. The HS code that matches the commodity description can be submitted to customs with confidence.

Without validation, extraction produces a spreadsheet of raw text that looks correct — until the carrier's tracking API returns "container not found" because digit 7 and 11 were swapped. That delay, at $100-500 per day in demurrage charges, makes the difference between extraction that saves money and extraction that creates a different kind of cost.

Export Strategies — What Goes into the Final Spreadsheet

Shipping document extraction is not finished until the data is in a usable format. The output strategy depends on who uses it and what system it feeds.

Per-document rows. Each document in the packet generates one output row. The BOL row contains all BOL fields. The packing list row contains all packing list fields. This preserves the full detail of each document but requires you to cross-reference across rows manually. Best for teams that need to audit each document individually.

Per-shipment consolidated rows. One row per shipment, with columns grouped by source document: BOL_Container_Number, Manifest_Container_Number, PL_Container_Number, followed by a reconciliation column. This is the format that AP teams and customs brokers prefer — all data for the shipment in one place, with discrepancies visible at a glance.

Per-line-item rows. One row per line item from the packing list or commercial invoice, with shipment-level fields (container number, BOL number, port codes) repeated on every row. This is the format for inventory management systems and duty calculation engines that need item-level detail.

ImageToTable.ai supports all three output formats via its batch processing pipeline. The export token system lets you generate Excel files on demand and share them with team members who don't have accounts — the receiver opens a link and downloads the output. This is particularly useful for freight forwarders who need to share shipment data with their clients without giving each client access to the tool itself.

Common Pitfalls in Shipping Document Extraction

Even with the right approach, shipping document extraction has traps that catch logistics teams who are new to automated processing.

Treating all BOLs as the same document. A straight BOL, an ocean BOL, a multimodal BOL, a house BOL, and a master BOL share a name but differ in field structure and legal effect. An extraction setup that works on a straight BOL (one shipper, one consignee, simple routing) will miss the HBL reference number on a house BOL and the onward carriage terms on a multimodal BOL. The solution is to design your column schema for the most complex document type you encounter and let simpler documents populate fewer fields.

Ignoring the consolidation layer. When a freight forwarder consolidates shipments from five shippers into one container, the packing list is not a single document — it is a collection of shipper-level packing lists plus a consolidation manifest. The extraction setup must understand that container MSCU 234781 6 may contain 15 separate purchase orders from five exporters, each with its own PO number, HS code, and country of origin. A tool that outputs one row per container misses all the item-level detail that customs requires.

Skipping weight normalization. The BOL may show 15,420 KGS. The manifest shows 34,000 LBS. The packing list shows 340 CWT (hundredweight). These are the same weight in different units — but raw text extraction outputs them as three different numbers. A computed column that normalizes all weights to a single unit (kilograms) and flags any actual discrepancies (after unit conversion) prevents weight-related customs holds and carrier invoice disputes.

Not validating codes at extraction time. An invalid container check digit, a non-existent UN/LOCODE, or a mismatched HS code that is caught at extraction time costs nothing to fix. The same error caught 48 hours later — after the ISF filing has been submitted, after the cargo has been loaded — triggers a $5,000 amendment penalty under US CBP regulations (19 CFR 149.3). Extraction without real-time validation is not extraction — it's typing at speed.

Frequently Asked Questions

Building a Repeatable Shipping Document Workflow

Shipping document extraction is not a one-time digitization project. It is a repeatable operational process: every day, a shipment's worth of BOLs, manifests, packing lists, commercial invoices, and freight invoices arrives as PDFs and images, and every day, that data needs to reach the TMS, the customs broker, and the AP system without a manual typing pass. The difference between extraction that works and extraction that creates new work is whether the tool handles the full packet together — with cross-document field mapping, code validation, and batch export — or whether it forces you to extract each document type separately and stitch the results by hand.

The tool that reads the BOL and stops — before the manifest, before the packing list, before the cross-document reconciliation — has read one document. It has not processed the shipment. A complete extraction captures the packet, validates the shared fields, and outputs a dataset where discrepancies are already flagged and codes are already standardized. That is the difference between a document-reading tool and a shipping document workflow.