CPQ, ERP, and PIM: the industrial quoting architecture

In industrial quoting, the problem is almost never the tool. It's the architecture.

A technical salesperson receives a quote request for a configurable machine and needs three pieces of information simultaneously: the technical specifications of each component, the updated price with its stock and margins, and the rules that dictate which combinations are manufacturable.

The problem is that these three pieces of data reside in three different systems. When they don't communicate, the salesperson manually compiles them in an Excel spreadsheet. This takes days. And they make mistakes that aren't discovered until after the offer is signed.

This article explains how to orchestrate PIM, ERP, and CPQ to make complex industrial quoting work end-to-end. And what breaks when one of the three layers is missing or overlaps with another.

Where a CPQ gets its data and why it needs PIM and ERP

A CPQ is not the single source of truth for your products or your prices. It's the layer that applies configuration logic and generates the quote. To do this effectively, it consumes data governed elsewhere:

• Technical specifications (attributes, variants, datasheets, relationships between components) reside in the PIM.
• Prices, stock, margins, and commercial terms reside in the ERP.
• The rules for what can be combined with what and the generation of the quote are the CPQ's job.

The most common mistake we see in industrial projects is believing that CPQ can act as a PIM.

What each layer does: PIM, ERP, and CPQ

Each system governs a type of data. And none can do the other's job well.

• The PIM is the single source of truth for the product. This is where technical attributes, variants, datasheets, and component relationships reside. It's the same data that feeds your website and catalogs, so it must be centralized in one place.
• The ERP governs money. Price, stock, margins, discounts, and each customer's commercial terms. It's where the price is truly calculated.
• The CPQ provides what neither of the other two can do: configuration logic. It applies the rules of what can be combined with what, and generates the final quote.

The most common mistake we see in industrial projects is asking the CPQ to act as a PIM. It can store attributes, yes. But as soon as you have thousands of technical variants that also feed your website and catalogs, keeping that data within the CPQ means duplicating it. And duplicated data will eventually fall out of sync.

The practical rule: each piece of data must have a single source of truth.

How data flows in an industrial quote

The flow of a well-implemented configurable quote goes like this:

1. The PIM feeds the catalog and attributes. The CPQ configurator knows which components exist, their specifications, and how they relate, because the PIM synchronizes them. If this integration is missing: your team manually uploads references to the CPQ, and the website sells a product the configurator doesn't recognize.
2. The CPQ applies compatibility rules. When the salesperson selects components, the rules engine validates that the combination is technically viable and manufacturable. If this integration is missing: there's no validation, and the quote might promise a configuration that's impossible to produce.
3. The ERP validates price, stock, and margins. The price isn't calculated using a frozen table within the CPQ: it's pulled from the ERP in real-time, with current discounts and margins for that customer. If this integration is missing: you apply old prices and incorrect discount structures, precisely the error that erodes margins the most.
4. The offer is generated. With the validated configuration and correct pricing, the CPQ produces the quote document, formatted and branded for the customer, ready to send. If this integration is missing: the salesperson has to reassemble the PDF manually.

Remove any of these four steps, and the system ceases to be an architecture: it becomes three disconnected tools held together by manual work.

How this looks in practice: Mercura CPQ demo

In our interview with Mercura CPQ we saw the theory in action. Three moments made it clear how each layer behaves when a salesperson configures a complex industrial product.

Incompatible components: the configurator prevents progress

The rules validate each combination against technical restrictions before calculating the price.

The salesperson doesn't need to memorize what fits with what; the engine blocks it. In catalogs with thousands of variants, that's the difference between a manufacturable offer and a promise that engineering will later have to disprove.

Live price calculation: the real number, not an estimate

When adding or removing components, the price is recalculated using the latest ERP data — in Mercura, with native integration to Microsoft Dynamics 365 Business Central — applying discounts and margins according to business rules.

Instant quote: validated configuration, confirmed price

The document is generated complete and with the client's branding. 2D and 3D visualization helps them understand what they are buying, reducing misunderstandings before signing.

This is what separates a real architecture from a list of features: What matters is the order and understanding that if that order is broken, the quote is broken.

Common architectural errors in industrial projects

From the projects we support, these are the most common architectural flaws:

1. Implementing CPQ without a PIM behind it. The configurator ends up being fed manually or from a master Excel sheet. It works for the first week; within a month, the data no longer matches the website or the catalog. If you're still unsure which PIM fits your catalog, we elaborate on it in which PIM to choose based on your catalog, channels, and integrations.
2. Duplicating pricing logic in the CPQ and ERP. Maintaining two pricing engines guarantees that sooner or later they will produce different results. Pricing is governed in the ERP; the CPQ consumes it, it doesn't recalculate it on its own.
3. Not defining the source of truth for each piece of data. This is the root error from which the other two derive. If no one has decided that the product lives in the PIM and the price in the ERP, each system ends up storing its own version. This is exactly the pattern we describe in avoiding duplications in your B2B tech stack.
4. Integrating point-to-point without considering the architecture. Connecting CPQ↔ERP, PIM↔CPQ, and PIM↔eCommerce as isolated integrations works until you add the fourth system. Beyond a certain complexity, an integration layer that centralizes flows is advisable, as we explain in what automating a B2B company entails.

Where to start

If you're evaluating this architecture, the first thing we look at isn't which CPQ to buy. It's this:

• Where each piece of data resides today (product, price, rules) and whether there's a single source of truth or multiple parallel versions.
• How mature your PIM is, because without well-governed product data, the CPQ has nothing to draw from.
• What level of integration you truly need: not all companies need the same.

Industrial quoting isn't fixed by buying a tool. It's fixed by deciding which layer governs which data, and ensuring all three communicate in the correct order.

At Novicell, we work on this architecture from start to finish: product data governance, PIM and CPQ selection and implementation, and integration with your ERP. If you're at this stage, talk to our specialists.