Automating Packing List and Bill of Lading Data Entry

Every importer and wholesaler I've spoken to has the same stack on their desk: a packing list PDF from the supplier, a bill of lading from the forwarder, and someone whose job is to retype both into a spreadsheet or a booking screen. It's not hard work. It's just slow, repetitive, and exactly the kind of task where a tired set of eyes drops a container number or transposes a weight. This is about what "automate data entry packing list" and "bill of lading data extraction" actually mean in practice, not what the marketing copy says they mean.

What's actually being extracted

A packing list and a bill of lading carry overlapping but distinct fields. Here's the shape of what a structured extraction produces from both documents together:

{
  "document_type": "bill_of_lading",
  "bol_number": "MAEU123456789",
  "shipper": "ACME TRADING CO LTD",
  "consignee": "NORTHSHORE IMPORTS BV",
  "notify_party": "NORTHSHORE IMPORTS BV",
  "vessel": "MAERSK ESSEX",
  "voyage": "412W",
  "port_of_loading": "SHANGHAI",
  "port_of_discharge": "ROTTERDAM",
  "containers": [
    {
      "container_number": "MSKU1234567",
      "seal_number": "SL998877",
      "gross_weight_kg": 18420,
      "package_count": 840
    }
  ]
}

{
  "document_type": "packing_list",
  "invoice_reference": "INV-2026-0442",
  "total_cartons": 840,
  "total_net_weight_kg": 16900,
  "total_gross_weight_kg": 18420,
  "line_items": [
    {
      "description": "Cotton T-Shirts, Mixed Colours",
      "hs_code": "610910",
      "carton_count": 420,
      "units_per_carton": 48,
      "net_weight_kg": 8450
    }
  ]
}

Notice the overlap: gross weight and package count appear on both documents and should match. That cross-check is the first thing worth doing before any data goes anywhere.

The permitted example, end to end

Take one incoming shipment. Supplier emails a packing list PDF, forwarder sends a bill of lading PDF. The workflow I'd expect to see:

1. Both documents land in one place (inbox, upload, or API).
2. Fields are extracted per the schema above, from each document separately.
3. The two documents are reconciled on the fields they share: container number, package count, gross weight.
4. Party names are checked against what you already have on file for that supplier or consignee, flagging anything new or mismatched rather than silently accepting it.
5. A human reviews the flagged items and anything the extraction marked as low confidence, not the whole document from scratch.
6. The reviewed, confirmed data is exported to wherever it needs to go next.

Step 6 is where most tools quietly go vague, and it's worth being precise about it.

Two different destinations, two different levels of trust

There's a real difference between "we can export a spreadsheet" and "we have a working connection into your operating system." Treat them as separate questions.

Generic spreadsheet or CSV handoff. If a tool extracts fields and drops them into a spreadsheet, that's a starting point to assess, not a finished workflow. You still have to get that data into whatever you actually run your import operation on. For most importers and wholesalers today, that's a manual step, and it's worth timing it the same way you'd time the typing it replaces.

CargoMode's connected workflow. CargoMode accepts packing lists, bills of lading and commercial invoices, extracts the fields, and runs them through operator review before they're confirmed. The part that's genuinely wired through end to end today is the CargoWise-connected booking path. If you run CargoWise, that connection is real and current. If you don't, treat the fit as a hypothesis to test on your own documents, not a shipped integration, until you've confirmed it against what you actually need. The honest move is to check the current scope at cargomo.de before assuming a feature exists.

Why operator review stays in the loop

Freight documents are inconsistent by design. Suppliers use their own templates, forwarders use their own layouts, and a single shipment can have revised packing lists that never get flagged as revisions. An extraction engine that silently guesses on a smudged container number or an ambiguous HS code digit is worse than one that flags it. That's why review sits in the workflow rather than being presented as optional. It's also why I won't give you an accuracy percentage here: any number without your own document set behind it is a guess dressed up as a fact.

Measure your own numbers before you measure a tool's

Here's the arithmetic worth running before you evaluate anything:

Documents per month    = D
Minutes per document   = M  (current manual keying, both PL and BOL)
Current monthly hours  = (D × M) / 60

Now estimate the review-only version:

Minutes per document under review  = R  (checking flagged fields only)
Projected monthly hours            = (D × R) / 60

Plug in your own D, M and R from your own records. If you haven't timed any of these yet, that's the first thing to do, not the extraction tool. A stopwatch on ten real documents this week will tell you more than any vendor claim.

What this isn't

To be clear about scope: this isn't purchase order automation, it isn't invoice reconciliation against a PO, and it isn't a ready-made connector into every ERP. It's packing list and bill of lading extraction with a human review step, and for CargoWise users, a connected booking path. If your workflow needs more than that today, say so when you test it, so you're assessing the actual boundary rather than an assumed one.

Next step

If you want to see how this holds up against documents you actually handle, bring a few representative redacted packing lists and bills of lading, along with the systems you run today, to a live assessment. For background on how extraction approaches differ before you get there, the OCR versus structured extraction comparison is worth a read, and if you want to sanity-check a container number by hand first, the container number validator is free to use right now.