BOM Review: The Missing Step Between BOM Creation and Release

A BOM can exist and still not be ready for release. Here is why that matters  and what a better review process should do.

Most product BOMs are not built from a single source. In practice, they come together from multiple places — mechanical assemblies from SOLIDWORKS or other CAD tools, electrical components from spreadsheets, purchased parts from supplier catalogs, standard hardware from internal libraries. OpenBOM helps teams pull all of this together into one structured BOM.

And that part works. Teams can capture product structure from different sources, organize it, and share it. The BOM gets built.

But then procurement starts. Or production planning begins. And that is when the real gaps appear.

A buyer goes to place orders and discovers that half the purchased parts have no preferred vendor. A manufacturing planner opens the BOM and finds components without drawings, unclear revision status, or missing material specifications. A cost review shows that nobody actually rolled up the numbers against the target. An ERP import fails because required fields are empty.

These gaps were always there. They were just invisible until someone downstream needed the data.

Finding them at the procurement or production stage is expensive. It causes delays, rework, back-and-forth between teams, and sometimes missed commitments to customers. Finding them earlier — during the BOM building process itself — would save significant time and money.

This is the problem that BOM Review is designed to solve.

If you are the person responsible for making sure product data moves cleanly from engineering to purchasing, manufacturing, or ERP — this is the situation I am describing.

Creating a BOM Is Not the Same as Reviewing It

For many years, the main focus of BOM management has been to create and organize product structure. This is important, of course. Without a structured BOM, teams cannot manage items, quantities, assemblies, revisions, or downstream processes effectively.

But once the BOM exists, the next challenge begins.

A BOM is not just a list of parts. It is a working agreement between engineering, purchasing, manufacturing, suppliers, finance, and sometimes service teams. Each of these groups expects something different from the same BOM.

Engineering wants to make sure the product structure is correct. Purchasing wants supplier and cost information. Manufacturing needs drawings, materials, processes, and make-or-buy decisions. Finance wants cost rollups and target comparisons. ERP needs clean and complete data.

This is where the gap appears. A BOM can be structurally correct but not useful enough for the next step. It can be complete from the engineering point of view, but not ready for purchasing. It can be released, but still missing sourcing data. It can include all parts, but still fail target cost or target weight.

That is the problem BOM Review is supposed to solve.

Why BOM Review Is Often Hard

In many companies, BOM review happens manually and informally.

Someone exports the BOM to Excel and adds a column for comments. Someone else opens a slightly different version. A third person fills in some cells and sends it back. The project manager tries to merge the feedback. By the end of the week, there are three versions of the spreadsheet, two email threads, and one Slack conversation — and nobody is completely sure what was agreed or what still needs to be done.

The product data and the review process live in completely different places. That separation is the root of the problem.

This is not because teams are careless. It happens because BOM review is a cross-functional process. It touches many people, many data points, and many goals. It is not enough to say, “Here is the BOM.” The real question is, “Is this BOM ready for what we need to do next?”

And the answer depends on context.

A purchasing review is different from a manufacturing review. A cost review is different from an engineering release review. A supplier readiness review is different from an ERP handoff review. Each one requires different information and different people.

This is why BOM Review should not be treated as a one-time meeting. It should be treated as a product readiness process.

What BOM Review Needs to Do

When I think about BOM Review, I see three practical jobs.

First, it needs to validate the BOM. The review process should help teams find missing, incomplete, inconsistent, or risky information before it creates problems downstream.

Second, it needs to turn findings into tasks. Finding a problem is useful only if someone owns the fix. A missing vendor, a missing drawing, a duplicated part, or a cost exception needs to become an action item assigned to the right person.

Third, it needs to track improvement against goals. BOM review should not only produce a list of issues. It should help teams understand whether the BOM is getting better and moving closer to where it needs to be.

These goals can be different depending on the company and product. Some teams care most about target cost. Others prioritize target weight, supplier coverage, manufacturing readiness, documentation completeness, standard part usage, compliance, or ERP handoff quality.

The important thing is that BOM Review connects product data, people, actions, and goals in one continuous process.

