10 Bill of Materials Review Mistakes That Cause Quality, Cost, and Supply Chain Problems

Every manufacturing company has a BOM review process. The question is what that process actually catches — and what still slips through.

I have been thinking about this problem for a while, and the more I look at it, the more I think the phrase “BOM review” is doing too much work. It covers everything from a five-minute scan of a spreadsheet to a formal multi-team gate that takes two weeks. Most companies land somewhere in between, closer to the informal end than they would like to admit. An experienced engineer looks it over. Someone in procurement asks a question. A manager signs off. The BOM gets released.

This works until it doesn’t. And when it stops working, the cost is never just the original mistake. It is the purchasing delay, the production shortage, the quality escape, the compliance gap that shows up during customer delivery or certification. Before release, a missing manufacturer part number is a data issue. After release, it becomes a chain of problems.

Here are ten BOM review mistakes I see most often — and a question at the end about how your team actually handles this process today.

1. Part Number Errors: Missing, Duplicate, or Unfinished Identifiers

Part numbers define identity. If a part does not have a valid, unique, approved number, everything downstream becomes unstable. Procurement does not know what to buy. Manufacturing does not know what to build. ERP cannot process the item. This sounds obvious, but it still happens constantly — temporary numbers that never get finalized, duplicates from different teams using different logic, vendor numbers used in place of internal item numbers.

The failure is not usually carelessness. It is that the BOM review process has no explicit check for it. Nobody is asked to verify part number completeness before release.

2. Incorrect Quantities and Units of Measure in the BOM

One bracket instead of two. Ten screws instead of twelve. A cable length in inches when the supplier quotes in millimeters. These errors are easy to miss because the BOM looks complete — every field is filled in, nothing is obviously wrong. The mistake only becomes visible when materials are ordered, kits are pulled, or the first build starts.

Units of measure compound the problem. Engineering thinks in one unit, suppliers quote in another, ERP requires a third. If the BOM does not explicitly define units and the review process does not check them, production planning and costing become unreliable without anyone knowing why.

3. BOM Not Synchronized with CAD Files and Engineering Drawings

Many BOM problems are not caused by missing data. They are caused by inconsistent data across artifacts that were never compared directly.

The CAD assembly says one thing. The drawing was updated last week but the BOM still references the previous revision. The spreadsheet was manually edited after the last CAD export. A supplier quote was based on a version from two months ago.

When you look at each artifact separately, everything appears correct. The problem only surfaces when you put them side by side. A BOM is not just a list of parts — it is supposed to reflect CAD structure, drawings, specifications, and change history simultaneously. If those are out of sync at release, you are releasing a product that exists differently in different systems.

4. Missing Manufacturer Part Numbers and Supplier Sourcing Data

A BOM can be technically correct and still not be buyable.

Engineering defines the right component. But procurement needs manufacturer part numbers, approved vendor lists, sourcing status, lead time, and purchasing readiness. If that information is missing, purchasing has to chase it down after release — searching for suppliers, validating components, asking engineering for clarification, creating last-minute substitutions under time pressure.

This is especially common at the EBOM-to-MBOM transition. Engineering considers the design finished. Supply chain is not consulted until procurement discovers the gaps.

5. Obsolete, Single-Source, and Long-Lead Components Not Flagged

Some BOMs are complete but fragile. The part exists. The number is right. But the component is obsolete, end-of-life, single-sourced with a six-month lead time, or exposed to supply chain risk that nobody reviewed.

This type of mistake almost never appears during an informal BOM review because nobody is explicitly looking for it. It appears weeks later when purchasing starts ordering. At that point, engineering has to reopen the design, approve alternates, negotiate with suppliers, or delay production — all under schedule pressure.

A release-ready BOM should identify supply chain risk, not just engineering correctness. And it should define alternates and approved substitutes before release, not after.

6. Wrong Revision Level or Incorrect Lifecycle Status on BOM Items

A component was revised, but the BOM still points to the previous version. A drawing is still in work-in-progress status. A CAD file was updated but not formally released. A specification was replaced, but the BOM still references the old document.

Each of these individually may seem like a minor administrative issue. Collectively, they mean the shop floor or supplier is working from a different version of reality than engineering intended. This is one of the most common root causes of quality escapes — not a wrong part, but a right part at the wrong revision.

7. EBOM Structure Does Not Match Manufacturing BOM Requirements

A BOM can contain every correct part and still be structured wrong for manufacturing.

