Many manufactured products are not single products but families: a base product offered in a range of variants that differ in defined ways. Their bills of materials have to vary with them. This piece explains how Odoo handles configurable BOMs with product variants.
The variant problem
Consider a product made in several sizes, or several materials, or several finishes. Each variant is a distinct sellable, producible item, and each may differ slightly in what it is made of. Modelling this by creating an entirely separate, unrelated product and BOM for every variant does not scale: a product family with several attributes quickly multiplies into many combinations, each needing its own BOM, all maintained by hand. Odoo's variant and BOM capabilities exist to avoid exactly that.
How Odoo models variants
Odoo handles a product family through a product template with attributes. The template is the product family; the attributes, such as size, colour, or material, and their values define the variations; and the specific combinations are the variants. This means a family of variants is managed as one template, not as a scatter of disconnected products.
How BOMs work with variants
With variants modelled this way, Odoo lets bills of materials work with them rather than against them. There are two situations.
The variants share a BOM. Where the variants of a family are made from essentially the same components and operations, a single BOM can apply to the whole product template, covering all its variants. One BOM, the whole family.
The variants differ in defined ways. Where variants genuinely differ in what they are made of, Odoo lets the BOM reflect that. A BOM can be made specific to a particular variant, and individual components or operations on a BOM can be tied to specific variant attribute values, so that a given component or operation applies only to the variants it actually belongs to. This is the configurable BOM: one BOM structure that adjusts to the variant.
The practical approach
The sensible way to set this up is to start from the common ground and add the differences. Define the product template and its attributes. Build a BOM that covers what all the variants share. Then, for the components or operations that differ, tie them to the specific variant values they apply to. The result is one managed BOM that produces the right components for whichever variant is being made, rather than a separate BOM per variant.
When variants genuinely need separate BOMs
Honesty requires a limit. The configurable, attribute-tied approach works well when variants differ in defined, manageable ways from a common base. If two members of a notional family are genuinely so different in construction that they share little, forcing them into one configurable BOM is more awkward than helpful, and they may be better treated as separate products. The configurable BOM is for genuine variation around a common base, not for products that only superficially resemble each other.
Why this matters
Configurable BOMs matter because they keep a variant-heavy product range manageable. Without them, a manufacturer either maintains an unmanageable number of separate BOMs or oversimplifies and loses accuracy. With them, the product family is one coherent thing, a change to the shared part of the BOM flows to all variants, and the differences are captured precisely. For any manufacturer with real product variety, this is what makes the BOMs sustainable.
The takeaway
Odoo handles configurable BOMs by modelling a product family as a template with attributes and variants, then letting a BOM either apply to the whole family or vary by tying specific components and operations to specific variant values. This avoids maintaining a separate unrelated BOM for every variant. Use it for genuine variation around a common base; products that truly share little are better kept separate. For how we approach Odoo for manufacturers, see our manufacturing work.