Every factory I have visited for OEMup in the last two years has the same conversation eventually. We sit with the supervisor, ask them to walk us through how a finished pump (or compressor, or moulded part, or fabricated frame) is built, and within ten minutes the whiteboard has a tree on it. They have always known the BOM was a tree. The software just never let them say so.
This post is the tree, made explicit. If you are evaluating a manufacturing ERP, this is the data model you should ask every vendor to show you on a whiteboard. If they hesitate, they are selling you an inventory app with a manufacturing wrapper, not a manufacturing system.
What is a Bill of Materials, really?
A bill of materials is the parts list that turns inputs into one unit of an output. Three things matter about a BOM:
- Parent — child relationships. One finished good is made of N components, each in a specific quantity.
- Units of measure. The parent might be in pieces, a child in kg, another in litres. The BOM stores the conversion implicitly.
- Yield and scrap. Real manufacturing loses material. A BOM that does not capture scrap percentages will under-issue material to the shop floor and the supervisor will quietly draw extra from inventory without a record.
A single-level BOM stops at the immediate children. A multi-level BOM continues until every leaf is something you either buy from a vendor or pull from raw-material stock. The difference is the difference between a parts list and a production plan.
A real example: a 1HP centrifugal pump
This is roughly what one of our launch customer’s BOMs looks like for a 1HP pump. Names simplified, quantities rounded.
Notice five things in that tree:
- Three different levels of depth — the motor sub-assembly stops at level 1 (it’s bought, we don’t open it), the impeller goes to level 3, the casing has a phantom kit at level 2.
- Scrap percentages are encoded as quantities greater than 1 (the casting needs 1.05 pieces because 5% will fail machining).
- Mixed units of measure — pieces, kg, litres — all in one BOM.
- A phantom (the bolt set) groups two fastener lines so the engineering BOM stays readable, but the system never actually builds the kit; it explodes the bolts and washers straight into the work order.
- An alternate component on the bearing — the planner can substitute the sealed variant when conditions demand without changing the parent BOM.
None of this fits in a single-level BOM. None of it fits in Excel beyond the first few SKUs. This is why every factory above 20 SKUs eventually keeps a "real BOM" in someone’s head while a "Tally BOM" exists for the journal voucher.
What can you do with a multi-level BOM that single-level can’t?
1. True roll-up costing
Cost flows from raw material at the leaves up to the finished good at the root. Change EN8 round-bar price and the impeller cost updates, which updates the pump cost. With a single-level BOM you would have to re-cost every parent manually.
2. Stage-by-stage production planning
Each sub-assembly can be planned independently. The supervisor can release a work order for "make 50 impeller assemblies" without releasing the final pump assembly — useful when waiting for motors or paint.
3. Operation-level WIP tracking
Each level can have its own routing (cutting → welding → QC). When a part fails at operation 3, the system knows exactly which level’s BOM and which operation it failed at. Variance analysis becomes possible.
4. Reusable sub-assemblies across products
The same impeller assembly might appear in five different pump models. Change its BOM in one place — every parent updates. Without a tree, you would maintain five copies and lose synchronisation within a quarter.
5. Material requirements planning (MRP)
Given a sales forecast of "200 pumps next month", MRP explodes the BOM tree to compute exactly how many castings, how much EN8 bar, how many bolts to procure. A flat BOM cannot do this beyond the first level.
6. Engineering change control
When the design team changes the impeller from 6 to 8 vanes, the change happens at one node and ripples to every product that uses it — with versioning, so old work orders keep their original BOM.
Why does BOM versioning matter for accurate costing?
This is the single most important capability after the tree itself. Without it, the BOM is a moving target.
Here is the scenario every factory eventually hits: in March you closed 50 work orders for the 1HP pump, each costed against BOM version 1.0. In April the sourcing team finds a cheaper casting vendor and switches. You update the BOM. Then in May the auditor pulls a random work order from March and asks why the standard cost shown on the work order does not match the BOM. If your BOM has no versioning, it does not match. You have no defensible answer.
With versioning:
- Old work orders stay linked to BOM v1.0 and continue to cost against it forever.
- New work orders use BOM v1.1 from the date of the change.
- Variance reports compare actual cost to the BOM version that was in effect when the order was released — not the latest one.
- You can run a diff between any two BOM versions to see exactly what changed and when.
An Excel BOM “version” is usually whatever was on disk the last time someone saved. There is no history. There is no "what did this BOM look like on 15 March 2026?" There is only the current file and whatever the supervisor remembers. That gap closes CBIC-mandated ITC-04 audits and CA queries about why standard costs moved.
What are phantom BOMs and alternate components?
Phantom BOMs
A phantom is a sub-assembly the system never actually builds or stocks. It exists only as a grouping in the BOM tree. When a work order is released for the parent, the phantom is "exploded" — its components flow straight into the parent’s material issue list.
The bolt-set in our pump example is a phantom. There is no "Bolt-Set-Casing" item in inventory. The phantom just groups the bolts and washers in the BOM so the engineering drawing stays readable. When the work order is released, the system issues 8 bolts and 16 washers directly. The phantom never appears in stock.
Use phantoms for fastener kits, harness kits, paint-and-label kits, anything that travels together in the engineering drawing but never sits on a rack.
Alternate components
Each BOM line can carry one or more alternates, ranked by preference, with optional cost or quality flags. The planner picks the primary by default; if it is short, the system auto-suggests the alternate.
Real-world uses we have seen at our launch customers:
- Bearings: sealed (6203-2RS) substituted for open (6203) when humidity is high.
- Hardware grades: SS316 substituted for SS304 when chloride exposure is expected.
- Vendor variants: the same EN8 round bar from two suppliers with a 2% price difference.
- Imported ↔ local: a Japanese motor substituted with a domestic-equivalent when import lead times stretch.
Alternates change the work-order cost without changing the BOM itself. This is how factories stay agile.
Scrap and yield
Two ways to encode loss. Scrap percentage at the component line says “to produce 1 unit of the parent, issue 1.05 of this child to account for 5% expected scrap.” Yield percentage at the parent line says the opposite — "1 unit of input produces 0.95 of output." Pick one convention per factory and stick with it; mixing the two is a common source of costing confusion.
What a clean BOM data model looks like
Without going into our schema in detail, here is what we settled on in OEMup’s production module after looking at how five launch factories actually use their BOMs:
- BOM Header (parent item, version, effective-from date, effective-to date, status)
- BOM Lines (child item, quantity, UoM, scrap %, alternate group ID, phantom flag, operation linkage)
- Alternates linked to a BOM Line by the alternate group (one primary, N alternates, ranked)
- Routing Lines linked to BOM levels — each operation knows which components it consumes
- BOM Change Log — every edit captures who, when, why (engineering change number)
The headline test for a BOM data model is this: can you ask the question "what is the standard cost of this product as of 15 March 2026, given the BOM version in effect that day and the input prices from that day’s purchase records?" If the answer takes more than 30 seconds, the BOM is not really there yet.
See the BOM tree of your real product on OEMup — in 20 minutes
Bring a sample BOM (Excel, drawing, or even a hand-sketch). We’ll model it live during the demo with versioning, phantoms, and an alternate component — then explode an MRP for 100 units.
Book a Demo →All plans include the full production module — see pricing.
The bottom line
Single-level BOMs survive only as long as your products are simple and your team is small enough to keep the rest in their heads. The moment you cross 20-30 SKUs, add a second shift, or hire your first dedicated planner, the single-level model breaks. It does not crash — it just quietly stops telling the truth, and the team works around it with spreadsheets that diverge from the books.
A multi-level BOM is not exotic ERP territory. It is the bare minimum to run a factory honestly. Insist on it, and insist on versioning. The rest of the manufacturing module — work orders, MRP, costing, job-work — depends on this one data structure being right.
See the product: OEMup Multi-Level BOM Software →
Related deep dives: 5 Things Tally Cannot Do That a Manufacturing ERP Can covers the same gap from the operational angle; Job Work and ITC-04 is the GST side; How to Migrate from Tally to a Manufacturing ERP walks through importing existing BOMs into a proper structure.
FAQ
What is a multi-level bill of materials?
A hierarchical structure where the components of a finished product are themselves assemblies made from sub-components. Each sub-assembly has its own BOM, and the tree continues until every leaf is a raw material or bought-out part.
Why is a single-level BOM not enough for a manufacturer?
It cannot represent how a product is actually built in stages, cannot cost a half-finished work order, and cannot let you change one sub-component without redoing every parent BOM by hand. It is fine for a trader; it is wrong for a factory.
What is BOM versioning and why does it matter?
Versioning keeps the historical BOM intact when a component changes. Old work orders continue to cost against the old BOM; new ones use the new one. Without versioning, changing a component retroactively corrupts the costing of every closed work order on that BOM.
What is a phantom BOM?
A sub-assembly the system never actually builds or stocks. It exists only as a grouping in the BOM tree. When a work order is released, the phantom is exploded straight into its components, which are issued directly to the parent.
What are alternate components?
Interchangeable substitutes the planner can use when the primary is out of stock or more expensive. Each BOM line can have ranked alternates, with optional cost or quality flags. The BOM itself stays unchanged; only the work-order substitution is recorded.
Can I maintain my BOMs in Excel and just sync to the ERP?
You can during migration, but it does not scale. Excel cannot represent parent-child relationships cleanly, cannot enforce that a component referenced in 12 BOMs changes everywhere at once, and has no versioning. The 5-SKU spreadsheet becomes a 200-SKU mess within 18 months.
How does OEMup handle multi-level BOMs?
Versioned tree with native support for phantoms, alternates, scrap percentages, and operation routings linked to specific BOM levels. Changing a component in one place propagates to every parent that uses it; old work orders retain their original BOM version; reports roll up cost from raw material to finished good through every level automatically.