BOM Explode-for-Purchasing: Turn a Multi-Level BOM into a Clean Buy List

The problem this kills

You've got a job to build — say 50 of an assembly — and now somebody has to figure out exactly what to buy. The bill of materials isn't a flat list; it's a tree. The top assembly is made of sub-assemblies, which are made of more sub-assemblies, which finally bottom out in real parts you purchase. Some of those sub-assemblies are phantoms — groupings that exist on paper but you never actually buy or stock; you buy their children. Some are make items you build in-house, not buy. And the same screw, the same connector, the same bracket shows up in five different branches of the tree, each with its own quantity.

So the buyer sits with a spreadsheet, expands each level by hand, multiplies quantities down — "2 per sub-assembly, 3 sub-assemblies per unit, 50 units" — tries to remember which lines are phantoms to skip, and then hunts for every place the same part appears so they can add the quantities up into one purchase. It's slow, and it's exactly the kind of arithmetic where one missed branch means you're short on the line, or one double-counted phantom means you over-buy. Multiply that across a real BOM with hundreds of parts and several levels, and a single explode-by-hand can eat an afternoon and still be wrong.

You don't need an MRP module to fix this. You can build the exploder yourself, this afternoon.

What you'll build

An internal web tool your planning and purchasing team logs into. You import your indented multi-level BOM (the CSV or Sheet you already have), with a make-vs-buy / phantom flag on each part. You pick the top assembly and type a build quantity. The tool walks every level of the tree, multiplies the quantities down each branch, drops the phantom and make sub-assemblies (keeping only the parts you actually purchase), and then rolls every appearance of the same component SKU into a single line with the total extended quantity you need to buy.

If you upload an on-hand stock snapshot, it'll subtract what you already have and show you the net quantity to order. The result is a clean, consolidated buy list — one row per purchasable SKU, with the extended required quantity and any on-hand offset noted. The buyer reviews it on screen, approves it, and clicks once to export a requisition CSV in the exact columns your purchasing system or ERP wants — ready to become a requisition or PO.

What's inside the Implementation Plan

The downloadable plan is a single markdown file you paste into an AI coding agent. It opens by interviewing you about your own BOM and purchasing process — how your BOM export is shaped, what you call each field, how a parent links to its child, how you flag phantom and make items, your typical and peak BOM depth and size, and your requisition export columns — and then it reads a short spec back for your thumbs-up before it builds anything. That's the difference between a tool shaped to your BOM and SKU conventions and a generic template you have to fight.

From there it walks the agent through the data model (BOM nodes, parent-child links, flags, build runs, and the exploded buy list), the importer, the recursive explosion engine that multiplies quantities down and collapses phantoms, the duplicate-SKU roll-up, the optional on-hand subtraction, the buyer review-and-approve screen, and the final requisition export. Every step ends with a ready-to-copy prompt. There's a full "No API yet?" path: BOM (and optional stock) CSV in, requisition CSV out — you never have to touch your ERP's API to ship.

The governance it includes (this is the point)

A buy list becomes real money the moment it turns into a PO, so the controls are the product. The plan builds them in: a login so only your team can use it; row-level security so each organization only ever sees its own BOMs and buy lists; a complete audit trail of who exploded what, at what quantity, who approved, and when; a hard human-approval gate so a buy list can't become a requisition export until a buyer signs off; and a duplicate guard keyed on the build run plus child SKU so the same run can't be exploded into the same requisition twice. Nothing gets exported until a person has reviewed the extended quantities and any on-hand offset.

Who it's for

Buyers, planners, and purchasing managers prepping a buy for a specific job or production run. If you can read your own indented BOM and explain which lines you actually purchase versus which are phantoms you skip, you can build this — no developer required.

You've got this — open the plan, paste the first prompt, answer a few questions about how your BOM is shaped, and you'll watch your first build quantity explode into a clean buy list.