Bill of Materials (BOM) Explained for Small Manufacturers
A bill of materials is the recipe your product is measured against — what a BOM contains, single-level vs multi-level, how it drives costing and purchasing, and why small manufacturers need one before they need machinery.
A bill of materials (BOM) is the complete, structured list of everything required to make one unit of a product: raw materials, components, sub-assemblies, packaging — each with its exact quantity. A bakery's BOM for a loaf lists flour, yeast, salt, and the bag it leaves in; a furniture maker's BOM for a chair lists timber by the meter, screws by count, varnish by the milliliter. It looks like documentation. It functions as a contract: the standard that production, costing, and purchasing are all measured against.
What a working BOM contains
- Components and quantities per unit of output — in the units you actually issue (kg, meters, pieces), including expected process loss where it is real (cutting waste, evaporation).
- Packaging — the bag, label, bottle, and carton are materials, not afterthoughts; leaving them off the BOM is how "profitable" products lose money at the till.
- Sub-assemblies (in multi-level BOMs) — a sauce that goes into three dishes, a frame that goes into four furniture items: costed once as its own BOM, consumed by the parents.
- Yield — what one run of the recipe produces (100kg of flour → 260 loaves), the denominator of every per-unit number.
- Version and effective date — recipes change; costing and variance analysis must know which version a batch used.
The three jobs a BOM does
| Job | How the BOM does it | What happens without it |
|---|---|---|
| Costing | Component quantities × current material costs = true unit cost, updating as prices move | Prices set by feel; margin discovered at year-end |
| Production control | Materials issued against the BOM; consumption variance per batch asks "why more?" | Open-door stores; leakage with perfect deniability |
| Purchasing | Production plan × BOM = exact material requirements, netted against stock | Buying by habit; stockouts and expiry at the same time |
Single-level vs multi-level
A single-level BOM lists direct inputs one layer deep — fine for simple products. A multi-level BOM nests sub-assemblies: the chair contains a frame, the frame contains timber. Multi-level matters when intermediates are shared, stocked, or made in batches — the sauce example — because it lets you cost and control the intermediate once instead of duplicating it inside every parent recipe.
BOM accuracy: the variance loop
A BOM is a hypothesis until production data confirms it. The loop that keeps it honest is the batch reconciliation: issue materials against the BOM, weigh what the run consumed and produced, and read the variance. Consistent over-consumption means the BOM is wrong (update it, and reprice) or the process is leaking (fix it). A BOM nobody reconciles against drifts into fiction within a quarter — and everything costed from it drifts along.
Starting from zero, this week
- Pick your top five products by volume and write their BOMs from a supervised production run — measured, not remembered.
- Cost them at current purchase prices (landed cost for imported inputs) and compare against selling prices. Expect at least one unwelcome surprise.
- Start issuing materials against the BOMs for those five products; run the variance report weekly.
- Add products at a relaxed pace; add sub-assembly levels only where intermediates are genuinely shared.
This is the same play whether the product is bread, furniture, animal feed, or a plated dish — where the BOM is called a recipe card. The full manufacturing context — yields, waste, quality holds, and traceability — is in the manufacturing ERP guide.
What AWRA OpsHub does today
- Landed cost on receipts — freight, duty, clearing and transport captured per purchase order, allocated across the lines by value or by quantity, written onto the batch and carried into the item's weighted average cost.
- Batch, lot and serial tracking — expiry date, supplier and originating purchase order recorded on every batch, with serial numbers where you need them.
- Quality holds that are enforced, not advisory — quarantined, inspection-pending, damaged, expired and returned stock is excluded from issuing and selling by the allocation query itself. Hold, release and dispose each record the quantity, the reason, a note and the person who did it.
- Batch traceability screens — per item, per batch and per serial: every inbound and outbound movement with its source document, total in, total out, and exactly where the remainder is sitting.
More we can add to your workspace
- A bill of materials. A BOM or recipe with a version and an effective date — the entity itself, which everything else in this article hangs on.
- A production order and an issue-against-recipe. Materials leave the store as a stock adjustment or a transfer, not as consumption measured against an expected quantity.
- A yield and a consumption variance. Expected-versus-actual is the entire point of a recipe, and there is nothing here to compute it from.
- Multi-level costing. A sub-assembly cannot be costed once as its own BOM and then consumed by a parent.
Read this as a method post, not a product post. You can hold your BOMs in a spreadsheet and still get real value from the layer underneath them — true landed input costs, batch tracking, and holds that stop suspect stock moving. What you cannot do here yet is have the system measure a production run against the recipe. If BOM-driven production is the thing you are actually buying, buy it from someone who has shipped it, or talk to us about building it — that is a real conversation, not a brush-off.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsIf you want the other half of this — not what a BOM is, but what actually happens to your material and your accounts when you run production without one — that is production without a bill of materials. It traces a single run through issue, output and journal, and it is blunt about which of the three the absent recipe costs you.
Build the layer underneath first
True landed input costs, batch and serial tracking, and enforced quality holds — the measurement layer a BOM sits on top of. The BOM itself is not built, and the page this goes to says so too.
See what is builtFrequently asked questions
How is a BOM different from a recipe or formula?
Same concept, different dialects: kitchens say recipe, process industries say formula, discrete manufacturing says BOM. The functional test is identical — exact inputs per unit of output, versioned, and used to issue, cost, and reconcile. Call it whatever your floor calls it; measure against it either way.
Should labor and overhead be in the BOM?
The BOM proper is materials; labor and overhead join at the costing layer (a routing, or simpler per-unit rates) to build full unit cost. Small manufacturers do well starting with material-only BOMs — materials are usually the biggest slice and the easiest to measure — and layering labor rates in once the material discipline holds.
How do we handle by-products in a BOM?
Record them as secondary outputs of the production run with their own stock and value — bran from milling, offcuts from joinery. Ignoring by-products overstates the main product's cost and invites the by-product revenue to leak off-book.
Our recipes vary with input quality (moisture, grade). Is a fixed BOM realistic?
Use the standard BOM as the baseline and let batch variance carry the reality: a wet-season maize batch consuming 4% more is a recorded, explained variance — not a reason to abandon the standard. If a variation is permanent, version the BOM. The standard is what makes the variation visible.
