---
title: Build a bill of materials
summary: >
  A bill of materials is the parts list for one built product. Open the
  product, add each component with the quantity needed per finished unit,
  and save — the list saves as one piece, not row by row. Components must
  already exist as products. Saving moves no stock; it tells Mossery how many
  units you could build from what is on the shelf right now.
type: task
group: make
step: 4
permission: products.manage_bom
prerequisites: []
related:
  - /help/make/product-types-and-stock-modes
  - /help/make/run-an-assembly-order
  - /help/make/the-three-numbers-of-a-built-product
last_updated: 2026-08-07
---

**A bill of materials is a recipe.** It says what goes into one finished unit,
and how much of each.

Write the recipe once and the app can answer a question you would otherwise
answer by walking the shelves: how many of this could we build today. That
number appears next to the product, feeds the build queue, and is part of what
your storefront is told you have.

This page covers:

- [What a bill of materials is](#what-a-bill-of-materials-is)
- [Before you start](#before-you-start)
- [Add the components](#add-the-components)
- [Sub-kits and the depth limit](#sub-kits-and-the-depth-limit)
- [What saving changes and what it does not](#what-saving-changes-and-what-it-does-not)

## What a bill of materials is

One parent product, and the list of components one unit of it consumes.

Only a **built** product has one. Every product carries an inventory type, and
the parts list appears only when that type is set to built — a plain stocked
product holds units and has no recipe, and a service holds nothing at all. If
the components panel is missing, the product's type is the first thing to check.

Each line is a component and a quantity per finished unit. A gift set made of
one notebook, two pens and one sleeve is four lines, with quantities 1, 2 and 1.

Two extra things a line can carry:

- **Wastage.** A percentage added on top, for the share of material that gets spoiled in the making. A line with quantity 2 and 5% wastage consumes slightly more than 2 per unit, always rounded up.
- **Notes.** Free text for the person who reads the recipe next.

## Before you start

Every component has to exist as a product first.

The component picker searches your catalogue and offers nothing else. There is
no "add it anyway" escape hatch, and a bulk import rejects any row whose
component code is not in the catalogue. This is deliberate: a parts list that
names something the app has never heard of cannot be counted, costed or built.

So before you open the editor, have:

- The parent product, with its inventory type set to built.
- Every component already created, each with its own product code, for example `SKU-001`.
- The quantity of each component that one finished unit consumes.

If a component is missing, create it as a product first, then come back.

## Add the components

1. Open the product and find the components panel. From the **Bill of Materials** page you can also open any built product straight into its editor.
2. Click **Add component**. A search box appears — type a product code or a name and pick from the results.
3. Set **Qty needed**. This is per finished unit, not per batch. Two pens in one gift set is 2, whether you build one set or a thousand.
4. Repeat for every component. Each component may appear only once, so combine duplicates into a single line rather than adding two.
5. Click **Save BOM**.

Alongside each line the editor shows the component's type, its unit cost, and
how much of it is on hand and available. Those columns are read-only. They are
there so you can see immediately whether the recipe you just wrote is one you
could actually build.

The whole list saves at once. There is no per-row save — the button replaces
every line in one go, so a half-written list never lands. Remove a row and save,
and that component is gone from the recipe.

### Importing many at once

For a large catalogue there is a **CSV import** on the Bill of Materials page.
One row per component line, with columns for the parent code, the component
code, the quantity required, the wastage percentage and a note. Same rules
apply: an unknown component code is rejected rather than quietly skipped.

## Sub-kits and the depth limit

A component can itself be a built product. That is a sub-kit, and it is normal.

When it happens, the app counts the sub-kit twice over: the finished sub-kits
sitting on the shelf, **and** the ones that could still be built from their own
parts. A sleeve line backed by 20 finished sleeves and the parts for 60 more
supports 80 parents, not 20.

Three rules keep the tree sane, and all three are checked when you save:

| Rule | What happens if you break it |
| --- | --- |
| A product cannot contain itself | Save is refused |
| A component cannot already contain the parent, at any depth | Save is refused as a circular reference |
| A chain may be at most six products deep | Save is refused as too deep |

Six levels is a lot. If you are pressing against it, the model is usually
telling you that two of the middle layers are the same idea.

One more thing decides whether a component limits you at all. A component set to
build on demand holds no stock by design, so it never caps the count. If every
component on a recipe is on demand, the product reads **Always available**
instead of a number.

## What saving changes and what it does not

Saving a parts list moves no stock. Not one unit.

What it changes is what the app believes. Immediately after you save:

- The product gets an **assemblable** figure — how many complete units the components on hand could produce right now.
- The **limiting component** is named: the one line that runs out first. Restocking anything else changes nothing.
- The product is bucketed on the Bill of Materials page as blocked, constrained by stock, always available, or missing a parts list entirely.

That assemblable figure is location-aware, and this catches people out. The
components have to be in the same place as each other for the count to be real.
Twenty sleeves at a retail counter and twenty notebooks at your main warehouse
build nothing, because nobody is assembling at either end with half the parts.

Stock only moves when someone actually builds — that happens on an assembly
order, not here. And a built product is always three numbers, not one: the units
already built, the units its components could still make, and what is left over
after what is already promised to orders. The house way of saying it out loud is
"we have 25 in stock, and the components to assemble 50 more."

## Explore

**Running the build.** The parts list is the plan; an assembly order is what
actually consumes components and puts finished units on the shelf.
[Learn more →](/help/make/run-an-assembly-order)

**The three numbers.** Why a built product reports on hand, assemblable and
available separately, and which one your storefront sees.
[Learn more →](/help/make/the-three-numbers-of-a-built-product)

**Types and modes.** Which products get a parts list at all, and what "on
demand" does to the count.
[Learn more →](/help/make/product-types-and-stock-modes)