A bill of lading data extractor that answers to your rules, not ours.
Most tools read the page, hand you a JSON and wish you luck integrating it. SunnyExtract reads the bill of lading against your operational context — your ports, your consignees, your tolerances — cross-checks it against the commercial invoice and packing list, and stops anything that does not add up in a Zero-Inbox where your own team clears it.
Example
A scanned bill of lading becomes structured shipment data — and surfaces the mismatch it was hiding
Scanned Bill of Lading — multi-page, stapled to the packing list
{
"document_type": "bill_of_lading",
"bl_number": "MEDUH2840173",
"carrier": "MSC",
"shipper": "Rotterdam Trading BV",
"consignee": "Almacenes del Sur SL",
"notify_party": "Iberia Customs Brokers SL",
"vessel_voyage": "MSC ARUSHI / 447W",
"port_of_loading": "NLRTM",
"port_of_discharge": "ESVLC",
"containers": [
{
"container_no": "MSCU7761430",
"seal_no": "ML-8842197",
"type": "40HC"
}
],
"packages": 1240,
"gross_weight_kg": 14500.5,
"freight_terms": "prepaid",
"cross_check": {
"commercial_invoice": "matched",
"packing_list": "mismatch",
"exception": "Gross weight: packing list states 14,480.00 kg, B/L states 14,500.50 kg — delta 20.5 kg, above the 5 kg tolerance for this customer",
"routed_to": "zero_inbox"
}
}
Structured output — fields mapped, cross-check run, exception routed to the Zero-Inbox
The problem
Why generic bill of lading OCR breaks in production
A bill of lading is not a form. Every shipping line lays it out differently, a good share of them arrive as a phone photo of a fax, and the fields that carry the most risk — container numbers, weights, consignee — are the ones stamps and handwriting land on. OCR reads what is on the page. It does not know what your operation expects to find there.
Every carrier has its own layout, so template-based extraction breaks the first time a new shipping line appears
Documents arrive as scans, phone photos and multi-page PDFs where one B/L is stapled to an invoice and a packing list
Container and seal numbers are among the most frequently misread fields, and the most expensive ones to get wrong
Weights and quantities disagree between the bill of lading, the commercial invoice and the packing list more often than anyone admits
A generic API cannot know your internal project codes, your consignees, or which port pairs are even plausible for this customer
When an extraction is uncertain, an API-only tool has nowhere to put the doubt — so it guesses, and a clean-looking wrong value lands in your TMS
The JSON is the easy part. The rules are the product.
Every vendor in this category can turn a bill of lading into fields. What none of them carry is your business logic: the tolerance you accept between the B/L weight and the invoice weight, the consignee that is the same customer under three spellings, the shipment that must never be posted before customs clears. We build that logic into the pipeline — and when it breaks, the document stops in front of a person instead of flowing into your systems as data that looks right.
Extracted fields
What we extract from a bill of lading
These are the fields we map most often. The schema you actually get is the one your operation needs — extraction is built per client, not picked from a dropdown.
Parties
-
Shipper
-
Consignee
-
Notify party
-
Carrier and SCAC code
Shipment
-
B/L number
-
Vessel and voyage number
-
Port of loading (POL)
-
Port of discharge (POD)
-
Place of receipt and place of delivery
-
Date and place of issue
Cargo
-
Container and seal numbers
-
Number and type of packages
-
Description of goods
-
Commodity and HS code
-
Marks and numbers
Commercial terms
-
Gross weight, net weight and measurement (CBM)
-
Freight terms (prepaid or collect)
-
Incoterms
The workflow
How the Zero-Inbox workflow runs
Three steps. The third is the one nobody else in this category sells you.
Capture and extract
The document arrives by email, API or a folder drop — PDF, scan or phone photo. It is classified (bill of lading, commercial invoice, packing list), split when several documents share one file, and the fields are extracted against the schema built for your operation. No templates, so a new carrier is not a new integration.
Apply your rules
The extraction is checked against your business logic rather than a generic plausibility test: does the gross weight agree with the packing list within the tolerance you accept, is this port pair possible for this customer, does the consignee resolve to an account you actually have, is this shipment allowed to be posted yet.
Zero-Inbox — your team clears the exception
Clean documents flow straight into your system. Anything that breaks a rule, or that the model is not confident about, stops and lands in the Zero-Inbox: one queue, the scan on one side, the extracted field on the other, and the reason it stopped written in plain words. Your operations team decides. Nothing questionable reaches your ERP quietly.
Living context
Correct it once. The rule stays.
There is no black-box retraining here, and that is the point. When your operator fixes something in the Zero-Inbox — a consignee that turns out to be an existing customer under a different spelling, a weight tolerance that was always going to be too tight — the fix is not applied to that one document and forgotten. It is kept as a rule, in your context, and it runs from the next document onwards.
A correction becomes a rule you can read, not a weight buried inside a model — you can see why the engine decided what it decided, and so can whoever audits you
The Deviation Inspector is where that context lives: consignee and supplier name mappings, project and vault routing, the tolerances you accept — your business rules, in one place, under your control
We keep the extraction prompts underneath tuned; you keep the business rules. Neither side is guessing what the other changed
The same correction never has to be made twice: from the next document on, the rule runs before the document ever reaches a person
Reconciliation
Bill of lading reconciliation, against your rules
Extraction is table stakes. The work that actually costs your team hours is the cross-check — and it is exactly the part every API-only vendor hands back to you.
Three-way matching: the bill of lading against the commercial invoice and the packing list — quantities, weights, container counts and references, compared with the tolerance your operation accepts instead of an exact-string test
Commodity bill of lading reconciliation: line items matched by description and HS code across documents that describe the same goods in different words
Third-party delivery reconciliation: carrier and forwarder paperwork matched against your own delivery records, so a discrepancy surfaces before it turns into an invoice dispute
Every mismatch becomes an exception with a reason attached, never a silent overwrite — it reaches the Zero-Inbox with both values side by side
Where this document lands
Operations that process this document
This document type is part of the wider workflows we build for the operations below.
FAQ
Frequently asked questions
What fields can your bill of lading data extractor capture?
Commonly the B/L number, shipper, consignee, notify party, carrier, vessel and voyage, port of loading and discharge, container and seal numbers, package counts, description of goods, HS code, gross and net weight, and freight terms. Because the pipeline is built per client rather than chosen from a menu, the schema you get is the one your operation actually needs — including your own internal references, project codes and account identifiers.
Do you offer out-of-the-box bill of lading reconciliation?
No, and that is deliberate. Reconciliation is where operations differ most: the tolerance you accept on a weight, which references are authoritative, what counts as the same commodity described two ways. A generic matcher either misses real discrepancies or floods you with false ones. We design the reconciliation rules with you during the workflow review and build them into your pipeline.
What happens when the scan is unreadable or a field is handwritten?
The document stops. Rather than pushing a guessed value into your TMS or ERP, the uncertain field is flagged and the document lands in the Zero-Inbox, where your team sees the scan next to the extracted data and the reason it was held. A person decides, and the corrected document continues through the pipeline.
Does the system learn from our corrections?
Yes, but not by retraining a model behind your back. A correction made in the Zero-Inbox is stored as a rule in your context — the consignee that maps to an account you already have, the tolerance that was too tight — and from the next document on, that rule runs automatically. You can read it and change it in the Deviation Inspector. That is deliberate: an operations team cannot audit a model weight, but it can audit a rule.
Can you handle bills of lading from any shipping line?
Extraction is not template-based, so a layout we have never seen does not require a new integration — the pipeline reads the document for what it is rather than matching it against a stored form. What does need setting up is your business logic: the rules, the tolerances and the systems the data flows into.
Is this just an OCR bill of lading API?
No. OCR is one input, not the product. Text recognition puts characters on the table; the value is in what happens next — classification, validation against your rules, cross-checking against the invoice and packing list, and a human-reviewed exception path. An OCR API returns a JSON and leaves the hard part with you.
Request a private workflow review
Tell us how your document workflow works today. We review every request manually and prepare demos around real operational needs.
Request private workflow review