Validate the BOM

Validation sounds simple, but in practice it means different things depending on what the BOM needs to support.

If the BOM is being prepared for purchasing, the review may need to check whether purchased parts have preferred vendors, manufacturer part numbers, cost, lead time, and approved alternates.

If the BOM is being prepared for manufacturing, the review may need to confirm that drawings are attached, revisions are clear, materials are defined, make-or-buy decisions are complete, and required process data is available.

If the BOM is being reviewed for cost, the team may need to compare estimated cost against target cost, identify high-cost components, find missing cost data, and surface exceptions.

If the BOM is being reviewed for weight, the team may need to understand which assemblies are above target, which components contribute most to the problem, and whether design alternatives exist.

This means BOM validation cannot be only a generic “missing fields” report. It needs to be connected to the goal of the review.

The same BOM can be reviewed from multiple perspectives: engineering readiness, purchasing readiness, manufacturing readiness, cost readiness, supplier readiness, and release readiness. A useful review process helps teams see not only what data exists, but what data is missing for the specific next step.

Create Tasks for People to Fix

Validation is only the beginning.

The next question is always: who needs to do something?

This is where many BOM review processes break down. When someone finds a gap during BOM review, the most common response is an email or a Slack message. “Hey, can you check part number 10472? I think the vendor is missing.” That message may get a reply, or it may not. It is disconnected from the BOM. There is no record of it in the product data. Two weeks later, nobody knows whether it was resolved.

A better process connects the finding directly to the BOM row. The task lives next to the item with the problem. It is assigned to a specific person. It has a status — open, in progress, resolved. When the vendor data is added, the task closes. The review record shows what was missing, who fixed it, and when.

This is a simple idea, but it changes the coordination experience significantly. The BOM becomes not only a data structure but a workspace for review and action.

If vendor information is missing, purchasing should be assigned. If a drawing is missing, engineering or design should be assigned. If make-or-buy status is unclear, manufacturing should review it. If an expensive component has no alternate, supply chain should investigate. If an assembly exceeds the target weight, engineering needs to look at design options. If cost exceeds the target, the product team needs to understand where the gap comes from.

When tasks are connected directly to BOM items rather than floating in email threads and spreadsheet comments, the whole team can see what is open, what is being worked on, and what has been resolved — without anyone having to chase down status updates manually.

Track Improvement Against BOM Goals

The third job is improvement tracking.

A good BOM review process should answer a simple question: are we getting closer to where we need to be?

Take target cost as an example. A team may have a product cost target of $180 per unit. The BOM rolls up to $214. That gap is visible — but only if someone runs the calculation and compares it against the target. If that comparison never happens during review, the gap surfaces later, during quoting or procurement, when it is much harder to fix.

The same is true for weight. A mechanical assembly may have a target of 4.2 kg. The current BOM rolls up to 5.1 kg. Engineering needs to know which subassembly is contributing most to the problem, and whether there is a design option available. But if nobody tracks weight as a BOM goal during review, that conversation happens too late.

This is why goal tracking needs to be part of the review process, not a separate analysis that happens afterward.

BOM readiness is rarely achieved in one step. A team may start with a BOM that is structurally complete but missing cost data. Then purchasing fills in vendor information. Engineering adds missing drawings. Manufacturing confirms make-or-buy status. Supply chain adds alternates. The project manager tracks whether cost and weight targets are improving.

Without tracking, this improvement is hard to see. Teams may know there are issues, but not whether the number of issues is going down. They may know the target cost is missed, but not whether recent changes are helping. They may know drawings are missing, but not how close they are to full documentation completeness.

BOM Review should help teams track practical goals: target cost, target weight, sourcing completeness, manufacturing readiness, ERP handoff readiness, supplier coverage, drawing and documentation completeness, revision readiness, standard part usage, and compliance completeness. These are not abstract metrics. They are the things teams need to know before they can move forward with confidence.

A Simple Example: Reviewing a BOM Before Purchasing

Imagine a team preparing a BOM for purchasing.

