Bills of materials on Shopify, without the ERP

A bill of materials is the recipe for something you make: every component and raw material that goes into one finished unit, with the quantity of each, including sub-assemblies that have recipes of their own. It is what turns a count of finished goods into a picture of what you are able to build and what building it costs you.

If you make what you sell, whether that is candles, furniture or kits assembled from parts, Shopify tracks one number for you: how many finished units are on the shelf. The parts that went into them are tracked somewhere else, usually a spreadsheet or the head of the person who does the ordering.

That arrangement holds up until you need to answer three questions:

What does one of these cost us to make?
How many could we build right now, from what we have?
What do we need to buy before the next batch, and when?

A spreadsheet can answer each of them if someone sits down and works it out. It cannot keep the answers current, and it cannot move your Shopify inventory when you finish a batch. A bill of materials can do both. The term usually comes attached to a lot of ERP you may not need, so here is what it covers on its own.

What a bill of materials is

A bill of materials (a BOM, or a recipe) is the list of what goes into one unit of a finished product, with a quantity per unit: one board deck, one binding hardware kit, 120 grams of epoxy. A BOM is only useful if:

Quantities are decimals, in real units. Nobody uses “1 resin”. They use 120 g, or 0.25 of a sheet. A BOM that only counts whole items makes you invent fake units and do the conversion in your head.
Components can have recipes of their own. The hardware kit is itself assembled from bolts and plates, so it is a finished product at one level and a component at the next.
Not every line limits a build. Packaging you never run out of belongs on the recipe for costing, but it should not drag the can-build count to zero because someone forgot to count the boxes.

Question one: what does it cost to make

An assembled cost is the BOM rolled up: each component’s cost times its quantity per unit, added together, plus whatever labor and overhead you choose to add.

Component cost should be landed cost. If the epoxy came in on a pallet with $180 of freight and a duty charge, the resin’s unit cost is the invoice price plus its share of those charges, the same way you would work out landed cost for anything you resell. An assembled cost built on supplier list prices understates the cost of every product you make.

The cost has to be fixed per build. Prices move. If the resin costs 12% more next quarter, the boards you made this quarter did not get more expensive. A spreadsheet that recomputes from current prices says they did, and your margin history changes every time a supplier sends a new price list. A build should record what its components cost on the day, and that cost should stay on the batch.

Question two: how many can we build

This one is arithmetic. For each component that limits a build, divide what you have by how much one unit needs. The smallest answer is how many you can build. Fourteen decks, two hardware kits and 2,400 g of resin at 120 g per board means two boards. The kits are the limit, however much resin you have.

The question is what “have” means once builds are in progress. If one open build has already claimed three kits, the next build on the same parts should show that shortage instead of both builds counting the same stock.

Question three: what do we need to buy

This is where a BOM becomes part of how you replenish. There are two cases:

Make to stock. A product you build should be replenished the same way as a product you buy, from sales velocity and a reorder point, except the suggestion is a build instead of a purchase order. The components those builds will need then belong in the buy plan as lines of their own, for example “needed for builds: 2,400 g of resin”. Resin never sells on its own, so it has no sales history to trigger a reorder.
Make to order. When a customer orders something you build and you do not have it in stock, the build should be created from the order, with the quantity, location and due date filled in, so nobody has to copy numbers across.

The build: moving stock both ways at once

Finishing a batch is the part that has to work. Components go down, finished goods go up, and both should happen in one movement, on the same document, with a reference your inventory history can show later. A spreadsheet cannot do this. A “bundle” or “kit” feature that only deducts on sale does it at the wrong time. A second inventory system that syncs to Shopify on a timer does it late.

Real production also has a gap between taking parts off the shelf and finishing the product, which is work in progress. Issue the components when the job starts, record what you made when it ends, including scrap and yield, and return what you did not use. That way the stock picture is right during the build as well as at the end.

What you do not need an ERP for

An ERP gives you routings, work centers, capacity scheduling, shop-floor timers and an MRP run that pushes demand through every level of every recipe over a planning horizon. If you run a production line with operators clocking onto operations, you need that, and it is priced accordingly.

Most Shopify makers need less than that: a recipe, a cost that stays fixed per build, a can-build count, a build that moves the stock, and demand that triggers the next build. Buying an ERP to get those usually means running a second inventory that Shopify cannot see. It syncs back on a schedule, and your sellable stock in Shopify is always a little behind.

Whatever tool you look at, check two things: does your finished-goods inventory stay in Shopify, and does it move when you finish the batch?

Where Stockroom stands

Stockroom covers that shorter list inside Shopify: bills of materials with decimal quantities and units, materials kept as draft, unsellable Shopify products counted in grams and metres, an assembled cost from landed component costs, a can-build count, builds that issue components into work in progress and record runs with yield and scrap (one Shopify inventory adjustment per run), and production planning that turns reorder suggestions and customer orders into builds and puts the components into the buy plan. Manufacturing is in early access and free, like the rest of the app. Stockroom does not do routings, capacity or shop-floor timing.