PCB data management
BOM version control: keep the parts list matched to the PCB revision.
BOM version control prevents a common hardware failure: the board is one revision, the BOM is another, the firmware assumes a third, and production discovers the mismatch only after money has been spent.
Direct answer: how to version a PCB BOM
Version a PCB BOM by tying it to the hardware revision and release package. Use names like `Product_HW-R2_BOM_2026-06-06.csv`. Change the BOM version whenever the PCB revision, footprint, value, MPN, approved alternate, DNP status, supplier-critical part, or manufacturing release changes. Keep old BOMs archived and marked as superseded.
When should a BOM version change?
| Change | New BOM version? | Reason |
|---|---|---|
| PCB revision changes | Yes | Footprints, designators, values, connectors, or assembly state may change. |
| Component MPN changes | Yes | Purchase and assembly need traceability for the exact approved part. |
| Approved alternate added | Yes | Alternates affect sourcing, assembly risk, and future support. |
| DNP status changes | Yes | Assembly output changes even if the PCB file does not. |
| Supplier SKU changes only | Maybe | If the same MPN is sourced through another supplier, record it but separate commercial change from engineering change. |
| Price changes | No engineering version | Track cost separately unless the approved component changes. |
BOM naming examples
Your BOM filename should make the matching hardware revision obvious. If someone has to open the file to guess what board it belongs to, the name is weak.
Good:
SmartRelay_HW-R1_BOM_2026-06-06.csv
SmartRelay_HW-R2_BOM_2026-07-18.xlsx
SmartRelay_HW-R2_Production_BOM_2026-08-01.csv
Bad:
BOM.xlsx
BOM-final.xlsx
BOM-latest-new.csv
Client-purchase-this-one.xlsx
Lightweight BOM version control workflow
This process is enough for most freelancers, consultants, and small electronics teams before they move into full PDM.
Create the BOM for a specific hardware revision, not as a floating parts list.
Check regulators, connectors, ICs, sensors, RF parts, and parts with footprint or firmware impact.
Record exactly which alternates are allowed and what must match.
Store the BOM with Gerbers, drills, PnP, assembly notes, and release notes.
Common BOM version control mistakes
| Mistake | Better rule |
|---|---|
| One BOM used for all board revisions. | One approved BOM per hardware revision or release package. |
| Alternates approved through chat only. | Record alternates in the BOM or PDM system. |
| Purchase edits the BOM silently. | Separate purchasing notes from engineering-approved BOM changes. |
| DNP parts are unclear. | Use a dedicated DNP status column and assembly notes. |
| BOM not stored with Gerbers. | Freeze BOM inside the manufacturing release package. |
When BOM version control needs software
Manual BOM version control works while one person owns engineering and purchase. It becomes risky when multiple people can change parts, approve alternates, order components, or release production builds.
Electronics PDM turns BOM version control into a workflow.
PCBVault Electronics PDM is being planned to connect BOM versions, approved components, alternates, ECOs, firmware links, and manufacturing release history.
FAQ
What is BOM version control?
It is the process of tracking BOM changes across PCB revisions, MPN changes, alternates, DNP status, suppliers, firmware compatibility, and manufacturing releases.
Should a BOM version match the PCB revision?
Yes. The BOM should clearly show the hardware revision or release package it belongs to.
Can price changes create a new BOM version?
Not usually as an engineering version. Price changes should be tracked commercially unless the approved component itself changes.
What is the biggest BOM versioning risk?
The biggest risk is purchase or assembly using a BOM that does not match the PCB revision and Gerber package.