BOM is the data foundation of engineering and manufacturing. Even its name can spark some controversy among professionals in these fields, especially those who remember part lists on drawings. Still, the Bill of Materials remains one of the most universal terms used across various tools and software systems to manage product data. Bill of Materials (BOM) is the connective tissue between design, production, procurement, and support. Yet, despite its universal presence, BOM remains one of the most fragmented and misunderstood data artifacts. Every system – PLM, ERP, CAD, or MES – has its own view of the BOM. Every company reinvents how BOMs are defined, exchanged, and managed. And when you step back, the lack of a unified BOM standard becomes painfully clear.
In my experience, companies spend a lot of time and money trying to align their systems around BOM synchronization. And despite decades of progress in standards, data exchange formats, and integration tools, most organizations still fall back to the lowest common denominator: Excel spreadsheets.
So, the question remains—are we finally getting closer to solving this problem? Could a universal standard, or perhaps AI, pave the way to more intelligent and interoperable BOM workflows? Let’s explore the landscape.
The Current State of BOM Standards
If you ask 10 engineers what a BOM is, you’ll get 15 answers. That’s because BOMs are shaped by purpose: a design BOM is not the same as a manufacturing BOM, which is different again from a service BOM or a sales configuration.
At a high level, a BOM is simply a list of components that make up a product. But the structure and data in that list vary dramatically depending on where and how it’s used. And that’s where the challenges begin.
Even the core types of BOM structures diverge:
- Single-level BOMs: A flat list of parts used in a top-level assembly.
- Multi-level BOMs: A hierarchical view showing parent-child relationships and nested subassemblies.
- Flattened BOMs: An exploded version used for quantity rollups, procurement, or costing.
But real-world BOMs are far more complex. Each domain adds its own semantics and requirements:
- CAD systems introduce design variants and geometry references.
- PLM tools track revisions, effectivity, and change management.
- ERP systems care about costing, supply availability, and operations planning.
- CPQ and sales platforms deal with configurations, rules, and option constraints.
So while the concept of a BOM is universal, the data models are anything but.
Standards That Aim to Bring Order
Over the years, various standards have emerged to address BOM interoperability, but none have managed to gain universal traction. They’re often domain-specific, complex to implement, or simply too late to replace entrenched systems.
Let’s take a quick tour of what I remember or found today (thanks for all AI and search tools :)):
- IPC-2570/2578 (PDX Suite): Used in electronics manufacturing, this suite helps exchange product data and BOMs in a structured XML format. It’s especially useful in ODM/EMS workflows but is rarely seen outside electronics.
- GEIA-STD-0007: A standard tailored for aerospace and defense contractors. It supports detailed lifecycle tracking and logistics support data—critical for compliance in those regulated industries (I was not aware of this, so if you have an experience, please share)
- STEP (ISO 10303): While not a BOM standard per se, STEP is a powerful framework for exchanging CAD and product structure data. It’s widely used for 3D model and design exchange, but it lacks full BOM semantics, especially around lifecycle and operational metadata (most of CAD systems today support it)
- CycloneDX: Another one I found as a A newer entrant, from software supply chain needs (think SBOMs), but it’s expanding into hardware. CycloneDX defines a flexible format for components, dependencies, and vulnerabilities.
Then there are the de facto “standards”—the export formats from tools like SolidWorks, Altium, SAP, Oracle, etc. Each has its own schema, often undocumented, but used widely in industry. Each PLM tool for the last 20-30 years claimed to be a standard for a BOM (in one way or another)
And presiding over all of them is the de facto king of BOM management—Microsoft Excel (or Google Sheets) these days. Despite its flaws, Excel continues to be the default tool for compiling, comparing, and exchanging BOMs. It’s easy, accessible, and flexible—but not scalable or reliable for modern digital workflows.
Various spreadsheet tools are growing around, but all of them have the same issues with BOMs – lack of structure and single source of truth support.
The Real Challenges of Cross-System BOM Exchange
When BOM data needs to flow between tools and teams, the trouble begins. Differences in structure, naming, relationships, and data granularity create a maze of compatibility issues. Every system has its own schema, and no single schema can satisfy them all.
This fragmentation leads to a world of brittle integration strategies:
- Custom-built adapters between tools.
- Rigid ETL pipelines to transform data.
- Centralized master data management solutions to “own” the BOM.
- Middleware platforms that try to bridge the gap.
Yet despite all this effort, most companies end up bringing critical BOM data outside their systems in spreadsheets, shared folders, or emails, just to keep everyone aligned.
Over the years of working with different BOM systems and projects, I found that what makes BOM data exchange so hard isn’t just formatting, but its the semantics. Systems don’t just disagree on the shape of the data, but also on what it means, how it changes, and who owns it.
BOM Data Beyond Excel: The Rise of Intelligent Models
For many years, relational databases (SQL) were the foundation of PLM and ERP systems. BOMs were stored in normalized tables, often flattened for ease of querying. While this worked well for structured data, it created rigidity in adapting to evolving product structures and relationships.
In recent years, a shift is happening.
New data formats and technologies are emerging:
- XML, JSON: Common for data exchange in web and software tools. They offer flexibility but lack native understanding of BOM semantics.
- Graph databases: In my perspective, the graph model is a game-changer. Instead of tables, they store relationships as first-class entities. For BOMs, where everything is connected and context-rich, graph models provide:
- Better navigation across relationships (e.g., find all affected assemblies).
- Easier change propagation and impact analysis.
- Scalability across complex product structures.
- Foundation for reasoning and AI-based automation.
I want to share my experience of using graph databases – At OpenBOM, we’ve embraced this graph-based approach. Our xBOM service builds on this architecture to allow flexible, multi-view BOM structures across engineering, manufacturing, and supply chain.
This new way of thinking about BOM data—not as a table but as a network of relationships—is foundational for the next generation of intelligent tools.
The AI Opportunity: Will LLMs Reinvent BOM Management?
AI has entered every corner of enterprise software—and BOMs are no exception. The use of large language models (LLMs) like GPT or Claude opens new doors for how BOM data can be interpreted, analyzed, and generated.
The potential is enormous:
- Automate BOM creation from design files or even product descriptions.
- Analyze and validate BOMs for errors, inconsistencies, or missing parts.
- Suggest alternate components based on availability, cost, or risk.
- Generate different BOM views (engineering, manufacturing, procurement) on demand.
In early OpenBOM experiments, we’ve seen how AI agents can:
- Parse messy spreadsheets and reassemble clean BOMs.
- Interpret context from CAD metadata and derive structured outputs.
- Interface with supplier databases to suggest procurement options.
But we must be cautious.
LLMs are powerful at understanding language, but BOMs require domain context and structured reasoning. They need to understand what a part is, how it relates to assemblies, how revisions work, and how configurations vary. Without a grounding in a semantic product model (like a graph), LLMs risk being impressive… but inaccurate.
So while we’re not quite at a “universal BOM-AI,” the path is forming. LLMs + graph-based product data + contextual reasoning = the future of BOM automation.
The Road Ahead: Preparing for the Future of BOM Interoperability
So where does this leave engineering and manufacturing teams today?
We may not have a universal BOM format yet. But we do have a direction—and a growing toolset of AI, graph-based data, and flexible integrations that can help teams better manage complexity.
Here’s what I recommend:
- Assess your current BOM landscape. Map out all the systems that manage BOM data—CAD, PLM, ERP, CPQ, etc. Identify overlaps, redundancies, and manual steps.
- Centralize BOM knowledge, even if virtually. Whether through a platform like OpenBOM or your own infrastructure, aim to consolidate BOM data into a common graph or schema. Think in terms of connected data, not isolated lists.
- Use APIs and standard connectors where possible. Avoid vendor lock-in and reduce brittle integrations. Open APIs, webhooks, and standard formats (JSON, CSV, CycloneDX, etc.) can go a long way.
- Start experimenting with AI agents. From classification to validation, small use cases can bring real gains. Keep in mind that AI doesn’t replace your engineers—it augments them.
- Push for semantic clarity in your BOM models. Whether through internal documentation or external standards, define what your BOMs mean. Don’t just exchange data—exchange understanding.
Conclusion: Are We There Yet?
The BOM problem isn’t new, but the tools we now have to solve it are.
While standards offer some structure, and tools like Excel provide flexibility, neither is enough on its own. We need smarter data models, more flexible platforms, and intelligent tools that can interpret, reason, and adapt.
The convergence of semantic graphs, open standards, and LLM-powered assistants gives us a glimpse of what’s possible. We may never get to a single “universal BOM file,” but we might achieve something better—a world where BOM data flows seamlessly, adapts to context, and helps people make better decisions.
So the question remains:
Will we finally break free from the mess of spreadsheets and achieve BOM intelligence and openness across the digital enterprise? Or will we keep building bridges between islands of structured chaos?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased
Want to explore how OpenBOM is enabling intelligent, multi-view BOMs and AI-enhanced workflows? Visit www.openbom.com or dive into the OpenBOM blog for real-world examples.
