The Bill of Materials in Supply Chain Management: From BOM to Purchase Order

What a BOM does on the buying side that it does not do on the shop floor

On the floor, a BOM answers “what goes into this unit and in what order”. In procurement it answers a harder question: what does this build commit us to buying, and by when.

• Quantities become financial. A line reading “gaskets: 4” is a note. Multiplied by a 250-unit run and a supplier minimum order quantity, it is a purchase decision.
• Dates enter the picture. The floor cares about sequence; purchasing cares about working days and lead times, counted backwards from the build start.
• Every component gains a supply position. Free stock, stock allocated elsewhere, quantities on open POs, and stock present but not booked in all change what you need to buy.
• The list becomes recursive. A sub-assembly is either bought or made from other bought things. Purchasing follows that all the way down.

The BOM is where dependent demand comes from: you order the part not because a customer asked for it, but because a parent item requires it. That is why it sits at the centre of purchasing.

BOM explosion: turning one build order into a shopping list

Explosion multiplies every line on the BOM by the quantity of the parent being built, then repeats that for every level below.

Microsoft’s Dynamics 365 documentation describes it plainly: a demand explosion of a BOM version “creates a demand for each BOM line item at a specific site and, possibly, at a specific warehouse”, and that demand “becomes the starting point for additional demand explosion”. The output of level one is the input to level two.

Two things go wrong here more than anything else.

Quantities entered against the wrong parent. Explosion assumes every BOM line is stated per one of its immediate parent, not per finished unit; state it per finished unit and the explosion doubles an already-doubled figure, so you buy double quietly and forever — the structuring rules that prevent it are in how to set up a multi-level BOM.

Warehouse and site. The explosion produces demand somewhere. A component sitting in finished goods rather than the production store is not available to the build — a constant trap for businesses with one building and three notional stock locations.

Gross to net: what you actually need to order

Gross requirements are what the build consumes. Net requirements are what you have to buy. The gap between them is your existing supply position.

Oracle’s MRP documentation gives the canonical arithmetic in its gross to net explosion example: gross requirements plus safety stock “represent the total demand”, scheduled receipts plus quantity on hand “represent the total supply”, and “the net requirements, total demand (150) minus total supply (130), equals 20”.

Net requirement = (gross requirement + safety stock) − (quantity on hand + scheduled receipts)

Four things routinely poison that calculation:

• On-hand that is not free. Stock allocated to another works order or a customer order is not available, but a stock report will happily count it.
• Scheduled receipts that will not land in time. A PO due three weeks after the build starts is supply, but not supply for this build. Netting must be time-phased, not totalled.
• Stock that exists physically but not in the system. Goods sitting in receiving and not booked in look like a shortage, so you buy again.
• Safety stock treated as usable. Netting to zero against a buffer you committed to holding is not a plan to build, it is a plan to consume your buffer.

Scrap and yield: why the BOM quantity is not the purchase quantity

A BOM says how much of a component ends up in the finished product. Purchasing needs to know how much goes into the process — a larger number wherever material is lost.

Oracle’s item and BOM attributes documentation defines component yield as “the percentage of a component on a bill of material that survives the manufacturing process”, and gives the adjustment: usage of 2 at a yield of 0.90 “is recalculated as 2 divided by 0.90, or 2.22”. Assembly shrinkage works the same way one level up — a planned order of 52 at 20% shrinkage becomes 52 ÷ (1 − 0.2) = 65.

Businesses recording neither compensate by buying “a bit extra” from memory — which holds until that person is on holiday, or until the extra becomes the new normal and nobody can say what real consumption is. Yield written on the BOM line makes the padding visible, auditable and correctable.

Lead time offsetting: when to order, not just how much

Knowing you need 1,000 gaskets is useless without the date. Time-phasing converts a requirement into an order date. Oracle’s time-phasing documentation puts it well: “Time-phasing delays release of orders for components until they are needed and offsets the requirements by item lead time (lead time offset).” Net requirements, once lot-sized and offset, become planned orders — and planned orders become purchase orders.

