AI Data Extraction for Shipping and Freight Documents

Bills of lading, sea waybills, booking confirmations and arrival notices for ocean; master and house air waybills, shipper's letters of instruction, cargo manifests, dangerous goods declarations and security declarations for air; and commercial invoices, pro forma invoices, packing lists, purchase orders, freight invoices and goods receipts across both modes.

Generic OCR returns the text on the page. It does not know which address block is the consignee, which of four place fields it is looking at, or which weight belongs to which container. Extraction here classifies the document first, applies a field model built for that type, reconstructs line items as rows, and then validates the result with deterministic code rather than reporting a confidence score.

Yes, and it is designed to be. Extracted values stay next to the source page so a reviewer can confirm or correct anything. Exports are generated from the corrected record, not from the raw reading — so a correction made once is reflected in every format and every downstream handoff.

Yes. Invoice lines, cargo lines, container rows and charge lines are returned as structured rows, including tables that run across page breaks and continuation sheets. This matters because everything downstream is line-level: customs classifies per line, three-way matching compares per line, duty is calculated per line.

Accuracy varies with document quality, and no honest answer is a single percentage. What the design guarantees instead is that uncertainty is visible: deterministic checks flag anything the arithmetic cannot support, the source page sits beside every value, and warnings are distinguished from contradictions so review effort goes where it matters.

Native PDFs, scans and photographs including phone images, in PDF, JPG, PNG and WebP. Multi-page documents are processed page by page. Native files give better results than a scan of a printout, but terminal photographs and faxed copies are normal inputs rather than edge cases.

Yes, for the languages the extraction layer supports, and field labels in those languages map to the same structured model. Values, party names and goods descriptions are preserved as written rather than translated, so the record matches the document a customs officer or carrier will be holding.

Typically well under a minute per page, with fields appearing progressively rather than all at the end. Long documents — multi-page packing lists, consolidation manifests, invoices with hundreds of lines — take proportionally longer because every page is read.

Yes, through batch upload or by forwarding a whole shipment email to your private intake address. Documents arriving together are grouped into a shipment record, which is what enables the cross-document comparison rather than treating each file in isolation.

Your documents are processed to produce your result and stored privately in your workspace under your control. They are not shared between accounts, and you can export or delete them at any time — deletion removes the document together with its extracted data.

Yes. Reviewed records export as structured JSON preserving the row arrays, and connector payloads carry the record into a downstream system so it does not have to be re-keyed. Excel and CSV remain available where a system takes a file rather than a feed.

No. The field models are built per document type rather than per carrier layout, which is what allows a Bill of Lading from an unfamiliar NVOCC to extract without setup. There is no template library to maintain and no rules to write when a supplier changes their invoice design.