How to Match Construction Material BOLs to POs
for Site Receiving

When You Sign the BOL, You Accept the Goods

The legal framework around construction material receiving is specific and unforgiving — and most people on site don't realize it applies until there's a dispute.

UCC Article 2 §2-606 defines acceptance of goods. It happens when the buyer "after a reasonable opportunity to inspect the goods, signifies to the seller that the goods are conforming or that he will take or retain them in spite of their non-conformity." That signature on the delivery ticket counts. Under §2-602, a buyer who wants to reject non-conforming goods must do so "within a reasonable time after delivery" and must "seasonably notify the seller." For a construction superintendent, "reasonable time" means before the truck leaves the gate. Once the driver is gone and the BOL is signed clean, proving a shortfall that wasn't noted at delivery is a steep uphill battle.

On the construction contract side, AIA Document A201-2017 §3.3.3 — the General Conditions used in most commercial construction contracts in the U.S. — requires the contractor to "be responsible for inspection of portions of Work already performed to determine that such portions are in proper condition to receive subsequent Work." This obligation flows downstream: the GC is contractually required to inspect delivered materials, and failing to catch a delivery shortfall that later causes a schedule delay doesn't shift the liability to the supplier.

This is the structural reason why the receiving step in construction is categorically different from warehouse receiving in logistics. In a warehouse, a miscount gets caught at the next cycle count. On a construction site, 20 missing studs discovered on framing day means a crew is idle, a crane is being billed, and a schedule milestone is sliding. For a full breakdown of the BOL data extraction landscape — including how different BOL types (straight, ocean, multimodal) structure their data — see our complete guide to BOL data extraction.

Forty Suppliers, Forty BOL Formats — and None of Them Match Your PO

A mid-size commercial GC running five active projects might receive material deliveries from 40 different suppliers in a single month. Each supplier generates delivery documentation in its own format:

• The lumber yard sends a handwritten carbon-copy delivery ticket — supplier name scrawled at the top, item descriptions abbreviated ("2×6 #2 SPF 16'"), quantities penciled in by the yard hand who loaded the truck
• The concrete batch plant generates a system-printed ticket with mix design specs, slump, volume in cubic yards, batch time, and truck number — fields a lumber yard ticket doesn't have
• The rebar fabricator emails a PDF with 14 line items of #4, #5, and #6 bar, each tied to a different pour sequence, with heat numbers and mill cert references
• The MEP distributor prints a packing slip from their ERP — SKU codes, manufacturer part numbers, unit of measure inconsistent with how you order (they ship by the box, you order by the foot)
• The drywall supplier drops off 80 sheets with a delivery note that lists "Drywall 4×8 5/8"" and a quantity — no PO number, no job reference

Each of these documents is functionally a bill of lading — it records what was delivered, by whom, to which job site. But the field layout, terminology, and data structure are different on every single one. A template-based extraction tool that needs a zonal definition for each supplier's document format would require 40 templates to be built and maintained — and the moment the lumber yard changes its ticket format or a new supplier comes on board, another template is needed.

This is where the extraction approach matters. Traditional OCR and template-based tools locate data by position — "the quantity field is in the top-right quadrant, 3 inches from the edge." Change the layout, break the template. Semantic extraction — where the AI locates "Quantity" by understanding what the field means, not where it sits — handles all 40 formats with a single set of column definitions. The distinction between these two approaches is explained in detail in our guide on what BOL data extraction is and how it differs from basic OCR.

The format problem compounds at month-end. The project accountant isn't processing BOLs one at a time as they arrive — they're processing 50 to 150 delivery tickets that accumulated over the month, all converging in the three days before the draw deadline. At that point, format diversity isn't just an extraction challenge. It's a throughput bottleneck.

Building the Columns That Turn a BOL into a PO Match

The output you need from a construction material BOL isn't a verbatim transcription of the delivery ticket. It's a structured row that answers five questions accounting needs before the supplier invoice gets paid:

1. Did we order this? (PO Number match)
2. What exactly is it? (Material Description → CSI MasterFormat code)
3. How much did we order vs. how much arrived? (Quantity comparison)
4. Which job does this belong to? (Job Number / Cost Code)
5. Is there a discrepancy that needs action? (Flag for AP review)

