Shipper and consignee blocks stay separate
Carrier, shipper, notify party, and consignee data can be extracted into named fields instead of buried inside page text.
Bills of lading combine logistics metadata, party blocks, vessel references, and dense tabular cargo details. LeapOCR helps teams turn those documents into schema-fit JSON for TMS, customs, and operations workflows while keeping markdown available for review.
Capture shipper, consignee, carrier, vessel, booking, and cargo details from BOLs.
Logistics teams usually need one object for shipment metadata and another array for cargo lines or package details.
{ "url": "https://example.com/bill-of-lading.pdf", "file_name": "bill-of-lading.pdf", "format": "structured", "instructions": "Extract shipper, consignee, carrier, vessel, booking number, and cargo line details.", "schema": { "type": "object", "properties": { "bol_number": { "type": "string" }, "shipper": { "type": "string" }, "consignee": { "type": "string" }, "cargo_lines": { "type": "array" } } }}
Why it works
The useful question is whether the shipment data lands in a clean structure for operations, customs, and tracking systems.
Carrier, shipper, notify party, and consignee data can be extracted into named fields instead of buried inside page text.
Package counts, weights, container references, and commodity details can be returned in structured arrays for downstream systems.
Markdown supports manual checks while structured output powers TMS, customs, and shipment workflows.
What you control
Bills of lading vary by carrier and lane, but the downstream fields tend to repeat.
These party blocks need to stay distinct because they drive customs, routing, and downstream operations.
Useful logistics workflows pull vessel names, booking references, and other routing metadata into named fields.
The payload should preserve cargo rows so downstream systems can use the result without reparsing the page.
Markdown gives operators a readable version of the BOL when they need to verify a shipment detail or correct an exception.
Examples
Most teams either need shipment-ready JSON for systems or a readable logistics document for human review.
This is the common pattern for logistics and freight teams pushing BOL data into TMS, customs, or internal tracking systems.
{ "bol_number": "BOL-77419", "shipper": "Harbor Parts Ltd.", "consignee": "Northwind Distribution", "carrier": "Blue Ocean Freight", "booking_number": "BK-440182", "cargo_lines": [ { "description": "Industrial bearings", "packages": 12, "gross_weight_kg": 640.0 }, { "description": "Hydraulic seals", "packages": 6, "gross_weight_kg": 88.0 } ]}
When shipment exceptions happen, operations teams still need a readable document view alongside the structured output.
# Bill of lading BOL-77419- Shipper: Harbor Parts Ltd.- Consignee: Northwind Distribution- Carrier: Blue Ocean Freight- Booking number: BK-440182## Cargo lines| Description | Packages | Gross weight (kg) || --- | ---: | ---: || Industrial bearings | 12 | 640.0 || Hydraulic seals | 6 | 88.0 |
FAQ
Straight answers for teams evaluating how this workflow fits into production.
Yes. Bill of lading workflows can return shipper, consignee, carrier, routing metadata, and cargo lines in a structured payload.
Because logistics workflows usually need shipment-ready objects with party blocks and cargo rows, not just page text that still needs to be restructured.
Yes. Markdown can remain available for manual checks while JSON powers the downstream logistics workflow.
Ready to test
Use a real freight document and check whether the result fits your TMS or customs workflow without another parsing layer.