The engineering structure is already created in OpenBOM — assembled from SOLIDWORKS exports, a handful of purchased components added manually, and a few items pulled in from a supplier catalog. The quantities are correct. The team can see all assemblies and components. At first glance, the BOM looks complete.

But when the team reviews it for purchasing readiness, several problems appear.

Some purchased parts do not have preferred vendors. A few items are missing cost. Several components do not have manufacturer part numbers. One expensive item has no approved alternate. A few drawings are missing. One subsystem is above the target weight. Two components look similar but use different part numbers and descriptions — possibly duplicates introduced when data came in from different sources.

This is a very common situation. Nothing is completely broken, but the BOM is not ready.

A useful BOM Review process would group these findings by category: sourcing gaps, cost gaps, documentation gaps, possible duplicates, weight risks, and approval issues. Then it would help create tasks for the right people.

Purchasing reviews missing vendors. Engineering confirms duplicate or similar parts. Design uploads missing drawings. Supply chain investigates alternates. The project owner tracks progress toward target cost and purchasing readiness.

The value is not magic. The value is focus.

Instead of manually inspecting hundreds of rows, the team can see what needs attention. Instead of circulating a spreadsheet, the team connects tasks directly to the BOM. Instead of losing decisions in emails or meetings, the team preserves the context of what was reviewed and what was fixed.

Where AI Can Help With BOM Review

This is the area where I think AI agents can become useful in a very practical way — not by replacing the review process, but by making it faster and more connected.

To make this tangible: in the purchasing example above, a BOM Review Agent would automatically identify the missing vendor records, the items without cost, the duplicate candidates, and the subsystem above target weight. It would group them by category and suggest who should act on each one. A purchasing manager opens the review and sees their specific action items — not a spreadsheet with 400 rows highlighted in yellow, but a focused list of the gaps that are actually blocking sourcing.

The agent also tracks whether those gaps are being closed. If the same vendor record is still missing after two days, the review shows it as an unresolved item. If the cost rollup improves after engineering makes a design change, the progress toward target cost is visible.

This is not AI as a chatbot. It is AI as a review coordinator — helping the team see what needs attention and keeping the work connected to the product data.

This is the direction we are exploring with the next OpenBOM agent: BOM Review Agent.

The idea is not to replace engineers, buyers, manufacturing planners, or project managers. The idea is to help them review BOMs in context, identify what needs attention, and coordinate improvement work in a way that stays connected to the product data.

BOM Review Agent is still early thinking. We are shaping the workflow with customers and partners. But the direction is clear: after product data is captured and organized, teams need a better way to review it and make it ready for the next process.

Closing: The BOM Review Discipline

The more I think about BOM Review, the more I see it as a missing discipline in many companies.

A missing vendor becomes a purchasing delay. A missing drawing becomes a supplier question. A wrong revision becomes a manufacturing issue. A missing cost becomes a budget surprise. A missing alternate becomes a supply chain risk. An overweight assembly becomes a late design change.

BOM Review helps teams catch these issues earlier — before they reach procurement or production, where fixing them costs far more time and money than it would have earlier in the process.

It also helps teams build a better working process around product data. Instead of asking people to manually check every row, the review process guides them to the most important gaps. Instead of treating review as a one-time meeting, it becomes an ongoing workflow. Instead of losing context, it preserves the history of what was checked, what was fixed, and why decisions were made.

A BOM can exist and still not be ready. This is the core problem.

BOM Review is the process that helps teams move from “we have the data” to “we trust the data for the next step.” It is about validation, task creation, and improvement tracking. It connects product structure with people, decisions, and goals.

Because in the end, the question is not only whether the BOM exists. The question is whether the BOM is ready.

This is an early look at how we are thinking about BOM Review and the direction of the next OpenBOM agent. We are actively working through these workflows with customers and partners — especially around what validation rules matter most, how tasks should connect to BOM items, and what goal tracking looks like in practice.

If BOM readiness is a problem your team deals with regularly, I would genuinely like to hear how you handle it today. The best product thinking usually starts with specific situations, not general ones.

More on BOM Review Agent soon.

REGISTER FOR FREE to check how OpenBOM can help. 

Best, Oleg