Your enclosure BOM might change twice between EVT and production. Your PCB BOM will change every time a distributor runs out of a 0402 capacitor.
That difference shapes everything about how you should manage an electrical BOM. A mechanical BOM is mostly parts you designed, from vendors you picked, on lead times you planned around. A PCB BOM is mostly commodity parts from a market that does not care about your build schedule.
Alternates Are the Normal State of a PCB BOM
Mechanical BOMs have alternates. A fastener from McMaster can come from a second supplier; a standard bearing has a dozen equivalents. But nobody swaps a custom machined bracket mid-production because a distributor ran dry.
Passives are different. Capacitors and resistors go out of stock constantly, and during the 2018 MLCC shortage, lead times on ordinary ceramic capacitors stretched for months. A 50-line PCBA BOM full of passives will have something out of stock at any given moment. Your CM will either call you about it or, in a turnkey arrangement, quietly find a substitute.
That makes alternates the normal state of an electrical BOM, not an exception. The question isn't whether parts on your board will get swapped. It's whether you'll know about it.
The cheapest fix is to qualify alternates before you need them. An approved alternates field on each line, populated during design, turns a shortage from a phone call into a non-event. In oroForge, a part can carry a second and third supplier, and alternates can live in custom fields on the part. If all of them are approved, your CM can move from one capacitor to another without waiting on you, and the record of what was allowed already exists. Deciding which parts deserve that treatment is its own triage; passives on power and timing circuits should be near the top of the list.
Every Swap Is a Possible Field Failure
Here is the part that makes alternates dangerous: two capacitors with the same capacitance and the same voltage rating are not the same capacitor.
They can differ in ESR, ripple current rating, temperature coefficient, DC bias derating, and rated lifetime at temperature. An X7R and a Y5V ceramic with identical values on the label behave nothing alike once the board warms up or the bias voltage climbs. An electrolytic rated for 2,000 hours at 105 °C and one rated for 10,000 hours look interchangeable on a datasheet summary line.
Power electronics is where this shows up most. Engineers who tear apart failing DC-DC converter modules report a familiar pattern: units from later production runs degrade faster than early ones, and when the modules are opened up, the output capacitor isn't the part that shipped in the first batch. Somewhere along the way it got swapped for a cheaper equivalent, the converter passed bring-up, and the failure arrived months later in the field.
Now put yourself on the other side of that. Your field returns spike. Units from one quarter fail; units from another don't. The first question anyone asks is what changed between those builds, and if the answer lives in an email thread with your CM from eight months ago, you won't find it.
That record belongs in your PLM. Every swap should carry three things: what changed, why it changed, and which revision of the BOM it landed in. In oroForge, every BOM revision is tracked and each change can carry a note explaining the reason, so "swapped C14 to the Murata part because the TDK was on 26-week lead time" sits right next to the change itself. When the returns come in, you can line up serial ranges against BOM revisions instead of guessing. A minimum viable ECO is enough structure for this; you don't need an enterprise change board to write down why a capacitor moved.
One Board, Three Part Numbers
Traceability falls apart fast if the board itself only has one identity. It needs at least three.
The bare PCB is the fabricated board: copper, solder mask, silkscreen. Its revision follows your Gerbers. The PCBA is the bare PCB plus every component placed on it; its revision follows the electrical BOM. The electronics assembly is the PCBA plus whatever makes it a working unit before it goes into the enclosure: firmware, a cable, a heatsink, a shield can.
Keeping these separate is what lets you change one without lying about the others. Your part numbers can stay dumb and sequential; what matters is that each layer gets its own number and its own revision. The rule for when each one moves:
| Change | Bare PCB rev | PCBA rev | New part number? |
|---|---|---|---|
| Same-footprint value change (10k to 12k) | No | Yes | No |
| Approved alternate used by your CM | No | No, but log it | No |
| New alternate qualified and added | No | Yes | No |
| Footprint, copper, or stackup change | Yes | Yes | Only if it's no longer interchangeable |
| Component populated or depopulated (DNP) | No | Yes | Yes, if both versions will exist |
| Firmware change | No | Depends on placement (below) | No |
The interchangeability test decides the last column. If a board built to the new revision can't drop into every product the old one went into, it's a new part, not a new revision.
Firmware Is a Line Item. Where You Put It Is a Decision.
Firmware belongs on the BOM. That argument is made in full elsewhere: it needs a version, a revision history, and a pairing to the hardware it runs on. In oroForge, firmware is a BOM line item like any other, and you can attach the code or binary directly to it. Because changes are tracked, the revision history shows when a release was just a firmware update and nothing else moved.
The harder question is where in the structure it goes. There are two reasonable answers.
Under the PCBA BOM. Firmware is a component of the programmed board, so a firmware change is a PCBA revision. This matches reality when your CM flashes the board on the line and ships you programmed PCBAs: the thing you receive is the board plus its code, and the part number should say so.
Under the electronics assembly. Firmware sits one level up, next to the PCBA rather than inside it. The PCBA revision only moves when hardware moves, and firmware releases revise the electronics assembly instead. This fits teams that flash at final assembly, or that ship firmware far more often than they change the board. Otherwise every release bumps the PCBA revision and buries the actual hardware changes under a pile of firmware ones.
The deciding question is who programs the board. If the CM does it, firmware goes under the PCBA. If you do, or if firmware moves on a weekly cadence while the board moves quarterly, it goes under the electronics assembly.
Either way, track it. A firmware change can break a product as quietly as a capacitor swap can: a new power management setting that runs a regulator harder, a timing change that only fails at temperature. If your field returns line up with a firmware release instead of a BOM change, you want that to be obvious from the record, not something you reconstruct.
What PCB BOM Software Has to Do for a Small Team
Most of what ranks for PCB BOM management is written by ECAD and component-data vendors, and it focuses on library sync and part search. Those matter. They aren't what breaks a small team's production.
Spreadsheets break first. A spreadsheet holds the current state of the BOM and nothing else; there's no record of which capacitor was on the board in March, or why it changed. That failure mode is predictable, and on an electrical BOM it arrives faster because the BOM moves faster.
Altium 365 is a good choice if your whole team works in Altium. It manages the board design well. The enclosure, the cable harness, and the firmware release usually live somewhere else, and the PCBA still has to land in a product-level BOM that your CM builds from.
What a small team actually needs is narrower than either:
- Import from the CSV your ECAD tool already exports, whether that's KiCad, Altium, or Eagle
- Multiple approved suppliers and alternates attached to each part
- A revision history that records why each change was made, not just that it happened
- Firmware as a versioned line item with the binary attached
- The PCBA as a sub-BOM inside the full product BOM, next to the enclosure and everything else
oroForge does each of those. BOM CSV exports import directly, the PCBA becomes its own sub-BOM under your top-level assembly, and every revision is kept with its reason and a one-click revert. Your CM can be added as a viewer, so they pull the current BOM and its approved alternates from the same place you edit it.
The Record Is the Product
Your PCB BOM will change more than anything else you build, and most of those changes won't feel like engineering decisions. They'll feel like purchasing. A capacitor was out of stock; something equivalent went in.
The swap is never the problem. Not knowing about it is. Attach the approved alternates, write down why each change happened, and decide where firmware lives before your first production run. When a batch of units starts failing in the field, the answer should take minutes to find. See pricing to set that record up before you need it.
