SHARED

Packing List OCR and AI Data Extraction

Turn multi-page packing lists into editable package and cargo rows. GainingDocx extracts carton counts, marks, product lines, dimensions, net and gross weight, CBM and container references, then checks printed totals.

Packing lists are where the physical truth of a shipment lives: cartons, weights, dimensions, container loading. They are also the documents most often retyped into warehouse systems line by painful line. GainingDocx parses them in seconds.

Every line's weights are checked (gross must exceed net), line sums are compared against printed totals, and container references are verified with the ISO 6346 check-digit algorithm.

Parse a document free See pricing

No sign-up for your first document · 15–30 seconds per page

Short answer

Updated August 4, 2026

What a packing list parser extracts

Package rows with marks and case numbers, package type and count, contents with SKU and HS code, item quantity, net and gross weight, dimensions and CBM, plus container and seal allocation where the list is container-based. Printed totals are recomputed from the rows, and impossible relationships — net weight above gross, a total that does not match its lines — are flagged.

Package rows preserved, not summarised
Net, gross and CBM recomputed from lines
Container and seal allocation captured
Matched against the invoice and B/L

Packing List Fields Extracted

Packing list number, date, invoice reference and PO number
Seller and buyer
Line items with cartons, packages, net kg, gross kg and CBM
Per-line dimensions where printed
Total cartons, net weight, gross weight and volume
Container references

Packing List Total and Container Checks

Computed in code — the AI never does the math.

Line gross ≥ net on every row
Line sums vs printed totals (±0.5%)
Total gross ≥ total net
Container reference check digits (ISO 6346)
Cross-document: container sets and totals vs the B/L

How to Extract Packing List Data

01
Upload or photograph the document — pages are compressed on your device.
02
Review the extracted fields; deterministic checks flag anything suspicious.
03
Export to Excel, CSV or JSON, or generate the counterpart document.

Packing lists are the least standardised document in the set

Bills of Lading vary by carrier but converge on a recognisable structure. Packing lists have no such gravity. They are produced by whoever packed the goods, in whatever their ERP or spreadsheet emits, and the result ranges from a properly structured case-level table to a scanned spreadsheet with merged cells and a handwritten amendment in the margin.

That variability is why extraction has to be tolerant about layout and strict about arithmetic. The structure of any given packing list cannot be assumed; the relationship between net weight, gross weight and package counts can be, and it is where the real findings come from.

Merged cells spanning several package rows
Case ranges expressed as '1-20' in a single cell rather than as twenty rows
Dimensions given per carton on some rows and per pallet on others, without saying which
Weights in kilograms on one row and pounds on another
Subtotals per container interleaved with package rows
Handwritten amendments over a printed table
Continuation sheets where the header does not repeat

Field inventory

Packing list extraction

Group	Fields
References	Packing list number and date, commercial invoice number, purchase order or contract reference
Parties	Seller or exporter, buyer, consignee or ship-to
Shipment	Mode of transport, carrier, vessel or flight, port of loading, port of discharge, transport document reference
Package rows	Marks and numbers, case number or range, package type, package count, contents description, SKU, HS code, item quantity and unit
Weights	Net weight and gross weight per row, and shipment totals
Dimensions	Length, width, height and unit, and CBM per row where printed or derived
Equipment	Container number, seal number, size and type where the list allocates cargo to containers
Totals	Total packages, total net weight, total gross weight, total CBM
Certification	Packing and handling notes, preparer name and signature evidence

The checks that find real errors

Packing list validation is unusually productive because the document is full of quantities that must satisfy simple relationships. When they do not, something upstream is genuinely wrong.

Net weight compared against gross weight per row and in total — net can never exceed gross
Package counts summed across rows and compared with the printed total
Net and gross weights summed and compared with the printed totals
CBM recomputed from dimensions and package count, and compared with any printed CBM
Container check digits recomputed under ISO 6346 where the list allocates cargo to containers
Per-container subtotals summed against the shipment totals
Units checked for consistency across rows, since a single row in a different unit distorts every total
Case number sequences checked for gaps and overlaps against the stated package count

Net exceeding gross is more common than it should be

It is one of the most frequently triggered validations on real documents. The usual causes are net and gross entered in the wrong columns, units mixed across rows, or net taken from a product specification while gross was measured. Whatever the cause, a document where net exceeds gross has an error somewhere upstream that will surface at customs if it is not resolved first.

Where the packing list has to agree with other documents

Cross-document reconciliation

Compare with	What must agree
Commercial invoice	SKUs, line quantities, HS codes, origin, and net and gross weights where the invoice states them
Bill of Lading or air waybill	Package counts, gross weight, measurement, container and seal numbers, marks
Purchase order	Item and quantity against what was ordered, so short or over shipment is visible
Goods receipt	What was declared as packed against what was recorded as received
VGM declaration	Cargo gross weight plus container tare against the weighed figure
Shipping marks on the cargo	Case numbers and marks, which are checked physically at examination

