You sell a coffee gift box on bol.com. Inside it: one grinder, two bags of beans, a wooden box and a printed card. All four of those items also sell separately, across three other channels.

How many gift boxes can you safely list?

Most sellers guess. They pick a number that feels safe, list 20, and adjust when something goes wrong. That works until the day one component runs out and four listings go dead at once, on the marketplace where availability drives ranking.

An assembly is a product that exists only because other products exist. Its stock level is not a number you store. It is a number you calculate, continuously, from everything underneath it. Get that calculation wrong and you either oversell or leave revenue on the table. There is no third outcome.

This article covers how assemblies and bills of materials actually work in a multichannel e-commerce operation: the math, the edge cases nobody warns you about, and how to run them without a spreadsheet.

What an assembly and a BOM actually are

An assembly (also called a bundle, kit, or set) is a sellable SKU built from other SKUs. The bill of materials, or BOM, is the recipe: which components go in, and how many of each per finished unit.

Our coffee gift box has a simple, single-level BOM:

• 1 × Grinder (SKU GR-100)
• 2 × Beans 250g (SKU BN-250)
• 1 × Wooden box (SKU BX-01)
• 1 × Gift card (SKU CD-01)

The important words are per unit. The BOM defines the ratio, not the total. Two bags of beans go into every box, so beans are consumed twice as fast as grinders. That factor of two is where most manual calculations quietly break.

Multi-level BOMs

A component can itself be an assembly. If your "Beans 250g" SKU is really bulk beans plus a bag plus a label, you have a multi-level BOM: the gift box depends on a sub-assembly, which depends on raw components.

Availability then has to cascade upward through every level. In practice, most e-commerce sellers stay single-level and are better off for it. Add depth only when the sub-assembly is genuinely sold on its own.

The core formula: availability is a constraint

Here is the calculation that matters more than any other in this article.

Bundle available = MIN over all components of FLOOR(component available ÷ quantity per bundle)

Your bundle availability is set by the scarcest component. Not the average, not the total, and not the one you thought of first.

Take real numbers. You have 40 grinders, and each box needs one, so grinders allow 40 boxes. You have 90 bags of beans and each box needs two, so beans allow 45 boxes. You have 25 wooden boxes, allowing 25. You have 500 gift cards, allowing 500.

MIN(40, 45, 25, 500) = 25 gift boxes.

You have 500 cards and 40 grinders, and none of it matters. Twenty-five wooden boxes cap the whole thing. If you had listed 40 based on the grinder count, you would have oversold by 15 units, and on bol.com or Amazon that means cancellations, a damaged performance score, and a listing that stops ranking.

Note the FLOOR. Ninety bags of beans divided by two is a clean 45, but 91 bags is still 45 boxes. Half a bundle is not a sellable unit, and rounding up is how phantom stock enters your system.

Available is not the same as on hand

One more layer. The number you feed into that formula should never be raw on-hand stock:

Component available = on hand − reserved − buffer stock

Reserved covers units already committed to open orders. Buffer stock is the safety margin you deliberately hold back per channel. Both reduce what an assembly can claim.

And here is the trap: buffer stock gets multiplied by the BOM quantity. Hold back 10 bags of beans as buffer and you have removed 5 gift boxes from availability, not 10. Sellers who set buffers at component level and then wonder why bundle availability dropped further than expected are usually meeting this multiplier for the first time.

Virtual versus physical assemblies

There are two fundamentally different ways to run an assembly, and picking the wrong one for your fulfilment setup causes more damage than any formula error.

Virtual assembly, built on demand

The bundle has no stock of its own. It exists as a definition. All stock lives at component level, and the deduction happens the moment an order comes in:

On sale: for each component, stock −= (BOM quantity × units ordered)

Your picker grabs the four items and boxes them at pack time. Availability is recalculated live from the components.

This is the right model when you fulfil from your own warehouse, when your bundle composition changes with the season, or when you run promotional sets that exist for six weeks. You are not committing physical inventory to a configuration you might regret in November.

Physical assembly, pre-built

