The parts list is not in dispute. Which of those parts is a thing you build is.
A finished product is a structure, not a list. Some lines on it are bought, some are subassemblies somebody makes, and some are kits, groupings that were never a physical thing at all, just a convenience for whoever wrote the list. On paper the three look identical. In practice the difference decides whether demand for the parent raises a production order or quietly resolves into components on a pick, and whether the buyer is meant to source the parent or the parts. When the structure lives in a document, that judgement is made again by hand every time somebody reads it, and two people reading the same document make it differently.
What you get with bill of materials
The structure as a record, with the distinction built in. A bill of materials has a header and component lines, each line carrying its own quantity, unit of measure and position in the sequence, so a component can be specified in a different unit from the parent. A BoM is one of exactly two types: a manufacturing BoM, or a kit. A kit is never manufactured, it is exploded into its components wherever it is used, and the explosion repeats on each level it discovers, so a kit nested inside a kit is resolved rather than stopped at.
Secondary outputs are first-class: a byproduct line carries its own product, quantity, unit and cost-share percentage, and the share is constrained to be non-negative and to total no more than one hundred, checked on the bill of materials and checked again on the manufacturing order.
Lines, byproducts and operations can each be attached to a named step of the routing, so a component is consumed at the operation that consumes it rather than at the order as a whole. Each of the three can also be restricted to specific product attribute values, which is what lets one bill of materials serve several variants instead of one per variant. Individual lines can be flagged for manual consumption. The BoM carries its own production lead time, which the procurement layer reads when it works a required date backwards.
And the structure is readable from the product: how many BoMs a product heads, how many it appears in, and whether it is a kit are all on the product record, with a BoM Overview report that renders the structure itself.
Where bill of materials comes from
All of that ships in Odoo Community's manufacturing module, part of the core, not a tier, not an add-on, not priced per user. And not taken from a feature list either: each behaviour above was checked against a running instance, which is why this page describes kit explosion and cost-share constraints rather than saying "full BoM support".
One boundary belongs here rather than in a footnote. Engineering change orders and product lifecycle management are not part of this module; Odoo's own is an Enterprise one. Whether anything in the wider ecosystem replaces it is a question nobody on our side has answered yet, so this page claims nothing about it in either direction. If controlled revisions are part of how your engineering team works, raise it on the call and you will get a straight answer about what we would have to build.
What is a bill of materials?
A bill of materials is the record of what a product is made of, and optionally of how it is made. It has a header naming the product, the quantity it produces and the unit that quantity is measured in, and a set of component lines, each with its own quantity and its own unit of measure, so a parent measured in units can consume a component measured in metres or kilograms. Beyond components a bill of materials can also carry secondary outputs of the same run, the operations the work passes through, a production lead time, and rules about how strictly actual consumption has to match what the document says. It is worth separating from a parts list, which is a description. A bill of materials is an instruction: something downstream reads it and acts, raising purchases for what has to be bought and builds for what has to be made.
What is the difference between a kit and a subassembly?
A subassembly is a real intermediate product that is made, stocked and consumed in its own right, so demand for it raises a production order of its own. A kit is not made at all, it is a grouping on paper, and when something needs it, the kit is replaced by its components rather than being produced. The practical difference is what appears in the queue: a structure full of subassemblies generates a chain of builds, and the same structure typed as kits generates one. This is why the distinction is worth setting deliberately rather than inheriting from whoever drew the original diagram, and why it matters that the replacement is recursive, a kit that contains another kit has to resolve all the way down, or the queue fills with orders for things nobody ever intended to build.
How do you avoid maintaining one bill of materials per product variant?
By making applicability a property of the line rather than of the document. If individual component lines, secondary outputs and routing operations can each be restricted to particular attribute values, this line only for the 12-volt version, that operation only for the coated finish, then one bill of materials on the product template covers the whole family, and the variant being produced decides which lines apply. The alternative, a separate document per variant, is not wrong so much as unstable: an engineering change then has to be applied to every copy, and the copies drift in the order somebody got to them. Variant sprawl in bills of materials is usually a symptom of the document being the unit of variation when the line should have been.
Does Odoo need an add-on for bills of materials?
No. Bills of materials, component lines, kits, byproducts and routing operations are all part of Odoo Community's manufacturing module, which ships in the core, so there is no per-user fee and no edition to reach for them. The BoM Overview report that renders the structure ships with it. The thing worth checking on any ERP shortlist is not whether bills of materials exist, since they always do, but which specific behaviours sit behind a paywall: kit explosion, byproduct costing, per-variant lines and operation-level material assignment are the ones that decide whether the document reflects how the product is actually built, and they are the ones worth naming in a demo request rather than assuming.