What is CPQ BOM reconciliation?

It is the work of checking that the bill of materials implied by a CPQ quote matches the manufacturing BOM the plant builds from and the lines that end up on the invoice, then fixing whichever one is wrong.

Does CPQ create the manufacturing BOM?

Some CPQ tools can. Oracle CPQ maps a configuration to sales and manufacturing BOMs, and some CPQ products create the production BOM in the ERP from an accepted quote. Many companies still re-key it, or have engineering rebuild it from the quote PDF.

Why does the CPQ BOM not match the ERP BOM?

The usual causes are separate item masters for sales and manufacturing items, configuration rules maintained in two places, an engineering change that reached ERP before CPQ, a quote revision that never became a BOM release, and invoice lines priced in different units than the build.

Can an integration fix BOM reconciliation?

An integration moves data faster, which narrows the window for drift. It does not decide which system owns each field, so the same disagreements come back after the next engineering change.

What does SingleBOM do here, and what does it not do?

SingleBOM is one JSON product model that CPQ, PLM, ERP, and billing read from, so the quote, MBOM, and invoice are views of the same object. It does not replace the CPQ process itself: approvals, e-signature, tax, and payment stay in your existing tools.

CPQ BOM reconciliation: why the quote and the build disagree

Short answer: CPQ BOM reconciliation means proving that what sales quoted, what the plant builds, and what finance invoices are the same product. It is needed because those three usually live in three systems, each with its own copy of the product. Reconciling is fixing the copies after they disagree. Avoiding it means not keeping separate copies to begin with.

Where the "CPQ BOM" comes from

Every CPQ tool holds some version of the product structure, and they call it different things. In Salesforce CPQ it is a bundle of product options. Oracle CPQ keeps a configuration BOM instance, stored as a JSON object, and maps it to a sales BOM and a manufacturing BOM through BOM mapping. Some CPQ products can create the production BOM in SAP from an accepted quote or push BOMs and routings into Dynamics.

Whatever it is called, the sales side is a structure built for exploration: what can be sold, with which options, at what price. The ERP side is built for execution: what to buy, what to build, and in what order. Reconciliation is the gap between the two, plus billing.

Five places the quote and the build split

1. Sales items are not manufacturing items

The quote line says "Cascade 440, 1400 × 2100, low-E argon glazing." The MBOM says frame extrusion, cut lengths, IGU, hardware set, sealant, and packaging. The mapping from one to the other is a set of rules. Those rules are product knowledge, and they often live in a script, a table, or one person's head.

2. The rules live in two places

CPQ has configuration rules that decide which options are valid. ERP often has its own: object dependencies in SAP variant configuration, or a configurator in the ERP. When an option is added in one and not the other, the quote can sell a combination the BOM explosion cannot build, or the reverse.

3. An engineering change reached one system first

An ECO updates PLM and then ERP. The CPQ model, the pricing, and the quote templates get updated later, when someone notices. Tacton describes the same ECO forcing updates across CPQ, PLM, ERP, and MES. Every update is a chance to miss one.

4. The quote revision never became a released BOM

A recent r/LeanManufacturing thread describes this one: the rep approved the quote, ERP never created the engineering release, and the shop built from last revision's parts list out of an email PDF. The poster's question was how to tie the approval to a quote revision ID and a released BOM, so that "approved" means something the floor can build.

5. The invoice speaks a different unit

The quote prices a window "each." The MBOM consumes extrusion by the meter and sealant by the tube. The invoice may split hardware onto its own line, or bundle installation, or recognize revenue differently from what the quote implied. None of these is wrong on its own. They become wrong when nobody can trace an invoice line back to the quote line and the build it came from.

A one-product reconciliation you can run this week

Before buying anything, measure the drift on one product. You need three files:

The quote, or a CPQ export of one closed order.
The manufacturing BOM the plant used for that order.
The invoice or sales order for the same order.

Then compare them on five things:

Check	Question to answer
Identity	Can every quote option be traced to MBOM lines, and every MBOM line back to an option or a base item?
Quantity and unit	Do quantities agree once units are converted? Who owns the conversion?
Revision	Was the MBOM revision the one that was current when the quote was accepted?
Price to build	Is every priced line backed by something built or bought? Is anything built that was never priced?
Invoice to quote	Does every invoice line map to a quote line, in the same unit and with the same revenue treatment?

For each disagreement, write down which document was right and which system should have changed. Most teams find that the disagreements cluster: one mapping table, one option family, one unit conversion. That cluster is where to start.

Why reconciliation keeps coming back

The usual fix is a better integration: real-time instead of nightly, validated instead of raw. That helps, and it is worth doing. But an integration copies a snapshot from one system into another. It does not settle who owns the product. After the next ECO, the next new option, or the next billing change, you are reconciling again.

The structural fix is to stop keeping three products. One product model holds the graph, the options, and the rules. Each function owns its own block of fields: sales owns price and lead time, manufacturing owns routing, billing owns the unit and the revenue treatment. The quote, the MBOM, and the invoice are generated as views of that one object, and reconciliation becomes a validation step rather than a project.

That is what SingleBOM is: a graph-style JSON product model those systems read and write. It is deliberately narrow. It does not run approvals, e-signature, tax, or payment. Those stay in your CPQ and ERP. It just keeps the product in one place.

What to look for if you are evaluating tools

Can the tool show, for one order, the quote line → MBOM line → invoice line chain?
When an ECO lands, which quotes, open orders, and price lines does it tell you are affected?
Do configuration rules live in one place, or are they copied into the ERP?
Can you export the full product model in an open format, or only reports?

If the answer to the last question is "only reports," the reconciliation work has moved into a new system, not gone away.