You build 30 gift boxes on a Tuesday. Components leave stock, and the assembly enters stock as a unit with its own barcode and EAN:

On build: component stock −= (BOM quantity × build quantity), assembly stock += build quantity

From that moment on, the assembly behaves like any ordinary product. Its availability is a stored number, not a calculated one.

This is mandatory when a third party fulfils for you. Amazon FBA and bol.com LVB warehouses do not assemble anything. They pick what is on the shelf. If you want a gift box shipped from a fulfilment centre, a physical gift box with its own EAN has to be sitting there.

Choosing between them

Go virtual when you ship from your own warehouse, when compositions change often, and when you want maximum flexibility on what you offer. Stock stays at component level and nothing is locked into a set.

Go physical when a fulfilment partner ships for you, when the bundle sells in high volume and you want to batch the labour, or when the set needs its own EAN for a marketplace listing.

Many sellers run both at once for the same product: virtual for their own webshop and B2B orders, physical for the units shipped into FBA or LVB. That works fine, as long as your system understands that the pre-built units are no longer available to the virtual bundle.

The shared component problem

This is the point where a real inventory system separates itself from a spreadsheet.

Add a second bundle. A "Starter set" containing 1 grinder and 1 bag of beans. Both bundles now claim the same grinder pool.

The gift box is available 25 times, capped by wooden boxes. The starter set is available 40 times, capped by grinders. And the grinder itself is listed standalone on three channels at 40.

You are now advertising 25 + 40 + 40 = 105 units of demand against 40 physical grinders.

That is not automatically overselling. Most of those listings will never all sell out. But it becomes overselling the instant one sale is not propagated everywhere else.

Every component mutation must recalculate every assembly that uses it, and push the result to every connected listing.

Sell one starter set and the grinder drops to 39, the beans to 89. The gift box is still capped at 25 by the boxes, so nothing changes there. Sell fifteen starter sets and the grinder pool hits 25. Now the gift box is jointly capped, and the sixteenth starter set has to reduce gift box availability too.

Doing this by hand across four channels is not slow. It is impossible. The recalculation has to happen on every mutation, and the mutation rate goes up with every channel you add.

One component out, many listings dead

The compounding damage is the real cost. When the wooden boxes run out, you do not lose one listing. You lose the gift box on bol.com, on Amazon, in your Shopify store, and in your B2B portal, all in the same minute.

On marketplaces, going to zero is not a pause. Bol.com and Amazon both use availability and delivery reliability as ranking inputs. A listing that drops out of stock loses position, loses the buy box, and does not recover the moment you restock. You pay for that outage twice: once in lost sales during the stockout, once in a slower ramp after it.

A shared component that sits in four bundles is a single point of failure for five listings. Treat it accordingly.

Cost price of an assembly

A bundle's cost price is not something you type in. It rolls up:

Assembly cost = Σ (component cost × BOM quantity) + assembly labour + packaging

For the gift box: the grinder costs €18.50, the two bags of beans €8.40 together, the wooden box €3.10, the gift card €0.25, and assembly labour €1.50.

Total cost: €31.75

Sell at €59.95 on bol.com, with roughly 15% commission (€8.99) and €4.95 shipping:

Margin = €59.95 − €31.75 − €8.99 − €4.95 = €14.26, or 23.8%

Now imagine your system carries the bundle at a purchase price of €0, because nobody ever bought a "gift box" from a supplier. Your margin report shows 74%. You scale the bundle, push it in ads, feature it on the homepage, and you are scaling your least profitable SKU while believing it is your best.

This gets worse when component costs move. A supplier raises bean prices by 15% and every bundle containing beans silently loses margin. If cost rolls up automatically from the BOM, you see it the same week. If it does not, you find out at the year-end.

Multi-warehouse: components must be in the same place

Availability is not global. It is per location.

Bundle available (per warehouse) = MIN over components of FLOOR(available in that warehouse ÷ BOM quantity)

You cannot build a gift box from a grinder in Utrecht and a wooden box sitting at your 3PL in Venlo. If your Utrecht warehouse holds 40 grinders and 0 boxes while the 3PL holds 0 grinders and 25 boxes, your true buildable quantity is zero, even though a naive global sum says 25.

