Bill of Lading BOL: Guide to Types and Fields
Learn about the bill of lading BOL, including types, key fields, and how automation simplifies shipping documentation in 2026.
A truck arrives at the dock, and the bill of lading BOL is still sitting in an email thread, a scanned PDF, or a photograph with half the fields difficult to read. Someone retypes the shipment number, consignee, packages, weight, and carrier details into an ERP. Later, finance finds a mismatch, operations finds a missing signature, and compliance has to determine which version is authoritative. This is why BOL automation requires more than OCR documents or a PDF parser. It requires document classification, structured extraction, validation, and controlled exception handling.
Why Bill of Lading Processing Still Causes Headaches
A typical manual BOL workflow looks simple from a distance. The shipper creates the document, the carrier accepts it, the warehouse uses it at pickup, and finance uses it for billing. In practice, several people re-key the same information into different systems while the freight is already moving.
That duplication creates avoidable failure points. A package count entered incorrectly can affect receiving and claims. A weight discrepancy can trigger billing questions or a freight-class dispute. A missing signature can delay proof-of-carriage review. When a document contains the wrong consignee or destination, the error can reach customs, delivery planning, and customer communication before anyone notices.
Why the document carries unusual risk
A bill of lading has three roles at once. It acts as a receipt for cargo, a contract of carriage, and, when negotiable, a document of title, as summarized in the historical and legal overview of bills of lading. That combination makes a BOL more than a shipping note. The same record supports physical handling, commercial obligations, and sometimes control over the goods.
Teams often focus on the visible labor, such as opening PDFs and copying values. The larger cost comes from investigation. Staff compare versions, request corrected documents, confirm whether a seal number applies, and decide whether an absent field is an error or irrelevant to that shipment.
Practical rule: Treat every BOL as a structured business record with legal consequences, not as an image that only needs to be read.
The structure matters whether a company processes a small monthly batch or a large freight operation. Before automating, map the fields that drive downstream actions and identify which values must be checked together. A practical reference on bill of lading for freight compliance is useful for teams documenting those operational responsibilities, while this guide to a trucking bill of lading provides additional context for road-freight workflows.
What manual entry gets wrong
Manual processing fails most often under time pressure. A clerk may capture the visible weight but miss the handling-unit type. Another may copy a BOL number correctly but associate it with the wrong shipment record. A third may approve a document because the text looks complete, even though the carrier signature is absent.
The fix isn't just hiring more reviewers. It's designing a workflow that extracts the information once, validates relationships between fields, and sends only genuine exceptions to people.
Understanding Bill of Lading Types and Legal Roles
The first automation decision is classification. A system can't validate a document properly until it knows what kind of BOL it has received and which legal role that document plays.
Start with the document type
A negotiable BOL can function as a transferable title document. It commonly appears where control of cargo may change during a trade or financing transaction, including arrangements involving a letter of credit. The workflow must protect original-document controls and identify clauses that affect endorsement or release.
A straight BOL, often called a straight bill, names the consignee directly. The carrier delivers to that named party, and the document doesn't operate as transferable title. Validation should focus on the identity and addresses of the parties, shipment details, and delivery instructions.
A seaway bill provides evidence of carriage without serving as a title document. It can suit established trading relationships where the parties don't need the control associated with an original negotiable BOL. That can simplify release, but it doesn't remove the need to verify cargo, parties, and transport information.
An electronic bill of lading, or eBL, represents the digital direction of travel. It can be issued and exchanged electronically, but its legal effect and interoperability depend on the applicable framework, platform, and participating parties.
Identify the parties before validating them
The shipper supplies or authorizes the cargo information. The carrier accepts the goods for transport and records the carriage terms. The consignee is the receiving party named for delivery. A notify party receives shipment communication and may be different from the consignee.
Those roles shouldn't be inferred from position alone. Templates vary by carrier, and labels such as “to order,” “notify,” “shipper,” or “consignee” can appear in different places. A classification layer should combine headings, clauses, document layout, and extracted values before applying field rules.
A useful processing sequence is:
- Classify the BOL. Detect whether the document is negotiable, a seaway bill, electronic, house, or master format where applicable.
- Map the parties. Separate shipper, carrier, consignee, notify party, and bill-to information.
- Apply relevant rules. Validate only the fields required for that type and shipment context.
For a concise explanation of the document's role in shipping, see this guide to what a bill of lading is in shipping. The important operational point is simple: classification comes before validation.
Key Fields and Validation Rules for Accurate Extraction
A reliable bill of lading BOL extraction workflow starts with a field model. ISO 5909 organizes an electronic B/L into eight information groups: basic information, parties, external references, transportation information, declared value, general goods description, goods item details, and freight or charges. That structure is useful because it turns a visually inconsistent document into discrete validation areas for customs, freight rating, and trade-finance workflows. The ISO 5909 electronic B/L model provides the standards context.
Separate required fields from conditional fields
The GS1 guideline distinguishes fields that should be present on a BOL from fields that depend on the shipment. Core mandatory information includes ship-from and ship-to details, the BOL number, carrier name, SCAC, terms, package count, weight, commodity description, trailer-loaded and counted indicators, and signatures. The GS1 US bill of lading guideline also identifies conditional information such as bill-to, PRO number, seal number, and master-BOL indicators.
| Field Category | Mandatory Fields | Conditional Fields |
|---|---|---|
| Parties and identity | Ship-from and ship-to names, addresses and ZIP codes, BOL number, carrier name, SCAC | Bill-to party, notify party, master-BOL parties |
| Cargo and handling | Package count, weight, commodity description, pallets or slips indicator, handling-unit quantity and type | Seal number, special handling details, shipment-specific references |
| Transport and acceptance | Terms, trailer-loaded and counted indicator, shipper signature, carrier signature | PRO number, booking or linked transport references |
A flat template creates two opposite problems. It flags a legitimate blank as an error, or it treats a missing required value as harmless because the field exists somewhere in the schema. The extraction system should classify shipment context first, then decide whether each field is mandatory, conditional, or optional.
Build rules around relationships
Field presence isn't enough. A strong workflow checks whether values agree:
- Weight checks: Under Carmack Amendment claim practice, declared weight should match actual weight within 5%, unless dispute language records a discrepancy. The practical explanation of these enforceable BOL elements is available in this Carmack-related BOL preparation guidance.
- Count checks: Package count should align with the listed handling units and pallet or slip indicators.
- Identity checks: The SCAC should correspond to the carrier identified on the document.
- Signature checks: Missing shipper or carrier signatures should create an exception, not disappear in an export.
- Description checks: Commodity details should be sufficiently complete for the relevant freight and compliance workflow.
The right output isn't just extracted text. It's a record containing values, confidence, validation status, and a traceable reason for any exception. Teams working with older templates can also use a BOL Word format guide when standardizing source documents.
Why Traditional OCR Fails at Bill of Lading Extraction
Basic OCR solves one narrow problem: it converts pixels into characters. That helps when a user needs to search a scan, but it doesn't tell the system whether a number is a BOL number, a seal number, a weight, or a reference printed beside the wrong label.
The distinction matters because BOL layouts are not uniform. Carrier forms, shipper forms, house bills, master bills, scanned copies, and photographs can place similar values in different regions. A text-only OCR engine may extract every visible word and still fail to create a dependable shipment record.
Where text capture breaks down
Traditional OCR usually doesn't understand conditionality. If a seaway bill doesn't contain a field used on a negotiable BOL, a rigid template may flag a false error. The opposite failure is more dangerous. A system may capture a declared weight without checking it against actual weight, freight class, or a related handling-unit count.
Consider two processing outcomes. In the first, the software extracts a weight variance and accepts it because no rule engine exists. In the second, it identifies the discrepancy, records the source values, and routes the document for review. Both systems can claim to have “read” the BOL. Only the second supports operational control.
OCR versus intelligent extraction
| Capability | Basic OCR | AI document extraction |
|---|---|---|
| Text recognition | Captures visible characters | Captures characters and their document meaning |
| Field mapping | Depends on fixed positions or templates | Maps labels, context, and layout to a schema |
| Document types | Often requires separate templates | Classifies BOL variants before extraction |
| Validation | Usually external or absent | Applies business rules and cross-field checks |
| Exceptions | Produces a file for manual review | Routes specific uncertainty or rule failures |
Modern intelligent document processing combines OCR, classification, field mapping, confidence scoring, and validation. It can recognize that a value belongs to the carrier section, distinguish a seal number from a shipment reference, and apply different rules based on document type.
That doesn't eliminate human judgment. It changes where people spend it. Reviewers should investigate ambiguous or contradictory records, not retype every legible field from every document.
Building Automated BOL Workflows with AI Extraction
A practical automated BOL workflow should make each decision visible. The system receives a PDF, scan, image, or mixed document set, identifies the document, extracts the relevant fields, validates them, and creates an exception only when a person needs to intervene.
Use five controlled stages
- Upload and normalize. Accept native PDFs, scanned PDFs, phone images, and multi-page files. Split mixed packets when a single upload contains a BOL, delivery receipt, invoice, or customs document.
- Classify the document. Detect the BOL type and shipment context before choosing the schema.
- Extract structured fields. Return values such as BOL number, shipper, consignee, carrier, SCAC, ports or locations, cargo description, containers, packages, weight, terms, and signatures.
- Validate and score. Apply required-field rules, weight tolerance checks, SCAC checks, signature checks, and cross-field consistency rules.
- Route exceptions. Send low-confidence fields, missing signatures, conflicting counts, or failed business rules to a reviewer with the source evidence attached.
The JSON output should preserve both the result and the reasoning trail. A representative structure looks like this:
{
"document_type": "bill_of_lading",
"classification": {
"variant": "non_negotiable",
"confidence": 0.98
},
"fields": {
"bol_number": {
"value": "BOL-EXAMPLE",
"confidence": 0.99
},
"shipper": {
"value": "Example Shipper",
"confidence": 0.97
},
"consignee": {
"value": "Example Consignee",
"confidence": 0.96
},
"package_count": {
"value": 24,
"confidence": 0.95
},
"declared_weight": {
"value": "Example value",
"confidence": 0.94
}
},
"validation": {
"status": "review",
"failed_rules": [
"carrier_signature_missing"
]
},
"traceability": {
"source_page": 1,
"source_regions_available": true
}
}
Configure rules for the real operation
Don't begin with every possible BOL field. Start with the values that drive freight release, billing, customs, claims, or ERP updates. Then add rules that reflect how your organization works.
A SCAC validation rule can compare the extracted carrier identifier with an approved carrier directory. A count rule can compare package quantity with handling-unit quantity. A signature rule can distinguish a visible signature from a printed name. A weight rule can compare declared and measured values and send a discrepancy to review instead of overwriting either one.
Platforms such as Matil.ai combine OCR, classification, validation, and workflow automation through an API, with pre-trained models, configurable structures, custom models, JSON output, traceability, and support for PDFs, images, and multi-page documents. Its stated capabilities include accuracy above 99% in multiple use cases, plus GDPR, ISO 27001, AICPA SOC, and zero-data-retention controls, as described in the publisher information. The important evaluation point isn't the feature list alone. Test the platform on your own carrier formats and measure extraction quality at field level.
For integration, an ERP or transport-management system can submit documents through an API, receive structured results, and use webhook notifications for exceptions. Batch processing suits backlogs and high-volume document intake, while synchronous calls can support dock or customer-service workflows. The review screen should show the original field location, extracted value, confidence, and failed rule so an operator can correct the record without searching through the entire file.
The following video can help technical and operations teams visualize document-processing automation in practice:
The Electronic Bill of Lading Reality Check
The paper-to-digital transition is real, but it isn't complete. Industry survey data reported by the International Chamber of Commerce shows overall eBL adoption rising from 33.0% in 2022 to 49.2% in 2024, with dual-format users increasing from 28.0% to 41.7% over the same period, according to the ICC eBL adoption survey. Those figures describe electronic use in some form, not a world where every shipment runs through one interoperable digital process.
Containerized-trade estimates show the gap more clearly. One industry estimate placed usage at about 5% in early 2024, up from 1.2% in 2021, while some 2025 estimates place worldwide electronic issuance around 11%, as reported in industry coverage of the transition. A separate commitment from DCSA member carriers targets full standardized adoption by 2030, but that is a future objective, not the current operating environment.
Why hybrid processing is the practical choice
Legal recognition differs across jurisdictions. Carriers and platforms may support different exchange methods. One trading partner may issue an electronic record while another still sends a scanned paper copy by email. Even on a regular lane such as US to Europe sea freight, the document workflow can vary by carrier, forwarder, consignee, and financing arrangement.
Interoperability is improving. The DCSA's Bill of Lading 3.0 standard added digital signatures and more than 190 attributes to support EU Import Control System 2 requirements, while common standards are being used in interoperable eBL pilots, as described by Breakbulk's coverage of electronic BOL adoption. Standards can reduce ambiguity, but they don't immediately change every party's legal process or software.
Your extraction layer therefore needs to handle three inputs at once:
- Paper-origin documents: scanned copies and photographs with variable image quality.
- Hybrid records: electronic forms combined with signed scans, attachments, or delivery evidence.
- Native digital documents: structured or semi-structured eBL files that still require validation and routing.
The bottleneck isn't only technical feasibility. It's the coordination of carriers, shippers, banks, customs authorities, platforms, and legal frameworks. An automation strategy that supports today's hybrid reality will be more useful than one designed only for a fully digital future.
Next Steps for Automating Your BOL Processing
Start with an operational baseline. Review the document formats you receive, the fields people re-key, the rules that cause disputes, and the points where signatures or approvals go missing. Record processing time, exception categories, and correction effort before selecting a platform. Without that baseline, a demo can look impressive while hiding the work your team still performs outside the system.
Use a focused evaluation checklist
- Accuracy: Look for accuracy above 99% in the relevant use case, and verify the result on your own BOL layouts rather than accepting a generic benchmark.
- Format coverage: Test native PDFs, scans, images, multi-page files, mixed document packets, and hybrid paper-electronic workflows.
- Rule flexibility: Confirm that you can configure mandatory and conditional fields, weight tolerances, signature checks, carrier validation, and cross-field consistency.
- Integration: Require an API, structured JSON output, traceability, and a clear method for exception webhooks or queue updates.
- Security: Review GDPR, ISO 27001, SOC controls, retention policy, access management, and audit requirements before production use.
A sensible rollout starts with one shipment type or carrier group. Configure the required fields, define what happens when a rule fails, and connect the results to the system that needs them, such as a TMS, ERP, claims platform, or finance queue. Keep human review for ambiguous cases and use reviewer corrections to refine rules and source handling.
Expect ongoing maintenance. Carrier formats evolve, new clauses appear, and the distinction between a missing field and an irrelevant field can change with shipment context. The goal isn't to remove every person from the process. It's to reserve human attention for exceptions while the system handles repeatable extraction, classification, validation, and routing.
Matil combines OCR, document classification, field validation, and workflow automation for BOL PDFs, scans, images, and mixed logistics documents, with API-based integration and enterprise controls including GDPR, ISO 27001, SOC, and zero data retention. If you're ready to test a hybrid BOL workflow against your own documents, visit Matil and evaluate the extraction and validation process with a focused pilot.
