Bill of Lading Generator: Stop Hand-Typing BOLs in Word
Build BOLs from your saved address book and product master in a click — pull addresses and items, auto-compute pieces, weight, and freight class, then let a clerk review and approve before the BOL prints and the shipment is logged.
An internal web tool where a clerk picks an order, the tool pulls the shipper and consignee addresses and the items, computes pieces/weight/freight class, drafts a standard VICS Bill of Lading PDF, the clerk reviews and approves, and the shipment is saved and the BOL emailed to the carrier and dock.
Before you start
- A Supabase account (free)
- A Vercel account (free)
- Exports you already have: a shipper/consignee address book CSV, a product catalog CSV (description, NMFC, freight class, weight per unit), and your order lines to ship
- Claude Code or any AI coding agent
The problem this kills
A truck is coming for a pickup, and somebody on your dock is hunched over a Word template typing a Bill of Lading — the shipping contract that rides with the freight and tells the carrier who's shipping, who's receiving, what's in the trailer, how much it weighs, and what freight class it is. They retype the same warehouse address for the thousandth time. They eyeball the product list and guess at the weight. They copy a freight class from last week's BOL and hope it's still right.
Then the small disasters start. A class is wrong, so the carrier reweighs-and-reclasses and bills you a surprise adjustment. The piece count doesn't match what's on the floor, so the driver refuses the pickup. The total weight doesn't add up to the line weights and nobody notices until it's a claim. A consignee address has a typo and the freight goes to the wrong dock. Every one of these is a hand-typing error that a saved address book and a product master would have prevented.
You don't need a transportation management system to fix this. You can build the BOL generator yourself, this weekend.
What you'll build
An internal web tool your shipping clerks log into. You keep your shipper and consignee addresses in a reusable address book and your products in a catalog (description, NMFC item number, freight class, weight per unit, pieces per unit). When an order is ready to ship, the clerk picks it, the tool pulls the right addresses and the order's items, and it does the math: total pieces, total weight, and the freight class for each line — and it checks that the line weights actually sum to the total and flags any mismatch before it bites you.
The tool drafts a clean, standard VICS Bill of Lading (the industry-standard layout carriers expect) as a PDF. The clerk reviews everything — classes, weights, piece counts, special instructions, accessorials — fixes anything off, and approves. Only then is the shipment saved, the BOL finalized with its BOL number, printed for the driver, and emailed to the carrier and the dock. PRO number is optional. The same BOL number can't be used twice, so you never double-ship an order.
What's inside the Implementation Plan
The downloadable plan is a single markdown file you paste into an AI coding agent. It opens by interviewing you about your own shipping process — your address-book and product fields, your real freight classes and NMFC conventions, how you number BOLs, your accessorials and special instructions, your typical and peak pickup volumes, and your messiest edge cases — and then it reads a short spec back for your thumbs-up before it builds a thing. That's the difference between a BOL shaped to your dock and a generic template you have to fight.
From there it walks the agent through the data model (address book, product catalog, orders, and the BOL itself), the importers, the BOL builder that computes pieces/weight/class, the weight-reconciliation check, the clerk review-and-approve screen, the VICS BOL PDF, and the carrier/dock email. Every step ends with a ready-to-copy prompt. There's a full "No API yet?" path: import your address book, catalog, and order lines from CSV, and export a clean BOL-data CSV in the exact columns your downstream system expects — so you never need an API to ship.
The governance it includes (this is the point)
On a shipping dock the controls are the product. The plan builds them in: a login so only your team can use it; row-level security so each organization only ever sees its own addresses, products, and shipments; a complete audit trail of who drafted, edited, approved, printed, and emailed each BOL, and when; a hard human-approval gate so no BOL is finalized, printed, or sent until a clerk reviews the classes, weights, and piece counts and signs off; and a duplicate guard on the BOL number so the same shipment can't be processed twice. The weight-reconciliation check physically flags a BOL where the line weights don't sum to the total before anyone can approve it.
Who it's for
Shipping clerks and warehouse leads who hand-type BOLs in Word and are tired of rejected pickups and surprise reclass bills. If you can explain to a new hire how you fill out a BOL and what makes a pickup get refused, you can build this — no developer required.
You've got this — open the plan, paste the first prompt, answer a few questions about how your dock actually ships, and you'll watch your first BOL fill itself out.