Bill of Materials (BOM) Management
Term 45 of 68 in the ERPStack technical glossary
What is Bill of Materials (BOM) Management?
A Bill of Materials (BOM) is a comprehensive list of raw materials, assemblies, sub-assemblies, parts, and the quantities of each needed to manufacture an end product.
Bill of Materials (BOM) Management at a glance
- Structure
- A directed acyclic graph, not a list: 1 parent part can expand through 5 or more nested levels
- Core operation
- Explosion — walking the tree to turn 1 finished unit into total component demand
- Storage
- PostgreSQL 18 recursive CTEs over a parent/child table, versioned by effective date
- Change control
- Every revision retained; 0 in-place edits, so a build from 2 years ago still reproduces
- Built with
- PostgreSQL 18 recursive CTEs through Drizzle ORM 0.45, surfaced by Next.js 16 and React 19, revisions retained immutably, procurement and costing in the same AWS-hosted ERP
- Numbers that matter
- 5 or more nesting levels per assembly; 1 new row per revision; 0 destructive edits; 3 quantities multiply at every level of the tree
- Where it lives
- Inside the ERP, not a spreadsheet — SAP S/4HANA, Oracle NetSuite and Epicor ERP all model it
- Commonly paired with
- An Immutable Audit Trail in PostgreSQL 18, AS9100 Aerospace Standard traceability, Drizzle ORM 0.45 recursive queries, Next.js 16 and React 19 screens, RBAC approvals, and procurement inside the same ERP
How Bill of Materials (BOM) Management works in production
The ERPStack approach to Bill of Materials (BOM) Management
We build BOM management pipelines using recursive database queries, allowing managers to track components and calculate costs across complex assemblies.
Frequently asked questions about Bill of Materials (BOM) Management
Why is a Bill of Materials harder than a product list?
Because Materials Management is recursive. A finished assembly contains sub-assemblies which contain their own parts, so a single order has to be exploded through the whole tree before you know what to buy. Quantities multiply at each level, shared components appear in several branches, and a substitution 3 levels down changes the cost of everything above it. A flat list cannot express any of that.
How should BOM revisions be stored?
Immutably, with effective dates. Materials Management data is evidence: if a unit shipped in March, you must be able to reconstruct exactly which revision built it, including the substitutions made that week. ERPStack stores each revision as a new row rather than an update, so history is intact by construction. That also makes engineering change orders reviewable, because the difference between 2 revisions is a query rather than a memory.
What breaks when the BOM lives in spreadsheets?
Three things, predictably. Materials Management in a spreadsheet has no referential integrity, so a renamed part silently orphans its children; no concurrency control, so 2 planners overwrite each other; and no history, so nobody can prove what was built. The failure is rarely dramatic — it shows up as procurement ordering the wrong quantity and nobody being able to explain why.
How does a BOM connect to purchasing and production?
Through explosion and netting. Materials Management turns a production plan into gross component demand, then nets it against stock on hand and open purchase orders to produce what actually needs buying. Because that calculation touches inventory, procurement and costing at once, it belongs inside the ERP transaction boundary rather than in a separate tool that has to be reconciled afterwards.