A common scene: A design is nearly complete. The CAD model is frozen, the drawings are released, and the manufacturing team asks for the bill of materials. Someone opens a spreadsheet, looks at the model, and hand-types parts and quantities into columns. It's tedious, but it's done.
Three weeks later, the designer finds a flaw in a subassembly. It takes a few minutes to fix in CAD. The change is committed. But the BOM spreadsheet sits in a folder, unseen. It still lists the old subassembly. Now the design and its parts list describe different things. Nobody realizes this until manufacturing builds the first unit and discovers a mismatch.
This happens everywhere. BOMs drift because they're born in a different system, live in a different place, and get updated by a different person on a different schedule. Even with care and good intentions, a spreadsheet BOM is a photo of the design taken once, frozen in a moment, with no automatic tie to what the design actually is anymore.
Why spreadsheet BOMs fail
Spreadsheet version control is broken in two ways: isolation and synchronization.
Isolation is the first problem. A BOM file sits in a folder somewhere, often separated from the CAD it describes. If an engineer needs to know what parts go in the bracket assembly, they open two windows: the CAD package on the left, the spreadsheet on the right, and manually cross-check them. If they've both been changed, reconciling them is detective work.
Synchronization is worse. When a CAD design changes, the BOM doesn't know. The spreadsheet doesn't get a notification. There's no automatic update, no flag, no audit trail of the mismatch. The two documents drift, and there's no way to know they're out of sync until something breaks or an audit reveals the gap.
For teams with regulated workflows, this is dangerous. Aerospace and medical device manufacturing need traceability: a clear, timestamped record of what parts went into which assemblies, and when that decision was made. A spreadsheet BOM with no history, no link to the CAD, and no change author is a traceability nightmare.
Version control that understands design
The answer is to version the BOM the same way you version the CAD. Not as a separate artifact, and not by hand. As part of the same commit.
When a designer changes the CAD model, they commit the change. That commit touches the part file, the assembly, the drawing, and the BOM. All four files move together, in one atomic action, with one timestamp and one change message. Now the BOM and the CAD are always in the same state. They can't drift because they're versioned as a unit.
OpenVault handles this naturally. You make a design change, and the BOM updates as part of the same workflow. When you sync with your team, everyone gets the model, the drawing, the rendering, and the BOM at the same revision. There's no lag, no spreadsheet living in a folder that someone forgets to update.
The history becomes automatic. Every version of the BOM is preserved, with its author, date, and the reason for the change. When a manufacturing team wants to know "what was in this assembly on October 15th?" the answer is one command away. That's the audit trail that regulated workflows need.
BOMs generated from CAD
The best BOMs aren't typed. They're extracted.
Modern CAD packages like SolidWorks, Fusion 360, and NX can generate BOMs directly from the model. The bill of materials is data embedded in the design: part numbers from properties, quantities from the assembly structure, materials from part attributes. A generated BOM is always current because it comes straight from what the model actually is.
But a generated BOM is raw. It's typically a flat list with no context, no sourcing notes, no alternate parts. That's where the spreadsheet piece is still useful: as a review layer, a place to add sourcing guidance, lead times, cost information, and engineering notes that the CAD package doesn't hold.
The workflow is: CAD generates the base BOM, engineering review enriches it with sourcing and notes, and the whole thing gets versioned together. When the CAD changes, the base BOM regenerates automatically. Engineers review the changes, update notes if needed, commit, and the parts list is current again.
Tool Crib Cloud includes a BOM editor and approval workflows that fit right into this. You generate the BOM from CAD, review and edit it in the web interface, add sourcing notes, and approve it all in one place. The approved BOM stays in version control, linked to the exact CAD revision it came from.
What version control gives you
When BOM and CAD are versioned together, several things become possible that aren't otherwise:
Traceability. You can answer "what was in this assembly at revision 4.2?" instantly. Every BOM revision is timestamped and authored. In regulated industries, that's not a nice-to-have. It's required.
Offline work. A designer working on a laptop can pull down the CAD and the BOM, make changes offline, and commit both when they reconnect. The team gets the complete, coherent change.
Branching and variants. If you're exploring a design variant, you branch. The CAD and BOM branch together. You can iterate on both, and when the variant is approved, merge it back. The main design never gets contaminated with experimental parts.
Blame and rollback. If a BOM error ships, you can see exactly when the error entered the system, who made the change, and why. You can roll back to the last good state if needed. With a spreadsheet, you're often just looking at whatever's in the file, with no way to know if it's right.
Audit readiness. Every part of the design carries a complete record. When someone asks "walk us through the design history," you have it. You don't reconstruct it from email or memory.
Start where you are
You don't need to overhaul your tools to get here. If you're using SolidWorks or Fusion, you're already generating BOMs. If you're using a spreadsheet for sourcing notes, keep it. Put both in version control together.
OpenVault handles mixed file types naturally. CAD files, spreadsheets, PDFs, text files, simulation data. Everything goes in, and large files automatically route through Git LFS. Your BOM spreadsheet sits right beside your STEP files, and they get versioned as one unit.
The payoff is straightforward: a design and its bill of materials that are always in sync, authored by real people, timestamped, and auditable. Spreadsheets living in a folder, updating on some unknown schedule, belong to the past. The parts list matches the CAD. The design history is in the commit log, ready before the audit begins.
That's what BOM version control does.