A phantom BOM is a sub-assembly that lives in your data model but never exists as physical stock. It is consumed immediately by the parent run, never purchased on its own, never stored, never sold. It exists for one reason: to keep the BOM readable.
When to use one
Three legitimate cases:
- Grouping, a set of components that always go together, for clarity. A “hardware pack” that is really four screws, two washers, and a nut. The pack never exists as a physical item, but naming it makes the parent BOM readable.
- Reuse without storage, a mix or blend used in two finished goods, but always made in-line with the parent run and never held. You want the parent BOMs to reference the same pattern, but you don't want MRP to plan a separate run.
- Documentation, a process step that has components but is easier to manage as a named collection.
How MRP treats a phantom
MRP skips the phantom node. When it explodes demand down the tree and hits a phantom, it does not generate a production order for the phantom. It keeps descending and plans the phantom's children against the parent's demand date.
The test: is this a phantom or a real sub-assembly?
Ask three questions. One “yes” means it should be a real sub-assembly, not a phantom:
- Is this ever held as stock, even briefly?
- Is this ever made in a different batch size to the parent?
- Is this ever used across multiple finished SKUs?
If the answer to all three is no, it is a phantom. Otherwise, it is a real sub-assembly with its own BOM and its own production plan.
Common mistakes
- Making everything a phantom to save admin. The system never plans sub-assembly runs, so you end up making them ad-hoc on the day. Throughput suffers.
- Making real sub-assemblies into phantoms to hide stock. Stock exists whether you model it or not. A phantom that has 3kg in a vessel somewhere is a phantom with a traceability problem.
- Never using phantoms at all. Every small grouping becomes a real sub-assembly, MRP generates planning noise for every trivial pack, and the shop floor drowns in work orders for things that were made in ten seconds.
Naming and codes
Give phantoms a distinct code prefix, we use P- in our demo data, so anyone reading a BOM can see at a glance which lines are real and which are phantoms. The cost of mistaking one for the other is non-trivial: it changes what MRP plans.
Phantoms in Stokka
Stokka supports phantom assemblies as a first-class flag on the BOM. MRP respects the flag. Explosions treat phantoms as pass-through nodes. You can toggle a sub-assembly from “real” to “phantom” with a version change, and runs on older versions retain their old behaviour.
Further reading
For how phantoms fit the wider BOM picture, see multi-level vs single-level BOMs. For the full BOM-building guide, read how to build a bill of materials.