Order-by date = build start date − (supplier lead time + goods-in and inspection + your own approval time)

Three details make or break this:

• Working days, not calendar days. A 25-day lead time is five weeks, not three and a half. Bank holidays count: a build starting Tuesday 8 September 2026 sits behind the UK late-summer bank holiday on Monday 31 August, pushing every order-by date one working day earlier than a plain five-day-week count suggests.
• Cumulative lead time on multi-level structures. If a sub-assembly you make takes ten days and its longest-lead raw material takes forty, the real horizon for that branch is fifty.
• Internal latency is lead time too. A requisition sitting in an inbox for four days is four days you did not plan for.

Minimum order quantities, pack sizes and lot multiples

Suppliers do not sell in the quantities your BOM implies. Order modifiers reconcile the two, and they are where clean netting turns back into approximate buying.

Oracle’s order modifiers reference covers the common ones: with a fixed lot multiple, “when the fixed lot multiple quantity is 100 and the requirement equals 110 units, place a single order for 200 units”; minimum and maximum order quantities mean orders are placed “for at least the minimum quantity, but no greater than the maximum quantity”; and on rounding it warns the process “may suggest a planned order for more than what is actually needed. This extra quantity is carried over into the next period as supply.”

That last line is the whole problem. Every rounding decision leaves a residue. Managed, it is next month’s opening stock. Unmanaged, it is dead stock — awkward precisely because each individual decision was rational.

Hold four fields against every component: minimum order quantity, order multiple or pack size, price-break quantities, and shelf life. A twelve-month price break on a component with a nine-month shelf life is not a saving.

Worked example: 250 filter units, exploded into purchase orders

A countertop water filter unit, batch of 250, build starting Tuesday 8 September 2026. Figures are illustrative; the arithmetic is the arithmetic.

Step one — quantities.

The gasket line is the one to study: 4 per unit at 90% yield is 4 ÷ 0.9 = 4.44, so 1,112 gross rather than 1,000. Netting takes it to 812; a 500-unit bag size takes it back up to 1,000. Three rules, one number, 188 gaskets left over on purpose. Note too what generated no PO: fixings were already in stock, and cartridges needed 500 but 180 on hand plus a 200-unit PO landing in time cut the order to one MOQ.

Step two — dates. Two working days for goods-in and inspection, counted back from 8 September in working days, with the Monday 31 August bank holiday taken out.

Two lessons. The imported cartridge had to be ordered in July for a September build — by the time the works order is raised, that decision is already made or already missed. And the order-by dates are nowhere near each other, so “raise the POs for the September build” is not one task but six, spread over six weeks. Batch purchasing into a single weekly session and you expedite the long-lead items by default.

What a wrong BOM quantity actually costs

The failure is asymmetric, and both ends are expensive in different ways.

Under-stated quantity → shortage. Say the gasket line reads 4 but the build uses 5, because a second seal was added and never written down. Across 250 units that is 250 gaskets short. At roughly £0.35 each the parts are worth about £88 — and they stop a run of a product worth hundreds of pounds a unit. The real cost is expedite freight, a resequenced schedule and a late delivery, not the parts.

Over-stated quantity → dead stock. Say the cartridge line reads 2 and the product ships with 1. You buy 250 cartridges you will never consume. At £4.20 each that is £1,050 on a shelf, and because it is a stocked item it looks like healthy inventory rather than a mistake. It surfaces when someone counts, or when the shelf life expires.

Three properties make BOM quantity errors worse than most data errors:

• They multiply. The error is per unit; the damage is per unit × batch size.
• They repeat. Nothing self-corrects; the same wrong figure fires on every run until a human notices.
• They hide inside variance. Over-consumption reads as “shop floor waste”, under-consumption as “we always seem to have spares”.

The control is boring: reconcile issued quantity against BOM quantity at the end of every works order, and treat a persistent gap as a BOM defect rather than a floor discipline problem.

Where BOM-driven demand meets reorder points

There are two legitimate ways to decide when to buy something, and confusing them causes double ordering.

