BOM & components
How to Create an Electronics BOM: A Practical Guide
What an electronics bill of materials is, which fields it needs, a worked example, and how to keep revisions straight when the hardware changes.
What is an electronics BOM?
A bill of materials (BOM) is the list of every part needed to build one unit of an electronic assembly. For a printed circuit board it answers three questions at once: what goes on the board, how many of each, and exactly which part — not "a 100 nF capacitor", but one specific orderable component from one specific manufacturer.
That last distinction is where most BOM trouble begins. A schematic can say "100 nF, 16 V, X7R" and be perfectly correct. A BOM that says the same thing is not yet buildable: a purchaser cannot order it and an assembler cannot place it.
What should an electronics BOM include?
A BOM that someone else can actually build from needs these columns. The names vary between teams; the information does not.
| Field | What it is | Why it matters |
|---|---|---|
| Item | Line number | Gives every line a stable handle in reviews and change notes |
| Reference designator | R1, C12, U4 | Ties the line to a position on the board and to the schematic |
| Quantity | How many per board | Drives purchasing and placement counts |
| Description / value | 100 nF 16 V X7R 0402 | What the part is, in engineering terms |
| Manufacturer | Who makes it | A part number alone is ambiguous between manufacturers |
| Manufacturer part number | The exact orderable part | The only field that identifies one physical component |
| Footprint / package | 0402, LQFP-100, SOT-23 | Must match the land pattern on the PCB |
| Mounting | SMT, through-hole, or not fitted | Tells assembly how to handle the line |
Two more fields earn their place once a product is real:
Lifecycle status — whether the manufacturer still makes the part. Useful at design review, and the first thing anyone checks before a reorder. Approved alternatives — parts the engineering team has accepted as equivalent. Without this column, a purchaser facing a shortage either stops the line or substitutes something nobody approved.
Reference designators deserve their own paragraph
A reference designator is not decoration. It is the link between three separate things: the symbol on the schematic, the footprint on the board, and the line on the BOM. When those three disagree, you get a board assembled with the right part in the wrong place, which is far more expensive to find than a part that was simply missing.
Two rules prevent most of it: a designator is used once per assembly, and it is never silently reused after a part is deleted. R7 removed in revision B should stay removed in revision C, not come back meaning something else.
Parts that are on the board but not fitted
Some lines exist in the design and are deliberately not placed during assembly: a resistor that selects an option, a test point, a footprint kept for a future variant. These are marked DNP (do not populate) or DNI (do not install) — the two terms mean the same thing and teams use one or the other.
They stay on the BOM. Deleting them loses the information that the footprint exists and was left empty on purpose, and the next person to read the board will spend an afternoon working out whether it was an oversight. Mark the line, set the quantity to zero or flag the mounting column, and say why in the description.
A BOM with a silently missing line and a BOM with a DNP line look identical to a purchaser and completely different to the person debugging the board.
Example electronics BOM
A short extract from a fictional controller board. Real BOMs run to hundreds of lines; the shape is the same.
| Item | Ref | Qty | Description | Manufacturer | MPN | Package | Mount |
|---|---|---|---|---|---|---|---|
| 1 | U1 | 1 | MCU, 32-bit, 168 MHz | STMicroelectronics | STM32F407VGT6 | LQFP-100 | SMT |
| 2 | U4 | 2 | Buck converter, 3 A | Texas Instruments | TPS62130RGTR | QFN-16 | SMT |
| 3 | C12–C18 | 7 | 100 nF 16 V X7R | Murata | GRM188R71H104KA93D | 0402 | SMT |
| 4 | L2 | 1 | Inductor, 2.2 µH | Würth Elektronik | 744314220 | 1210 | SMT |
| 5 | J1 | 1 | Connector, 10-pin | — | 1-2112931-1 | THT | Through-hole |
Notice what the table does not do. It does not say "capacitor, assorted". It does not merge two different manufacturers onto one line. And it groups C12–C18 only because those seven positions take the identical part — if one of them needed a different voltage rating, it would be its own line.
What is a BOM revision?
A BOM revision is a frozen state of the parts list, identified so that it can be referred to later without ambiguity. It records what the list contained at one moment — not what it contains now.
It is a different thing from the hardware revision. The board revision describes the physical design; the BOM revision describes the parts list for it. One board revision can accumulate several BOM revisions over its life, because a substitution does not require a new PCB.
That is why a BOM revision is only meaningful as a pair: BOM rev 3 for main controller rev C. On its own, "rev 3" does not say what it is a revision of.
How should BOM revisions be managed?
A BOM changes more often than the board it describes. A part goes end-of-life, a value is corrected, an alternative is approved. Most of those changes do not require a new PCB.
So a BOM needs a revision of its own, and it needs to say which board revision it belongs to. "BOM rev 3" on its own is not an answer; "BOM rev 3 for main controller rev C" is.
Three habits make this workable:
- Never edit a BOM that has been used to buy parts. Make a new revision.
The old one is the record of what was actually ordered.
- Record what changed and why, one line per change. "Changed J1" is not
enough; "Changed J1 to 1-2112931-1 — original end-of-life" is.
- Keep the identification in the data, not in the file name.
bom_rev_C_final_OK_v2.xlsx is how teams lose track of which one shipped.
What changes when a hardware revision changes
When a board moves from revision B to revision C, these have to be re-checked together, because changing one without the others is how a build goes wrong:
the BOM — parts added, removed, or substituted; the Gerber and drill files — the land patterns the BOM's footprints have to match; the schematic PDF — the reference designators the BOM points at; the assembly drawing — positions and orientations.
A change to any one of them can invalidate the others. A new connector footprint without a BOM change means the wrong part gets placed; a BOM change to a part in a different package without a layout change means the part does not fit.
Common BOM management mistakes
Describing a part instead of identifying it. "10k resistor" is a description. RC0603FR-0710KL is a part. A BOM needs both.
Keeping the revision in the file name. File names are not data. They get copied, renamed and duplicated, and two files with similar names and different contents is the normal end state.
Letting every project enter the same component separately. The same chip written three ways cannot be cross-checked between BOMs, so you cannot answer "which products use this part?" when it goes end-of-life.
Substituting without an approval trail. A purchaser facing a shortage will find something close. If there is no approved-alternatives column and no record of who accepted a substitution, the first time anyone learns about it is during failure analysis.
Separating the BOM from everything else. A correct BOM in a folder, next to Gerbers from a different revision, is not much better than no BOM at all.
Where this gets hard
Creating a BOM is not the difficult part. A competent engineer can produce a good one in an afternoon, and the table above is most of what it needs.
The difficult part is keeping the right BOM attached to the right hardware revision, next to the Gerbers that match it, next to the schematic PDF that uses those reference designators — and still being able to answer, two years later, which one was used to build the batch that shipped.
That is a filing problem, and folders are bad at it. A folder does not know that a PDF is the schematic of the board whose BOM sits next to it, or that one of the two BOMs in it belongs to a revision nobody built.
This is the problem XKEMA is built around: the bill of materials belongs to the board, the board has its revisions, and the documents hang from the element they actually describe.
BOM management — how the list stays attached to the product and to real component records. Hardware revision control — what happens when the next revision arrives and you need to see what changed. * How XKEMA works — the whole route, from an empty project to a frozen revision.