BOM & components
How to Manage BOM Revisions in Electronics
When a BOM revision should change, how it differs from the hardware revision, how to handle substitutions, and a release checklist.
Why BOM revisions become difficult
A bill of materials starts as one file and one owner. It stays manageable for about as long as the product has one revision.
Then a part goes end-of-life. Someone approves an alternative over email. A batch is built from a list that was correct in March. Six months later a customer reports a failure and the only honest answer to "which capacitor was on that board?" is that nobody is certain.
The difficulty is not the editing. It is that a BOM has two independent clocks — its own and the board's — and most teams keep only one of them.
BOM version vs hardware revision
These are different things and conflating them is the root of most of the confusion.
| Hardware revision | BOM revision | |
|---|---|---|
| Describes | the physical board: layout, footprints, stackup | the parts list for that board |
| Changes when | copper, footprints or board outline change | a part is added, removed or substituted |
| Needs a new PCB | yes | usually no |
| Typical identifier | Rev A, Rev B, Rev C | rev 1, rev 2, rev 3 |
One board revision normally accumulates several BOM revisions over its life. That is healthy: a substitution that does not change the land pattern has no business forcing a new PCB.
The consequence is that a BOM revision only identifies something when it is stated as a pair:
BOM rev 3 for main controller Rev C
"Rev 3" alone does not say what it is a revision of.
When should a BOM revision change?
A new BOM revision is warranted when the list that will be bought or built differs from the one before it. Concretely:
a manufacturer part number changes, including a substitution; a quantity changes; a line is added or removed; a line becomes DNP, or stops being DNP; * an approved alternative is added or withdrawn.
It is not warranted for changes that do not alter what gets ordered or placed: fixing a typo in a description, reformatting, adding an internal note. Those are edits to the same revision. Issuing a revision for every keystroke makes the revision number meaningless, which is the same end state as not having one.
The test is simple: would a purchaser or an assembler do something different because of this change? If yes, it is a new revision.
Component substitutions and alternatives
Substitution is where BOM discipline is actually tested, because it usually happens under time pressure and often outside engineering.
Two things prevent most of the damage.
An approved-alternatives column. For the lines where an equivalent genuinely exists, list it in advance. A purchaser facing a shortage then has a decision already made by engineering instead of a judgement call at 5pm.
A rule for everything else. If a part is not on the approved list, the substitution needs engineering approval before it is bought, and the approval goes into the BOM — not into an email thread.
What makes a part a valid alternative is narrower than it looks. Same footprint, same electrical specification for this circuit, and same relevant qualities: temperature range, voltage rating, tolerance, dielectric. Two 100 nF 0402 capacitors are not interchangeable if one is X7R and the other Y5V and the circuit cares.
Record the reason alongside the change. "Changed C19" tells the next person nothing. "Changed C19 to GRM188R71H104KA93D — original end-of-life, same dielectric and rating" tells them whether they can trust it.
Example: Rev B to Rev C
A fictional controller board moves from Rev B to Rev C. The layout changed, so the board revision changed — and the BOM changed with it.
| Ref | Change | Why |
|---|---|---|
| J1 | 1-2112931-1 replaces the previous connector | original end-of-life; new part has a different land pattern, which is what forced the layout change |
| C19 | added | decoupling added near U1 after the Rev B review |
| R7 | removed | option-select resistor no longer needed; footprint kept and marked DNP |
| U4 | quantity 1 → 2 | second rail added |
What this produces is not one change but a set that has to move together:
BOM rev 4 for Rev C, with those four lines; Gerbers and drill regenerated — J1's land pattern is different; schematic PDF reissued — C19 and R7 changed the reference designators; assembly drawing updated — one more part to place, one deliberately empty.
If the BOM is updated and the Gerbers are not, a board gets built with a connector that does not fit. If the Gerbers are updated and the BOM is not, the right pads get the wrong part. Both failures are found at assembly, which is the most expensive place to find them.
How BOM, Gerbers and documentation should move together
The useful mental model is a release: a named, frozen set of documents that together describe one buildable state of the board.
A release contains, at minimum: the fabrication package, the BOM, the assembly data and the drawings. It carries one identifier, and every file in it belongs to that identifier. Nothing in a release is edited after it is issued — a correction produces a new release.
That last rule is the one that gets broken, and it is the one that matters. A release you can still edit is not a record of anything.
Common mistakes
Keeping the revision in the file name. bom_revC_final_v2_OK.xlsx is how teams end up with two files, similar names, different contents and no way to tell which was used.
One revision per edit. If every typo produces a revision, the number stops carrying information.
No revision at all until manufacturing. The first time anyone asks for a frozen list is usually the day it has to be sent, which is the worst moment to discover that three changes were never recorded.
Substitutions that never reach the BOM. The part is swapped, the board is built, and the list still shows the original. Every later decision is made from a document that does not describe the hardware.
Updating the BOM and not the documentation. The parts list is right and the schematic PDF next to it is from two revisions ago.
Assuming the ECAD tool is the record. It holds the current design. It does not hold what was approved, what was bought, or what shipped.
A BOM release checklist
Before a BOM goes to purchasing or assembly:
- [ ] The BOM states which board revision it belongs to.
- [ ] Every line has a manufacturer and a manufacturer part number.
- [ ] Reference designators match the schematic, with none duplicated.
- [ ] Quantities match the number of designators on each line.
- [ ] DNP lines are present and marked, not deleted.
- [ ] Footprints match the land patterns in the current layout.
- [ ] Substitutions since the last revision are listed with their reason.
- [ ] Approved alternatives are stated for the lines where they exist.
- [ ] Lifecycle status checked for the parts that matter.
- [ ] The revision identifier is in the data, not only in the file name.
- [ ] The matching Gerbers, drill files and drawings are identified.
- [ ] Someone other than the author has read it.
Where XKEMA fits
Everything above is process, and a disciplined team can run it with spreadsheets and a shared folder. Many do, for a while.
What breaks is not the discipline but the filing. A folder does not know that one of the two BOMs inside it belongs to a revision that was never built, or that the schematic PDF beside it is two revisions old. It cannot refuse to let you edit a list that was already used to buy parts, and it cannot tell you what changed between two of them.
XKEMA is built around those relationships. A bill of materials belongs to the board it describes, the board has its revisions, each version records which one came before it, and an approved version is frozen — further change means a new version, which is the point of freezing one. Two versions of a BOM can be compared row by row, and the same applies to PDF pages and Gerber geometry.
What it is not: it does not replace your ECAD, it does not buy anything, and it is not source control for ECAD project files — there are no branches and no merges.
BOM management Hardware revision control * Hardware configuration management