Stop Fighting with Drawing PDFs: Get Clean BOMs in Minutes

If you build quotes or release builds from engineering PDFs, you know the drill: getting a clean, trustworthy BOM out of a drawing should be simple, and it rarely is. Tables split across pages, headers span multiple rows, faint gridlines drop out entirely, and the fonts do things no text extractor was trained for. Somehow you always end up manually fixing the "automated" extraction.

The failure mode everyone recognizes goes like this: you spend two hours transcribing a 50-line BOM by hand, or you run the drawing through a generic extraction tool, get back something that looks like a parts list, and an hour into cleanup realize the tool grabbed the revision history instead of the parts list. It's an easy mistake for software to make. A revision table and a BOM are both grids of short strings, and a detector that only knows what tables look like has no idea which one you meant.

We built File2BOM to turn that afternoon into about five minutes: you upload the PDF and get back a table you can check against a clipped image of the source before exporting it to your system. It does one thing, finding the actual BOM in a drawing and returning it as a clean, machine-readable table, and everything about its design follows from how badly generic tools handle the messy reality of manufacturing PDFs.

Finding the right table

The pipeline starts with detection. Candidate tables get picked up across all pages, including borderless ones and tables that continue across sheets, and if your drawings always put the BOM in the same corner, you can point the tool at that region and skip the search. Then the image gets cleaned up for reading: faint gridlines are reinforced and the resolution upsampled so small text in crowded cells stays legible. When a font defeats normal text extraction, OCR kicks in, and it runs on individual cells rather than whole pages, so what comes back is the exact value in that cell instead of a page of text you have to re-parse.

Detection alone isn't enough, though, and this is where the design principle comes in: AI finds the tables, engineering rules verify them. Neural networks are genuinely good at spotting tables on a page, and they are just as genuinely unable to tell a BOM from a revision log, since both are tables. So after detection, domain checks take over. The headers get scored for the words a real BOM uses, things like "Part #" and "Qty". Multi-row headers are merged into a single coherent row, with the columns realigned underneath them. Part numbers get checked against the shapes real part numbers actually take. The revision histories and title blocks that fool generic tools get filtered out here, along with legends and anything else that merely looks tabular.

What you get back

The output is built for import. Headers land in the first row, formatting is consistent from run to run, missing values are forward-filled so a half-empty column doesn't wreck the load, and there are no spacer rows waiting to break your pipeline.

And next to the data sits a clipped image of the exact table the tool detected. That image is the trust mechanism. You can see precisely what was captured, compare it against the data field by field if you want to, and reconcile any suspicious value in seconds without opening the original PDF. In our experience that's what actually gets a tool like this adopted, because nobody imports a BOM into an ERP on an algorithm's word alone.

Different people get different things out of that. A quoting team at a contract manufacturer gets a verified BOM they can take straight into quote prep and vendor sourcing, without arguing about whether the extraction missed rows or grabbed the wrong table. A sustaining engineer at an OEM mostly cares that the table is import-safe, with coherent headers and validated part numbers, and that follow-up questions like which mating connector or crimp tool a part calls for can be answered from actual datasheets. And whoever owns the PLM or ERP pipeline gets output that doesn't drift between runs, plus a visual audit trail that holds up when compliance asks how the data got there.

What clean extraction makes possible

Once the starting table is trustworthy, downstream automation stops being wishful. Clean part numbers can be matched against multiple vendors to find price breaks and compute a real total cost, and the same numbers can be checked against on-hand inventory and last-paid costs when the decision is buy versus use what's on the shelf. For wiring harnesses it goes further: with a clean BOM grounded in the source documents, identifying mating connectors and the required crimp tools becomes something the system can pull from datasheets instead of leaning on an engineer's memory. All of it depends on the first table being right.

When it hits an edge case

Perfect automation doesn't exist. Engineering drawings are about the hardest case there is for table extraction, with dense callouts, borderless cells, odd fonts, and layouts that vary from one customer's title block to the next, and tools built for research papers or invoices fall over quickly here. So File2BOM layers its approaches. A table the primary detector misses gets caught by a backup pass, and a font the text extractor chokes on gets handed to cell-level OCR. Ambiguous candidates go through the validation rules, which decide whether the thing is actually a BOM at all.

And when something does slip through, the clipped image keeps the failure cheap: you check it against the source and fix the one cell that's wrong. Verification that takes seconds is what makes it reasonable to verify every BOM that comes through, and that habit is worth more than any accuracy number we could put in a brochure.