Getting good results from difficult documents

1Submit the whole document including continuation sheets — package tables run over more often than any other document type.
2Where the packing list exists as a spreadsheet, submit that rather than a scan of a printout; structure that survives is structure that does not need reconstructing.
3Review the unit columns first, because a single row in the wrong unit distorts every total on the page.
4Check rows where dimensions describe a pallet rather than a carton, and confirm the CBM basis.
5Resolve any net-versus-gross flag at source rather than adjusting one figure to satisfy the check.
6Group with the invoice and transport document before exporting, so cross-document differences are caught in the same pass.

Try it on your own document — free, no sign-up

Start parsing

Packing List OCR FAQ

What teams ask most often before putting packing list parser output into a customs filing, a payment run or a downstream system.

What data is extracted from a packing list?

Package rows with marks and case numbers, package type and count, contents description, SKU, HS code and item quantity, net and gross weight, dimensions and CBM, plus container and seal allocation where present — together with the header references, parties, transport details and the printed shipment totals.

Are the totals checked against the lines?

Yes. Package counts, net weight, gross weight and CBM are all recomputed from the rows and compared with the printed totals. A total that does not equal the sum of its lines usually means a line was added, edited or removed after the total was written, and it is one of the more reliable defect signals in shipping documents.

What happens if net weight exceeds gross weight?

It is flagged as a contradiction, because the relationship is impossible. The usual causes are the two columns transposed, units mixed across rows, or a net figure taken from a product specification while the gross was measured. Resolve it at source rather than adjusting one number to satisfy the check, because customs applies the same logic.

Is CBM recalculated?

Yes, from dimensions and package count where dimensions are present, and compared with any printed CBM. Where a row's dimensions describe a loaded pallet or a whole lot rather than each package, the printed value is retained and the difference surfaced for review, since the calculation would otherwise be wrong by the number of packages.

Can it handle case ranges like 'C/NO. 1-20'?

Yes. A range expressed in one cell is captured as a range with its package count, rather than being misread as a single case. Case sequences are also checked across the document for gaps and overlaps against the stated total, which catches the common error of two rows claiming the same case numbers.

Does it capture container and seal allocation?

Yes, where the packing list allocates cargo to containers. Container numbers have their ISO 6346 check digits recomputed, seal numbers are captured as printed, and per-container subtotals are checked against the shipment totals. This is what makes a multi-container packing list reconcilable against the Bill of Lading.

What if the packing list mixes units?

Unit consistency is checked across rows and a mixed-unit document is flagged, because a single row in centimetres among rows in inches — or pounds among kilograms — distorts every total on the page while looking entirely normal. The printed unit per row is preserved so the source remains auditable.

Can the packing list be matched against the invoice?

Yes. Grouping them compares SKUs, line quantities, HS codes, origin and weights, and reports where the two documents describe the shipment differently. Divergence between the invoice and the packing list is one of the most common causes of customs queries and letter-of-credit discrepancies.

Does it work with scanned spreadsheets and photographs?

Yes, though a native file gives better results than a scan of a printout. Merged cells, handwritten amendments and photographed pages are all normal inputs. Where structure is genuinely ambiguous, the affected rows are surfaced for review rather than being resolved by assumption.

How does this help with VGM?

The packing list gross weight plus the container's stencilled tare should approximate the weighed VGM closely. Extracting the per-container gross weight makes that cross-check possible, and a material divergence means something was loaded, omitted or mis-weighed — worth resolving before the container ships rather than at the terminal.

Can I export the package rows to Excel?

Yes. Export produces an Excel workbook with the package rows intact on their own sheet, plus CSV and structured JSON where the row array needs to survive into a downstream system. Flattening the rows into a summary would defeat the purpose of extracting them.

Does the parser handle simple totals-only packing lists?

Yes, but it reports what it can. A list showing only shipment totals extracts those totals and records that no package-level detail was present, rather than fabricating rows. Where the document is too summarised to reconcile against the invoice, that limitation is stated instead of being hidden by a confident-looking result.

My packing list has 40+ lines. Will it work?

Yes — multi-page packing lists parse page by page, and every line lands in the Lines sheet of the Excel export.

Does it verify the totals row?

Yes. Line weights are summed in code and compared to the printed totals with a ±0.5% tolerance. A drift beyond that is flagged before anyone loads a container.

Can I create an invoice from the packing list?

Yes — the generator maps every line into a commercial invoice draft. Amounts stay blank (never invented); you fill in prices and download the PDF.

What formats can I upload?

PDF, JPG/JPEG, PNG, WebP, BMP and multi-page TIFF are supported. HEIC/HEIF also works when the device can decode it; otherwise export it as JPG. Pages are prepared client-side before upload.