Here's the column design that gets you from a photograph of a delivery ticket to a PO-matching-ready spreadsheet row. ImageToTable.ai works by Custom Column Extraction — you define the columns you want, and the AI locates the corresponding values on each document by understanding what the field means semantically, regardless of where it appears on the page or how the supplier labeled it:

The Computed Column approach is what shifts this from "data entry" to "decision support." Instead of a superintendent or project engineer manually subtracting PO quantity from BOL quantity for every line item on every delivery, the AI does it during extraction. A negative number in the Discrepancy column is an instant visual signal — that line item needs attention before the invoice gets paid. The computed column feature works by defining the calculation logic in the column definition itself; the AI reads the document, extracts the source values, and outputs the computed result in a single pass. For more on how this works across batch construction procurement workflows, see our guide on batch processing construction material POs for job costing.

Workflow: From Truck Gate to PO-Matched Spreadsheet

Here is the end-to-end flow for a typical construction receiving scenario — a superintendent at the gate with a truckload of materials, a paper BOL from the driver, and a PO that needs to be verified before the driver leaves.

Why Real-Time Discrepancy Detection Changes the Economics

The difference between catching a delivery shortfall at the gate and catching it during month-end close is measured in thousands of dollars per incident — and in construction, those incidents are not rare.

Industry data shows that 27% of vendor invoices contain errors, and 13% of delivered construction materials go directly to waste without ever being used. On a typical commercial project where materials represent 50–70% of total project costs, these error rates translate to real money. A $500,000 material package with a 3% invoice error rate that slips through matching represents $15,000 in overpayments — on a single project. For a GC running eight projects with net margins in the 2–5% range, catching these discrepancies isn't optimization. It's margin protection.

The workflow described above shifts the detection point from the accounting department — three weeks after delivery — to the superintendent at the gate, with the delivery still on the truck. A Discrepancy column that shows "-20" on the 2×6 line while the driver is still onsite means the superintendent can walk back to the truck, count the stack, and either find the missing 20 pieces or note the shortfall on the BOL before signing. That notation on the signed BOL is the difference between a successful freight claim and an unrecoverable loss.

For construction teams already tracking POs digitally — whether through Procore's Commitments module, Sage 300 CRE's purchasing workflow, or a spreadsheet — the extracted BOL data slots directly into the existing cost control process. The BOL extraction doesn't replace the ERP. It feeds it. For a detailed walkthrough of the extraction mechanics across BOL types and carrier formats, our guide on extracting bill of lading data to Excel covers the broader BOL extraction workflow.

The Handwritten BOL Reality: What Works and What Needs a Human Eye

No honest discussion of construction material BOL extraction can skip the hardest case: the handwritten delivery ticket. In logistics and freight forwarding, most BOLs are typed or system-generated. In construction, the lumber yard still runs on carbon paper and a clipboard. The concrete batch plant operator scribbles the slump and volume by hand. The small roofing supplier writes the square count on a tear-off pad.

AI extraction handles handwritten text better than traditional OCR — because it reads handwriting the way a human does, by recognizing letter shapes in context rather than matching pixel patterns. A clearly written "200 pcs 2×6×16'" on a lumber ticket will extract reliably. But handwriting quality varies dramatically. A rushed scrawl in ballpoint pen on a rain-spotted carbon copy is at the edge of what any system can reliably read — and it's worth being straightforward about this.

The practical workflow for handwritten BOLs: the superintendent photographs the ticket, the AI extracts what it can with confidence scores, and low-confidence fields (highlighted in the output) get a quick manual correction. For a delivery with 12 line items, this might mean reviewing 2–3 fields instead of typing all 12. The system gets better at each supplier's handwriting over time as the AI learns the patterns of that specific supplier's ticket format.

From Receiving Log to 3-Way Match: Closing the Loop with Accounting

The BOL data extracted at the gate doesn't live in isolation. It's the third leg of the three-way matching triangle that determines whether a supplier invoice gets paid.

