A subcontractor's bid arrives as a photo: a spec sheet on a tailgate, a number written across it in ballpoint, sent from a truck cab at 6:40 in the morning. Someone in the office squints at that photo and types the number into the estimate. That retyping step is where errors are born, and removing it is what document extraction does — carefully, with a human check built in, or not at all.
The paperwork that actually shows up
Construction and the trades run on documents that were never meant to be read by software. Delivery tickets on carbon paper, signed against a knee. Mill certifications that were faxed, scanned, and faxed again. A manufacturer bulletin that changed the fastener pattern last spring, photographed after a week on a dashboard, coffee ring and all. Change orders written on the back of the original scope sheet. And the bid itself, which very often is exactly what it sounds like: the sub's number scrawled over a photo of the spec sheet, because that is the fastest honest answer a person can give from a job site.
A native digital PDF — an invoice generated by a supplier's own system — extracts almost perfectly, because the text is already text underneath. The hard cases are everything else. In a contractor's office, everything else is most of the pile.
Reading and understanding are two different jobs
The first job is optical character recognition: turning pixels into characters. The second is structured extraction: deciding what those characters mean. Which string on the delivery ticket is the quantity, which is the unit price, which is the PO number, which is the date the pricing expires. These are separate problems and they fail separately. A system can read every character on a ticket correctly and still file the freight charge under materials, because nothing on the page says "this column is freight" in a way software can take for granted.
That second job is where the useful work happens. A searchable pile of scans is an archive. A quantity that lands in the quantity field of a job record is data you can compute a bid with.
Tables fail quietly, and quiet is the dangerous part
A price table that gets flattened during extraction becomes a wall of numbers with no memory of which column each one came from. The header row is orphaned from the rows it described. When that happens, the output is not garbage — garbage would get caught. The output is a plausible price attached to the wrong item. A system that reads a supplier sheet and returns $4.85 for a fitting priced at $48.50 one column over will pass a glance test every time, because $4.85 is a believable price for something. Confidently wrong beats illegible for damage done, because illegible gets retyped and confidently wrong gets bid.
The engineering answer is to treat tables as tables: keep rows and headers bound together through extraction, and refuse to emit a price that lost its header on the way through.
The confidence score is the design, not a feature
Every field the system extracts carries a score reflecting how sure the read is. A typed quantity on a clean scan scores high and flows straight into the record. A handwritten figure photographed at an angle in bad light scores low — and a low score does not get rounded up to an answer. It gets routed to a review queue, where a person sees the extracted value next to the original image and confirms or corrects it in a few seconds.
This gate exists because of errors like transposed digits. A bid of $1,840 read as $8,140 is plausible on its face; no downstream sanity check catches it, because the only thing wrong with it is that it does not match the paper. The single worst design choice in this category is a system that silently accepts every read. The review queue is not a limitation to apologize for. It is the mechanism that makes everything upstream of it trustworthy.
Where the fields go once they exist
The sub's number becomes a line in the estimate without passing through anyone's keyboard. Delivery ticket quantities reconcile against the purchase order they were supposed to fulfill, so a short shipment surfaces the week it happens instead of at job close-out. Invoice amounts land in job costing against the phase they belong to. Each of these is the same small move: a value that used to live on paper now lives in the field that a calculation reads.
What this does not fix
It cannot read what was never written. If the sub's photo carries a number and nothing else, extraction will capture the number faithfully — and it still cannot tell you whether that number includes tax, freight, or the exclusions he mentioned on the phone. Scope judgment stays with your estimator.
Handwriting is the worst case and always will be. Expect a higher share of handwritten fields to land in the review queue, and treat that as the system working.
And if your document flow is chaotic — bids in one person's texts, tickets in a glovebox, invoices in three inboxes — extraction will digitize the chaos without curing it. The collection step, getting documents to one intake point, is organizational work no software does for you.
Where to start
Pull the last ten documents someone in your office retyped. The real ones — the tailgate photos and the coffee-stained bulletin, not the cleanest examples in the drawer. That stack is the honest test: it shows what a system would read cleanly, what it would flag for review, and how much retyping time is actually on the table.