How to automate bill of lading processing

What this automation does

Paperwork is usually the last thing standing between a delivered load and an invoice. Drivers snap photos, receivers scribble notes, scanners produce crooked PDFs, and someone in billing reads every one. This workflow does the reading.

1. Collect. Documents arrive from a shared inbox (pod@ or paperwork@), a driver mobile app or scanning app, a document folder synced from the terminal scanner, or carrier portals that email PODs.
2. Split and classify. Multi-page files are split, and each page is classified: straight bill of lading, delivery receipt or POD, packing list, lumper receipt, weight ticket, or other.
3. Extract. A vision-capable model reads the BOL number, PRO number, shipper and consignee names and addresses, PO and reference numbers, SCAC, handling units and pieces, weight, freight class or NMFC item where shown, hazmat indicator, freight terms (prepaid, collect or third party), seal number, pickup and delivery dates, and whether there is a consignee signature.
4. Read the exceptions. The model separately reports any handwritten or stamped delivery notes and classifies them: shortage, overage, damage, refused, subject to count, or none.
5. Match. Code matches the document to an open load in your TMS or ERP using reference numbers, then compares pieces and weight against the load record.
6. Release or route. Clean, signed PODs mark the load delivered, attach the image and release invoicing. Anything with a mismatch, exception or missing signature goes to the OS&D or billing queue with the reason.

When it is worth building

This is worth it when billing waits on paperwork. If your team takes days after delivery to invoice because PODs have not been reviewed, every one of those days is cash you are not collecting. It is also worth it when OS&D claims get missed because nobody noticed a damage notation until the customer short-paid.

It is not worth building if your volume is small enough that one person reviews everything in an hour a day, or if your TMS or a document capture product already reads PODs well for your document mix. Several transportation document tools exist, and some TMS platforms include capture. Try them on 100 of your worst documents before deciding.

Architecture

TMS integration varies. Some systems expose documented APIs, others need a partner agreement, customer-specific credentials or EDI (for example 214 shipment status messages). When there is no write access, the workflow can produce a daily import file instead.

How to build it

1. Gather a test set of your ugliest documents. At least 150 pages: phone photos, faxed copies, multi-page scans, the standard VICS-style BOLs your retail customers use, and the hand-filled short forms from small shippers. Label the correct values by hand.
2. Define the schema per document type. A BOL and a lumper receipt need different fields. Keep each schema strict, with null allowed for fields that are not present.
3. Build splitting and classification. Detect page boundaries and document types before extraction. One bad split causes most downstream mismatches.
4. Extract with field-level confidence. Ask the model to mark each field as read clearly, read with doubt, or not present. Doubtful reference numbers are the main cause of wrong matches.
5. Match in code. Exact match on BOL or PRO first, then PO plus consignee, then a fuzzy rule set. Compare pieces and weight within a tolerance you choose, such as a set percentage for weight.
6. Route exceptions with the image. Reviewers should see the extracted values next to the original image, with the problem highlighted, and correct in one place.
7. Run in parallel with billing for two weeks. Measure field accuracy and match rate on live documents before letting clean PODs release invoices.

What breaks in production

• Several loads in one scan. Drivers often scan a whole day’s PODs into one file. If splitting fails, one load gets another load’s signature.
• Reference numbers in the wrong box. Shippers write PO numbers where the BOL number goes. Match on every number found, not only on the field label.
• Stamps and signatures over text. Receiving stamps commonly cover piece counts. Treat a covered field as unreadable rather than letting the model infer it.
• “Subject to count” and similar notations. These are not clean deliveries even without a stated shortage. Decide with your claims team how each notation should route.
• Duplicate submissions. The same POD arrives from the driver app and the carrier portal. Deduplicate on load plus document type plus page hash.
• Model updates. Pin the model version and re-run your labeled test set before upgrading.

Timeline and cost

A single intake channel plus one TMS or billing system typically takes two to four weeks. Lumeor builds this in the range of $6,000 to $12,000, depending on the number of intake sources, document types and how the TMS integration works. Running costs are driven by page count. The same extraction approach is covered in more depth in our guide to extracting data from documents with AI, and the cost of workflow automation page breaks down what moves the price. If you also want quotes to flow into the same system, see how to automate freight quotes with AI.

How to measure success

• Days from delivery to invoice, before and after
• Share of PODs that release invoicing with no human touch
• Field accuracy on BOL number, PRO number, pieces and weight against the labeled test set
• OS&D notations caught at document receipt versus discovered at customer short-pay
• Billing staff hours spent on paperwork per week