Bills of lading are among the most common documents in logistics and supply chain operations. They're also consistently difficult for generic OCR tools to parse accurately. Here's why.
The carrier-specific layout problem
Unlike invoices, which have moved toward common conventions for field positions (total in bottom-right, vendor in upper-left), bills of lading have no standard layout. FedEx BOLs look fundamentally different from UPS BOLs, which look different from freight carrier BOLs. The shipper name appears at different positions, the description of goods section uses different table structures, and the weight and count fields can appear in several different locations depending on the carrier template version.
Generic OCR returns the full text of the document. Without knowing the carrier's layout, there's no reliable way to parse which text corresponds to which field from the raw character output alone.
The table structure problem
Most BOLs include a commodities table listing each shipment item with its description, weight, count, and freight class. These tables use non-standard column widths that vary by carrier, and some BOLs have the table columns printed as lines while others use whitespace alignment.
Generic OCR reads text linearly. When columns are whitespace-aligned rather than box-delimited, the OCR output often merges content from adjacent columns or splits it in unexpected ways. A description field that wraps to a second line in a narrow column gets mixed with the weight field on the right when the output is linearized.
The handwritten annotation problem
About 15-20% of BOLs in our early-access logistics use cases have handwritten content: driver signature fields, inspection notations, weight adjustments written in at the dock. Standard OCR accuracy on handwritten text is substantially lower than on printed text. If the handwritten content overwrites or annotates a printed field, the extract of that field becomes unreliable.
How Parseloom handles BOLs differently
Parseloom's BOL templates are carrier-specific. We train separate models for major carrier layouts, so the extraction engine knows where to look for the shipper fields on a FedEx BOL versus a freight carrier BOL. The table parser handles both box-delimited and whitespace-aligned table structures explicitly. For handwritten content in key numeric fields (weight, count), the confidence score reflects the lower reliability so your integration can flag those for review.
We don't claim perfect accuracy on all BOL types. BOLs with poor scan quality, unusual carrier templates, or heavy handwritten annotations will have lower confidence scores than clean print-based documents. The confidence system exists precisely for this reason.