Dependent demand comes from the BOM: you need the part because a build needs it, on a known date, in a known quantity. Planned, time-phased, lumpy.

Independent demand is forecast: you need the part because history says you will. Managed with a reorder point, a min/max level or a two-bin system.

Most growing manufacturers run both — high-value, long-lead, product-specific items planned from the BOM, low-value consumables like fixings and tape on reorder points because planning them individually costs more than the parts are worth. The mechanics of setting those trigger levels are in the reorder point system guide.

The rule that matters: each component gets one method, not both. A part exploded from a BOM and sitting on an automatic trigger gets bought twice, and the surplus looks like ordinary stock. Move an item onto BOM-driven planning and turn its trigger off the same day.

From planned order to purchase order

Everything above produces a planned order — a recommendation with a quantity, a supplier and a date. Turning it into a commitment is where most leakage happens, because that is where the process leaves the system and enters people’s inboxes. The chain should run: planned order → requisition → approval → purchase order → acknowledgement → goods received → three-way match → payment.

Failure points worth auditing:

• No feedback from receipt back to the plan. Goods arrive short or late, the works order is not replanned, and the shortage is found by the person picking the job.
• Approval latency treated as free. If POs take three days to sign, every lead time in your system is understated by three days.
• Confirmed dates never captured. You ordered for the 8th, the supplier acknowledged the 15th, nothing in the plan knows. This is the most common cause of a build starting with a hole in it.
• Part numbers that do not match. The BOM says one thing, the supplier catalogue another, and the reconciliation lives in a buyer’s head.

The tracking side in detail is the purchase order tracking system guide.

Why spreadsheets stop coping here

A spreadsheet can hold a BOM. It struggles with the buying layer for structural reasons: it cannot net against live stock, does not know what is allocated, will not re-explode when the build quantity changes, has no calendar to offset lead times against, and cannot tell you a supplier moved a date. So netting happens mentally, padding by instinct, and the audit trail is a folder of emails.

For businesses too messy for spreadsheets but not ready for a full ERP, the right-sized version is simple: one product record with a live BOM, stock positions that distinguish free from allocated, supplier records carrying lead time and MOQ, and an explosion that produces a dated buying list you can approve. An owned operations system shaped around how you actually buy.

FAQ

What is a bill of materials used for in supply chain management?

It is the source of dependent demand. Exploded against a production plan, the BOM tells purchasing which components are required, in what quantity and by what date, which is what makes it possible to buy to a plan rather than a hunch. It also underpins costing, supplier allocation and the shortage checks that decide whether a build can start.

What is the difference between gross and net requirements?

Gross requirements are the total quantity a build consumes, straight from the exploded BOM. Net requirements subtract what you already have or have coming — quantity on hand and scheduled receipts — and add anything you must protect, such as safety stock. Only the net figure should become a purchase order, and only after lot sizing and lead time offsetting.

How does the BOM connect to purchase orders?

Four steps: explode the BOM against the build quantity for gross requirements; net those against free stock and in-time open orders; adjust for yield and scrap, then round to the supplier’s MOQ or pack multiple; offset backwards by supplier lead time for an order-by date. The output is a planned order, which becomes a requisition and then a PO.

Should every component be planned from the BOM?

No. High-value, long-lead or product-specific items are worth planning from the BOM because the accuracy pays for the effort. Low-value consumables are cheaper to manage on a reorder point or a two-bin system. Each component uses one method only — an item planned from the BOM and sitting on a reorder trigger will be bought twice.

Sources

• Microsoft Learn — Explosion of a BOM version, Dynamics 365 Supply Chain Management — how demand explosion creates site- and warehouse-specific demand for each BOM line.
• Oracle MRP — Gross to Net Explosion Example — net requirements as total demand minus total supply.
• Oracle MRP — Time-Phasing Requirements — lead time offsetting and delayed component order release.
• Oracle MRP — Item and Bill of Material Attributes — component yield and shrinkage rate, and how each inflates planned quantities.
• Oracle MRP — Order Modifiers — fixed lot multiples, minimum and maximum order quantities, and rounding.