Configurator Bill of Materials: Making the Parts List Match the Build

A customer builds a shelving system in a 3D configurator, clicks buy, and the order arrives in the warehouse as a list of parts. The customer judges the picture on screen. The warehouse packs the list. For modular products, where connectors, brackets and fittings follow from how the modules are placed, the two have to describe the same product. Most of the work that makes them agree happens before launch, together with the people who know how the product is assembled.

What a configurator's bill of materials contains

The bill of materials (BOM) is the list of every item a configured product is made of: modules, connectors, fittings, legs, and fabric or finish codes, each with a SKU and a quantity. In most configurators the same list also carries total dimensions, price and lead time.

After the customer clicks buy, the rest of the business works from that list. It becomes the cart lines in the webshop, the order lines in the ERP, the pick list in the warehouse, and the summary in the PDF or email the customer keeps. Some brands also send a screenshot of the configuration with each order, so warehouse staff can compare the list with the picture. This is where a 3D configurator starts to overlap with quoting tools, which we look at in 3D product configurator vs. CPQ software.

How the configurator works out the parts from a 3D build

Modules the customer places are the simple part: one module on screen, one line on the list. The parts the customer never picks come from rules. In a tube-and-shelf system, the connector at each junction depends on how many shelves meet there. A shelf on one side of the tube takes a tee clamp. Shelves on both sides at the same height take a cross clamp. The configurator reads the geometry of the finished build, finds every junction and applies the rule. Modular sofas follow the same logic with brackets between modules, and lighting systems with couplers and end caps.

The second layer is the SKU. Many ERP systems compose a SKU from several dimensions, for example size, foam type, colour ID and style ID. The configurator assembles that code from the customer's choices in exactly the format the ERP expects, down to the separators.

Three things to pay close attention to

The combinations at the edges. Assembly rules are usually written with the typical build in mind. The combinations that deserve extra attention are the ones at the edges: shelves at slightly different heights on either side of a tube, a corner module next to an end module, the maximum width. A rule such as "cross clamp where two shelves meet at the same height" also needs a definition of "the same height" that matches how the system is assembled in practice.

Data that appears in several places. A colour or finish is often shown in the 3D view, the PDF and the summary email. When a new colour is added, all three need the update. A quick check of the 3D view confirms one of them, so the PDF and the email need their own look.

SKU conventions between systems. ERP and webshop systems each have their own conventions for SKU codes, including separators like hyphens. When the configurator passes a code to the cart, both sides have to read it the same way, or a variant can arrive as its base product with the base price.

How to test the bill of materials before launch

Looking at the 3D model confirms how the product looks. The parts list is confirmed by counting. A test round in four steps covers most of it:

1. Build the edge cases on purpose. Maximum width and height, every corner and end module, and the configurations where two rules meet.
2. Count the physical parts. Ask someone on the product team, ideally the person who packs or assembles orders, to write down what each test build needs, and compare it line by line with the configurator's list.
3. Check every output. Generate the cart, the PDF and the summary email for the same configuration. The same list appears in three places and has to be identical in all three.
4. Place a test order. Follow it into the ERP or order system and check that SKUs, quantities and prices arrive as sent.

Keep the test configurations as saved share links. When a rule or a product changes after launch, the same set can be run again in an afternoon.

What the brand needs to hand over

The rules behind the parts list belong to the brand, and most of them sit with the product team and the warehouse. Before the build starts, we ask for:

• The complete SKU logic, including how codes are composed and which separators the ERP uses.
• The connector and fitting rules for every junction type, written as "when X meets Y, use Z".
• A named person on the product team who signs off the test builds.
• Three to five real orders from the past year that were built and shipped, to use as reference builds.

The SKU documentation is the item we request first, because it is the one most likely to shape the scope of an integration. It belongs in the same early phase as the 3D files and product data, which our guide to the real timeline for launching a configurator before Q4 walks through week by week.

With the rules written down and the test builds counted, an order goes from the customer's screen to the warehouse exactly as it was configured.