Three-way matching in construction AP compares: (1) the Purchase Order — what the GC committed to buy, at what price; (2) the Receiving Document — what actually arrived on site, confirmed by the superintendent's signed BOL; and (3) the Supplier Invoice — what the supplier is asking to be paid. If all three match, the invoice is approved for payment. If any leg disagrees — wrong quantity, wrong price, wrong material — the invoice is flagged for investigation.

In most construction companies today, Step 2 is the bottleneck. The PO exists in the system. The invoice arrives in the mail or by email. But the receiving document — the superintendent's signed BOL with quantity verification — lives on a piece of paper in a folder in the job trailer. The project accountant spends hours each month physically retrieving these BOLs, matching them to POs by hand, and entering the data before the three-way comparison can even begin.

The BOL extraction workflow described above eliminates this bottleneck. When the superintendent photographs the delivery ticket at the gate, that data is already structured and ready for export. By the time the supplier's invoice arrives — often weeks later — the receiving record is already in the spreadsheet, matched to the PO, with discrepancies flagged. Three-way matching becomes a review step, not a data-entry project.

For teams using construction ERP systems like Procore, Sage 300 CRE, or Viewpoint, the extracted BOL data can be imported into the system's receiving module — creating a digital goods receipt that ties directly to the commitment (PO) record. Procore's Commitments tool, for example, tracks every PO line item against received quantities, and a digital BOL extraction feed lets the system auto-populate the "Received" column without manual keying. Sage 300 CRE's purchasing module supports the same workflow through its goods receipt entry — and an upstream extraction layer means the entry is populated from the BOL photo, not from a keyboard.

Frequently Asked Questions

Does this work with handwritten delivery tickets from lumber yards?

Yes — on legible handwriting. The AI reads handwritten text by understanding letter shapes in context, not by pixel-matching templates. A clearly written delivery ticket will extract reliably. Carbon copies and heavily degraded handwriting will require manual review of low-confidence fields (typically 2–5 fields out of 30+). The system flags these automatically so you're not hunting for errors.

What if the supplier's BOL doesn't include a PO number?

This is common. In that case, the PO Number field in the extraction output will be blank — and it becomes a manual fill. However, if you've set up inference rules (Supplier → Job Number), the job number will still be populated, which narrows down which PO the delivery belongs to. For suppliers who consistently omit the PO number, a process change (requiring the PO number on every delivery ticket) solves this at the source.

Can the system handle different units of measure across suppliers?

The AI extracts whatever unit of measure appears on the BOL — pieces, board-feet, cubic yards, linear feet, tons. It does not automatically convert between units (board-feet to pieces, for example). If you need unit conversion, set up a Computed Column with the conversion formula — for example, Quantity in Pieces (board-feet ÷ 2.67) for 2×6 lumber — and the AI will perform the math during extraction.

How long does it take to process a batch of BOLs?

Each BOL takes approximately 5–10 seconds to process. A batch of 20 BOLs from 20 different suppliers with 20 different formats processes concurrently and completes in roughly the same time as a single document — well under a minute for the full batch. The extracted Excel file is ready for download immediately after processing.

Can I export directly into Procore or Sage 300 CRE?

The extraction tool outputs to Excel (XLSX), CSV, and Google Sheets. From Excel, data can be imported into Procore's Commitments module (via CSV import) or Sage 300 CRE's goods receipt entry. Direct API integration with construction ERPs is not currently available — the workflow is extract → Excel → import. For Google Sheets users, the Google Sheets Add-on provides direct-to-sheet extraction without the intermediate Excel step.

What's the accuracy like on carbon copies or rain-damaged tickets?

Accuracy decreases proportionally to document quality. A clean, flat, well-lit photo of a printed BOL achieves the highest accuracy. Carbon copies (faint text, blue ink on thin paper) and water-damaged documents will have lower confidence scores on affected fields. The system highlights low-confidence extractions so you can review them specifically — rather than proofreading the entire output. For critical deliveries where document quality is degraded, it's faster to extract what the AI can read confidently and manually fill the flagged fields than to type the entire document from scratch.