Khichdi InfoTech
Skip to content

Odoo Manufacturing · intermediate · 10 min read

Understanding Bills of Materials in Odoo

How to structure Odoo BoMs for single-level, multi-level, phantom, and subcontracting builds — with quantities, UoM, revisions, and costing implications.

Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice

Table of contents

A bill of materials in Odoo lists components, quantities, and units of measure for one unit of finished product — and optionally operations, by-products, and subcontracting steps.

BoM type matters: normal BoMs drive MO component lines; phantom BoMs explode sub-assemblies without creating separate MOs; subcontract BoMs trigger vendor flows instead of in-house production.

Multi-level products need consistent UoM, revision discipline, and a decision on whether sub-assemblies are stocked, built on demand, or phantom-exploded. Configurators and custom modules extend BoM logic when option matrices explode.

Most manufacturing go-live delays trace back to BoMs copied from engineering exports without Odoo-specific rules for phantom kits, scrap, or alternate components. Planners then fight MOs that reserve wrong quantities or fail costing close.

This article explains how Odoo interprets BoM structure and what to fix before MOs run at scale.

Each BoM ties to one product (or variant) and lists component lines with quantity per finished unit. Operations and work centers attach when routings are enabled. By-product lines capture co-products or scrap you track explicitly.

BoM quantity defines the batch size the component quantities reference — for example a BoM quantity of 10 means component lines are per 10 finished units unless you normalize to per-unit in reporting.

  • Component products must be storable (or consumable where appropriate)
  • Units of measure must convert cleanly between purchase, stock, and BoM UoM
  • BoM type: manufacture, kit, or subcontract
  • Optional operations sequence for shop-floor steps

Single-level BoMs list raw materials and bought parts only. Multi-level BoMs include sub-assemblies as components — each sub-assembly may have its own BoM and MO when manufactured separately.

Phantom BoMs let you model engineering structure without generating a separate MO for the sub-assembly: components explode onto the parent MO. Use phantoms for logical groupings operators never stock as WIP.

Subcontract BoMs mark an operation performed at a vendor: Odoo moves components to a subcontract location and expects finished goods back against a service purchase. Component lists must match what you physically ship.

Kit BoMs (where enabled) auto-deliver component sets on sales — useful for light assembly businesses. Do not confuse kits with full MRP when you need consumption traceability on the shop floor.

Odoo supports BoM versioning through duplicate BoMs, effective dates, or PLM modules depending on edition and customizations. Without a process, open MOs may consume an old revision while engineering already released a new one.

Substitute components often need Customization or clear planning rules — standard BoMs assume fixed component lines unless you use optional modules or manual MO edits.

Standard cost on finished goods rolls up from component standard costs and routing times when configured. Wrong BoM quantities or missing components skew margin reports and production variances.

Link Development when costing requires custom roll-up logic or integration with an external PLM source of truth.

  • Normalize BoM quantity to one finished unit unless batch sizing is intentional.
  • Document phantom versus stocked sub-assembly rules per product family.
  • Validate UoM conversions on every component with purchase and inventory teams.
  • Pilot costing roll-up on one finished good before mass BoM import.
  • Assign an engineering owner for revision control and MO cutoff rules.
  • Cross-link Customization when configurators dynamically build BoM lines from sales options.

  • !Importing flat Excel BoMs without multi-level or phantom decisions.
  • !Using consumable products for tracked components that must appear on MO pick lists.
  • !Mixing weight and count UoM without conversion factors.
  • !Leaving default BoM on templates while variants need separate BoMs.
  • !Shipping subcontract BoMs without matching vendor component receipts.
  • !Duplicating BoMs per customer instead of using variants or configurators.

BoMs are the contract between engineering, planning, and the shop floor — structure them for how you actually build, stock, and subcontract.

Next, walk one product from BoM explosion through MO reservation to confirm quantities and UoM before bulk master-data load.

Multi-level BoM with phantom and stocked sub-assemblies labeled.
  • Finished good

  • Sub-assembly

  • Raw materials

  • Operations

  • fgsa
  • sarm
  • fgops
Normal vs phantom vs subcontract BoM behavior.
OptionBest whenTrade-off
ConfigureStandard Odoo covers the needLimited uniqueness
CustomizeDifferentiating workflowUpgrade cost
IntegrateExternal system of recordSync complexity

Frequently asked questions

One BoM per variant or one BoM on the template?

Use variant-specific BoMs when components differ materially by attribute. Shared structures can live on the template with variant attributes on lines where supported. Configurable products may need dynamic BoM generation — see the configurators article.

When should I use a phantom BoM?

When engineering groups parts logically but you never stock or schedule the sub-assembly as its own MO. Phantoms explode components to the parent MO and simplify picking.

How do I handle scrap in the BoM?

Increase component quantity to cover expected scrap, add explicit scrap products as by-products, or record scrap at MO completion. Pick one method per line so costing stays explainable.

Can I migrate BoMs from our old ERP?

Yes, with mapping for UoM, product links, phantom flags, and subcontract steps. Migration projects should reconcile open MOs and revision cutover dates before bulk load.

Cleaning up BoM master data?

Share a sample product tree and costing goals — we will review structure, phantom use, and migration approach.

Business technology and software delivery