BOM management best practices for PCB projects

A bill of materials is the contract between your design and whoever builds it. If it is complete, current, and orderable, assembly is boring in the best way. If it is stale or missing part numbers, you get quote delays, wrong parts, and populated boards that do not match the schematic.

Short answer: Keep every part detail — value, footprint, manufacturer part number, distributor part number, quantity, DNP status — in the schematic as symbol fields, and regenerate the BOM from the design every time it changes. Never maintain the BOM as a separate spreadsheet. That single rule prevents almost every BOM problem.

What a good BOM contains#

A buildable BOM is more than a parts list. Each of these columns earns its place:

The value column tells a human what the part is. The manufacturer and distributor part numbers tell a machine — and a fab — exactly what to buy and place. A BOM without real part numbers is a wishlist, not a build package.

Keep the BOM in the schematic, not a spreadsheet#

The most important decision in BOM management is where the data lives. There are two options, and only one of them scales.

The wrong way: finish the schematic, export a rough parts list, then open a spreadsheet and hand-fill manufacturer and distributor part numbers. Now you have two documents that must be kept in agreement by memory and discipline.

The right way: store every part detail as a symbol field on the component in the schematic. KiCad symbols carry arbitrary fields — add MPN, LCSC, Manufacturer, and DNP right on the part. The schematic becomes the single source of truth, and the BOM is a view of it, generated on demand. There is nothing to keep in sync because there is only one place the data exists.

This is also where sourcing details belong long-term: the moment you pick a part in the schematic, record its part number on the symbol. Our guide to adding an LCSC part number to a KiCad BOM walks through the exact field setup.

Avoiding drift between schematic and BOM#

Drift is what happens when the design changes and the parts list does not. You swap a resistor value, ship the updated board, and the BOM still lists the old part — because the BOM was a separate file nobody remembered to touch.

When the BOM is generated from the schematic, drift becomes structurally impossible. Change a symbol field, regenerate, and the export reflects it immediately. The discipline shifts from "remember to update two things" to "update one thing" — the schematic — which people actually do.

A common and maddening failure mode: your part number lives in a field, but the BOM export template does not map that field to a column. The data is right there in the schematic, yet the exported file has an empty part-number column. Always confirm your export includes every field you rely on — a part number stored in a field the export drops is the same, to the assembler, as a part number that was never entered.

Handling alternates and second-sourcing#

Real production BOMs plan for a part being out of stock. An alternate (second source) is an approved substitute — a different manufacturer's equivalent that the assembler may use.

Capture alternates as additional fields on the symbol (MPN_Alt, LCSC_Alt) or in a dedicated alternates column, so they travel with the design. Passives with tight tolerances and generic logic are easy to second-source; anything with firmware, a specific pinout, or a critical spec usually is not. Marking which parts are safe to substitute — and which absolutely are not — saves a frantic email when the primary goes on a twelve-week lead time.

DNP: do-not-populate done right#

Do-not-populate parts are footprints intentionally left empty — a debug header, a depopulated resistor, an optional feature. The wrong way to handle them is to delete the part from the schematic, because then the footprint and the design intent vanish too.

Instead, flag them. KiCad has a native DNP attribute; set it, and the part stays in the schematic (and on the board) but is marked in the BOM as not populated. The assembler sees the footprint exists and knows to skip it. A DNP line in the BOM is information; a deleted part is a silent gap nobody can review.

Lifecycle and availability checks#

A perfect BOM full of obsolete parts is still unbuildable. Before a release, check that each part is active and in stock:

• Confirm no MPN is marked end-of-life or not-recommended-for-new-designs.
• Check stock and lead time on your distributor or LCSC, especially for the parts with only one source.
• Flag anything with a long lead time so it can be ordered early or second-sourced.

Doing this at design time — not when the quote comes back — is the difference between a smooth build and a two-week stall.

Version the BOM with the design#

Because the BOM is generated from the schematic, it should be versioned with the schematic, not stored off to the side. Every design revision produces a matching BOM, so you can always answer "which parts went on rev C?" by looking at rev C — never at a spreadsheet whose filename you have to trust.

This ties directly into how you hand a project off. A release that pairs the design, the manufacturing outputs, and a matching BOM is what wins repeat clients, and it is the format assemblers expect when you prepare a JLCPCB BOM and CPL.

Let the pipeline generate it#

Every practice here comes down to one habit: keep the data in the schematic and regenerate the BOM from it. That is exactly what GoForFab does — connect a KiCad project and every push runs kicad-cli to regenerate a correct BOM straight from your schematic fields, so the parts list can never drift from the design. It is free forever, and it turns "did anyone update the BOM?" into a question you never have to ask again.