This matters most when you sell from multiple locations per channel: own warehouse for the webshop, FBA for Amazon, LVB for bol.com. Each fulfilment path needs its own availability calculation, based on the components physically present in that location.

Returns, restocking and disassembly

A returned bundle comes back as one physical box. You have two choices, and both need to be recorded.

You can restock it as an assembly. The box is intact and resellable, so assembly stock increases by one. This is only valid for physical assemblies.

Or you can disassemble it and return the components to stock, which means component stock += BOM quantity for each line. Now the grinder and beans are available for standalone sale again, and every bundle using them recalculates upward.

The failure mode is doing this physically but not digitally. A returned gift box gets opened, the beans go back on the shelf, nobody records anything, and your bean count is off by two forever. Repeat that a few dozen times over a year and your reorder suggestions are built on fiction.

Every one of these movements should land in a mutation log you can filter and trace. When a count comes out wrong six weeks later, that log is the difference between finding the cause in two minutes and writing off the discrepancy.

Purchasing: never reorder a bundle

Reorder suggestions calculated on bundle sales alone will under-order every component. Demand has to flow down through the BOM:

Component demand = standalone sales + Σ (assembly sales × BOM quantity)

Say beans sell 60 units standalone per month, the gift box sells 20 (2 bags each), and the starter set sells 35 (1 bag each):

60 + (20 × 2) + (35 × 1) = 135 bags per month

If you forecast on standalone sales only, you order for 60 and run out in the second week. The stockout then takes down the beans listing, the gift box, and the starter set simultaneously.

Layer supplier lead time on top and the exposure is obvious. With a six-week lead time on beans, your reorder point is roughly 135 ÷ 30 × 42 ≈ 189 bags, plus safety stock. Component-level forecasting is not a nicety here. It is the only version that produces a number you can act on.

How Stockpilot handles this

Stockpilot manages assemblies end to end, from BOM definition through to live marketplace listings.

Define the BOM. Under Inventory > Bundles you create a bundle and add its components with a quantity per unit. That definition is the single source of truth for availability, cost roll-up and stock mutations.

Connect the bundle to listings. A bundle connects to sales channel listings the same way a single item does, across 100+ integrations including bol.com, Amazon, Kaufland, Shopify, WooCommerce and Magento. Once connected, Stockpilot keeps the listing's stock level current every time any component in the bundle moves, whether it was sold, received, counted or adjusted.

Automatic mutations. Sell a bundle and all individual components are deducted instantly, in the BOM ratio. No manual adjustment, no nightly batch, no spreadsheet reconciliation.

Buffer stock per channel. Set a safety margin per channel and it is applied to the component availability that feeds every bundle calculation, so aggressive marketplace listings cannot eat the stock your webshop depends on.

Multi-warehouse per channel. Stock in your own warehouse, at a fulfilment partner, and at FBA or LVB is visible in one overview, with per-channel warehouse assignment. Bundle availability is calculated from the components in the location that will actually ship the order.

Full mutation history. Every stock change is logged with what happened, when and why. When a bundle count looks wrong, you trace it back to the mutation instead of guessing.

Component-level purchasing. Purchase orders and reorder suggestions run on your components, based on sales velocity across all your channels, including the demand your bundles generate.

B2B and warehouse support. Bundles are orderable through the B2B portal, and the pick-and-pack module with barcode scanning handles the physical side of assembling them.

The takeaway

An assembly is not a product with a stock level. It is a claim on other products, recalculated on every mutation, constrained by its scarcest component, and duplicated across every channel where you list it.

That is trivial to describe and impossible to maintain manually past a handful of SKUs. The failure is never dramatic either. No alarm goes off. You just quietly oversell, quietly under-order, and quietly lose marketplace position on listings you thought were healthy.

Bundles are one of the highest-margin moves in e-commerce. They raise average order value, move slow stock, and create products your competitors cannot price-match. That upside only survives if the stock math underneath them is correct every second of the day.

Get the BOM right, let the system do the arithmetic, and sell the bundle with confidence.

‍