Short answer: a 150% BOM is a single bill of materials for an entire configurable product family. It contains every approved option and variant, more than any one product needs. Configuration rules filter it down to a 100% BOM: the exact parts and quantities for one order. SAP calls it a super BOM. Others call it a configurable, variant, or overloaded BOM.
Why a configurable product needs one
A standard product has one parts list. A configurable product has a parts list per valid combination of choices, and that can be thousands of lists. Maintaining every combination as its own BOM does not scale: one engineering change would mean editing all of them.
The 150% BOM flips this around. You maintain one structure with everything in it, plus the rules that say which pieces apply when. The explainers from Tacton, Wabric, and GrabCAD all land on the same definition. So does the SAP variant configuration documentation for super BOMs, which describes non-variable parts used in every variant alongside variant parts selected by dependencies.
How a 150% BOM resolves to a 100% BOM
Three things work together:
- The master structure. Every component, module, and alternative the family can use, including ones that never appear together.
- Options and rules. The choices a buyer makes (size, glazing, finish) and the constraints between them: what is compatible, what is excluded, and what one choice forces elsewhere.
- Quantity logic. Formulas that turn dimensions into cut lengths, areas, and counts. Without them, made-to-size products cannot be resolved.
Feed one set of choices through the rules and you get the 100% BOM for that order. Here is a small invented example in the SingleBOM JSON shape:
{
"id": "bom.win.cw-440",
"kind": "configurable",
"options": {
"width_mm": { "type": "int", "min": 600, "max": 2400 },
"glazing": { "type": "enum", "values": ["double-clear", "low-e-argon-double", "triple"] },
"finish": { "type": "enum", "values": ["anodized-clear", "powder-black"] }
},
"graph": {
"nodes": [
{ "id": "frame", "item": "aluminum frame", "qty": "perimeter_m(width_mm, height_mm)" },
{ "id": "igu-double", "item": "IGU, double", "when": "glazing != 'triple'" },
{ "id": "igu-triple", "item": "IGU, triple", "when": "glazing == 'triple'" },
{ "id": "hinge-hd", "item": "heavy-duty hinge", "when": "glazing == 'triple'" }
]
},
"rules": [
{ "id": "r1", "if": "glazing == 'triple'", "then": "width_mm <= 1800" }
]
}Invented example, not a customer record. Choosing triple glazing selects the triple IGU and the heavy-duty hinge, and caps the width at 1800 mm.
150% BOM vs 100% BOM
| 150% BOM | 100% BOM | |
|---|---|---|
| Scope | Whole product family | One order or one variant |
| Contents | Every approved option and alternative | Exactly the parts for this build |
| Contains rules? | Yes, or is tied to them | No, rules already applied |
| Who reads it | Configurator, product management, engineering | Purchasing, MRP, the floor, billing |
| SAP term | Super BOM (configurable material) | Sales order BOM / order BOM |
Where 150% BOMs go wrong
The concept is sound. The trouble is almost always that more than one system holds its own 150% model.
The rules are written twice
CPQ has a configuration model for selling. ERP has object dependencies or its own configurator for building. They were written by different teams at different times. When a new option goes into CPQ but not into the ERP model, the quote can be accepted and then fail to resolve downstream. The "SAP CPQ BOM not exploded" thread on SAP Community is a typical example: the fix came down to which attributes and knowledge-base versions each side knew about.
Engineering changes hit one copy
An ECO that swaps a hinge updates the engineering 150% structure. The CPQ model still offers the old hinge's option, at the old price, until someone updates it by hand. Every copy of the 150% model is one more place an ECO has to land.
Sales, manufacturing, and billing resolve it differently
Even with one set of rules, each function may resolve its own projection: a sales BOM of priced options, a manufacturing BOM of parts and operations, invoice lines in billing units. If those projections are produced by different code from different copies, the same order can produce three slightly different 100% answers. That is the quote, MBOM, and invoice drift every configure-to-order company knows.
What to standardize
If you take one thing from this: the 150% model is the object worth getting right, and it should exist once. Concretely:
- One option vocabulary. The same option IDs and values in CPQ, the plant, and billing. No translation table between "Low-E Argon" and "IGU-LEA-2."
- One rule set. Selling rules and building rules live together. A combination that cannot be built cannot be quoted.
- Resolutions, not copies. The quote, the sales order BOM, the MBOM, and the invoice are each generated from the same configuration against the same model, and each records which model revision it came from.
- Function-owned fields. Sales owns price and lead time, manufacturing owns routing and plant, billing owns unit and revenue treatment. All of these are fields on one object, not separate objects.
This is the idea behind SingleBOM: a graph-style JSON standard for the configurable product that CPQ, PLM, ERP, and billing all read. It is not a new configurator, and it does not replace approvals, e-signature, tax, or payment. It gives the 150% model a single home so every 100% answer agrees.
A quick self-check
- Count how many systems hold configuration rules for your top product family.
- Pick one recent order and resolve it in each: quote lines, MBOM, invoice lines.
- Note every part, quantity, or line that differs, and which copy of the rules produced it.
If the count in step 1 is more than one, step 3 will not come back empty.