Engineering organizes the BOM according to CAD assembly logic. This makes sense for design. But manufacturing may need a different structure based on build sequence, workstations, outsourced subassemblies, kitting, or installation steps. Some assemblies in the EBOM are purchased as a unit. Some are only logical groupings that should not become production assemblies. Some need to be broken out differently for ERP to plan correctly.

If the BOM structure is wrong, ERP handoff, production planning, costing, and shop floor execution all absorb the friction silently. Nobody traces the downstream confusion back to the structural mismatch in the original BOM.

8. Missing Compliance Data: RoHS, REACH, ITAR, and Required Documents

The BOM may list all the parts correctly and still be missing the information needed to actually ship, certify, or support the product.

Depending on the industry, that includes RoHS and REACH compliance data, conflict minerals declarations, ITAR classification, country-of-origin records, UL or CE documentation, material data sheets, inspection criteria, test procedures, assembly instructions, and packaging specifications. When this information is absent, the gap shows up during supplier onboarding, customer delivery, audit, or certification — at exactly the moment when it is hardest to fix quickly. A BOM review should ask not just whether all parts are listed, but whether all the information needed to release, build, inspect, certify, and support the product is present and attached.

9. No Formal BOM Review Process or Release Checklist Defined

This one is different from the others because it is not a data mistake. It is the condition that allows all the other mistakes to persist.

In most companies I talk to, BOM review works because experienced people know what to look for. There is no defined checklist. There is no standard set of review criteria. There is no formal list of who needs to be included — engineering, procurement, manufacturing, quality, compliance — and what each of them is responsible for validating. There is no tracked list of issues found, owners assigned, and corrections confirmed.

When the experienced person is in the room, the review catches what they know to catch. When they are unavailable, or when they are reviewing a product domain they know less well, the informal process fails invisibly. The BOM gets released with the same confidence as always, but the coverage was actually much thinner. This is the meta-mistake behind many of the others. Not missing data, but a missing process.

10. BOM Review Issues Not Tracked to Closure or Assigned Ownership

Finding BOM problems is only half the job. What happens next is where most reviews fall apart.

Issues are noted in meeting minutes, mentioned in emails, or captured informally in a spreadsheet someone created for this purpose. A few get fixed. Others get forgotten or stay in limbo. A week after the review, nobody has a clear picture of what was resolved and what is still open. The BOM gets released anyway because the schedule is pressing, with a quiet understanding that some things will be sorted out later.

Later is always more expensive than before release. A real BOM review produces clear actions with owners, priorities, and resolution deadlines. Each issue should have a path to closure, not just a record that it was noticed.

Is Your BOM Review Process Actually a Process?

These ten mistakes have a common thread. They are not primarily engineering failures. They are process failures. The data problems exist because the review process was not designed to catch them. The structural problems persist because the review does not include the right people. The follow-through breaks down because the review produces no actionable output.

This is what I keep coming back to: most companies treat BOM review as an approval event. A moment when someone with authority says the BOM is ready. But approval is not the same as readiness. A signature does not fix missing supplier data. A released status does not synchronize CAD, drawings, and ERP. A meeting does not assign corrective actions or track whether they were resolved.

What a Structured BOM Review Process Needs to Answer

Is there a defined checklist of what must be verified before release — not in someone’s head, but written down and applied consistently?

Are the right people included — engineering, procurement, manufacturing, quality, compliance — with clear responsibility for what each of them validates?

Are there explicit criteria for each review area, so the review is not dependent on who happens to be in the room?

Are issues tracked with owners and followed through to resolution, not just noted and forgotten?

And is the release decision based on confirmed readiness against those criteria, not just the absence of obvious objections?

Most teams I talk to can answer yes to maybe two of these five. The rest is filled in by experience, habit, and the pressure to release.

How Does Your Team Run BOM Reviews Today?

I am genuinely curious — not the formal answer, not “we have a process,” but the real one. Who actually reviews the BOM before release? What are they looking for? What do they consistently miss?

And what tools are you using to run the review — a shared spreadsheet, a checklist in Excel, comments in email, a PLM workflow, or something else entirely? Whatever the answer is, I am curious whether the tool you use today actually supports the five questions above, or whether it mostly handles the easy parts and leaves the hard ones to informal coordination.

Where does the process break down under schedule pressure? And if you were designing a better BOM review process from scratch — checklist, participants, criteria, issue tracking, release validation — what would you insist on including that your current process is missing?

Please reach out to OpenBOM– we are happy to discuss. 

Meantime REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg