A bill of materials, and the software behind it, earns its cost when a kit’s availability has to be calculated from its components’ stock, not carried as a count of its own — and especially when one of those components is itself another kit. If a “kit” is really just one item you stock and ship as a single unit, you don’t need bill of materials software. You need a single SKU.
That is the backend version of the question we answered on the storefront side in our piece on when a product configurator is worth building. That article covered what a customer sees when they configure a product. This one covers what has to be true in the warehouse for that configuration to actually be sellable — and it is a genuinely different problem. A kit that lets a customer pick options is a UI question. A kit whose availability depends on the stock of several other items, one of which is itself a kit, is an inventory-structure question, and it is the one that breaks default ecommerce setups first.
This is the second piece in a three-part series on this client’s build. The third piece covers what happens once a configured kit is priced and quoted — see whether that needed dedicated CPQ software.
Key takeaways
- A BOM earns its cost when kit availability must be derived from component stock, not carried as the kit’s own count. A fixed bundle with no component interdependency doesn’t need one.
- This client’s structure used multi-level phantom BOMs — kits containing sub-kits — with no manufacturing orders. That is pure kitting rather than a job for dedicated kitting software or classic assemble-to-order, and the distinction matters for what you actually need to build.
- Component stock was tracked individually, and kit availability was derived live from it, not stocked as a separate count on the kit itself.
- Neither Shopify’s native Bundles nor WooCommerce’s official Product Bundles extension can nest a bundle inside another bundle. A two-level kit structure has no native inventory path on either platform.
- BOM and kitting complexity is scoped inside the standard $5,000–$50,000 implementation range, not billed separately — it is catalogue complexity in concentrated form.
- Not every kit needs this. If a bundle is really one stocked item, plain single-SKU tracking is the right answer, not a BOM.
What this client’s backend build actually involved
Our client sells gate and access-control hardware kits — motors, tracks, sensors, brackets, and accessories that combine to match a specific gate type. The configurator we covered previously is what a customer sees when building one of these kits. Underneath it, something has to answer a much less visible question every time a kit is added to an order: given what is actually in the warehouse right now, can this specific combination actually ship?
We built that structure using Odoo’s Kit BoM type — the closest thing Odoo’s bill of materials software has to a phantom BOM, in the terminology used across manufacturing and PLM software generally. In Odoo’s own vocabulary this sits under Odoo bill of materials configuration rather than as a separate module. A phantom BOM is a subassembly that is never itself stocked or built as a discrete step; its components are consumed directly into the parent the moment an order needs them, as if the phantom level doesn’t exist in inventory at all. Critically, the structure went more than one level deep: some kits contained other kits as components, rather than every kit being a flat list of individual parts.
Be precise about what this is not: no manufacturing orders were created. Nothing was physically assembled ahead of the order in a production process with routing steps and work orders. Components were picked and shipped together under one kit. That makes this pure kitting, not assemble-to-order in the stricter manufacturing sense, where an order actually triggers a build step. If your mental model is “the system had to build something,” that’s not what happened here — the system had to know, correctly and in real time, what could be picked.
Every component kept its own stock record, and each kit’s availability was calculated from those records rather than stocked as a number on the kit itself. That is what makes a multi-level structure meaningful rather than cosmetic: a top-level kit’s true availability depends on the availability of its sub-kit, which in turn depends on the availability of its own components. Get that calculation wrong at any level and you either oversell a combination you can’t actually fulfil, or block a sale you could have fulfilled.
Where WooCommerce and Shopify’s default inventory setups can’t do this
This is a different limitation from the one we covered in the configurator piece. That article was about what a customer can select. This is about whether a kit’s stock status can be trusted once nesting is involved — and on both platforms, the honest answer is no, past one level.
Shopify’s native Bundles feature has no stock count of its own. A bundle’s availability is calculated live from its components’ stock, which is the right general mechanism — but Shopify’s own documentation states plainly that a bundle cannot contain another bundle. That calculation only ever runs one level deep. There is no native way to let a bundle’s availability depend on the availability of a sub-bundle, because the sub-bundle can’t exist inside the parent in the first place.
WooCommerce’s official Product Bundles extension has the same ceiling. It does deduct stock at the individual bundled-item level and calculates the bundle’s own availability from that, which is again the right mechanism for a single level. But its own documentation is explicit that a Bundle-type product cannot be added as a bundled item inside another Bundle. (Worth a precise distinction here: WooCommerce.com separately sells Chained Products, a different extension built for a different purpose — automatically adding related items to a cart — which does support linking one chained product inside another. That is not the same feature as Product Bundles, and it does not solve the multi-level kit-availability problem described here.)
The common thread is the same one from the configurator piece, from a different angle. Both platforms were built around a product-plus-variants model, and both extended that model with a single, flat layer of bundling on top. Neither was built around a structure where a component can itself be a structure. That is exactly what a multi-level BOM is, and it is why this kind of catalogue tends to land on a system built around it natively rather than one where it was added on afterward.
What BOM and kitting work adds to implementation cost
Like the configurator itself, this isn’t priced as a separate line item — it is scoped inside the same $5,000 to $50,000 (USD) range that covers Odoo ecommerce implementations generally, and the same variable dominates it: how much of the configuration your own team does versus handing the project over.
Where BOM structure specifically moves the number: catalogue complexity is one of the widest-effect cost drivers on any Odoo ecommerce build, and a multi-level BOM is catalogue complexity concentrated into the inventory layer rather than the storefront layer. Depth is what matters here, not breadth. A kit with a handful of flat components is close to a variants problem in cost. A kit whose components are themselves kits requires the compatibility and availability logic to be correct at every level, and someone has to verify that before it goes live — that verification, not the BOM records themselves, is usually the larger part of the work.
When you don’t need a BOM
Most “kits” on ecommerce stores don’t need any of this. If what you sell as a kit is really packed and stocked as one physical unit — a gift set assembled upstream, for instance, that arrives at your warehouse already combined — its availability is just its own stock count. Building a phantom BOM for that case adds structure with nothing to calculate.
The trigger isn’t whether you call something a kit. It’s whether the kit’s true availability depends on more than one underlying stock number, and especially whether any of those numbers belongs to something that is itself a kit. If a single stock count already tells you the truth about whether you can sell it, you don’t have a BOM problem — you have a product.
Frequently asked questions
What is a bill of materials, and when does an ecommerce business need one?
A bill of materials (BOM) is a structure that defines what a product is made of. An ecommerce business needs one when a “kit” it sells isn’t really a single stocked item, but has an availability that depends on the stock of its individual components. If a kit’s stock count on its own already tells you whether you can sell it, you don’t need a BOM.
Is this the same as assemble-to-order?
Not in the strict sense. Assemble-to-order typically means an order triggers an actual build step, with routing and work orders. This client’s kits used no manufacturing orders at all — components were picked and shipped together under one kit, with no production step in between. That makes it pure kitting via phantom BOMs, not assemble-to-order in the manufacturing sense, even though the two terms get used interchangeably in casual conversation.
What is a phantom BOM?
A phantom BOM is a subassembly that is never itself stocked or built as a discrete step. Its components are consumed directly into the parent product the moment an order needs them, as if the phantom level doesn’t exist in inventory. In Odoo, this is the Kit BoM type. It’s the right structure when a “kit” doesn’t need its own inventory record, only its components do.
How deep did the kit nesting go?
More than one level. Some of this client’s kits contained other kits as components, rather than every kit being a flat list of individual parts. That multi-level structure is what makes correct, real-time availability calculation genuinely hard, and it’s the specific thing that neither Shopify’s nor WooCommerce’s native bundle features support.
Can Shopify or WooCommerce handle multi-level kits natively?
No. Shopify’s own documentation states that a bundle cannot contain another bundle, so its live component-based availability calculation only ever runs one level deep. WooCommerce’s official Product Bundles extension has the same restriction: a Bundle-type product cannot be added as a bundled item inside another Bundle. Neither has a native way to let a kit’s availability depend on the availability of a sub-kit.
How much does BOM or kitting work add to an Odoo implementation?
It isn’t priced separately. In our experience, Odoo ecommerce implementations run $5,000 to $50,000 (USD), and multi-level BOM structure is one of the forms catalogue complexity takes that pushes a project toward the top of that range — specifically because someone has to verify the availability logic is correct at every level before go-live.
Do I need a BOM for my kits?
Only if a kit’s true availability depends on more than one stock number, especially if one of those is itself a kit. If your kit is packed and stocked as a single physical unit, its own stock count already tells the truth about whether you can sell it, and a BOM would add structure with nothing to calculate.
Ready to look at your kit structure?
Whether your kits need a bill of materials or just a cleaner single-SKU setup depends on how their availability actually gets calculated today — not on what you call them. That’s worth a real look at your catalogue rather than a generic checklist.
Talk to us about your Odoo ecommerce build →
About the author
Nguyen Tran is the founder of Ministers.io. He has spent five years working on Odoo ERP implementations — five delivered directly and more than twenty advised on — across ecommerce, retail, manufacturing, and maintenance, repair and operations (MRO).
