Tag: costing

Manufacturing CPQ Process Flow from Customer Need to Quote

A manufacturing CPQ process flow takes a customer need and turns it into a technically valid, manufacturable and commercially accurate quote. CPQ means configure, price, quote. In manufacturing, the process can include product configuration rules, engineering calculations, CAD automation, bill of materials generation, costing, pricing, approvals and integration with enterprise systems.

The flow is usually: capture requirements, select or build a product configuration, validate technical constraints, perform engineering calculations, generate product and manufacturing data, calculate cost and price, prepare the quote, obtain approvals and hand the approved configuration into order execution. The exact sequence varies by product and business model. A standard configure-to-order product may follow an automated path, while an engineer-to-order product may require engineering review before a quote is released.

This is different from generic sales CPQ, which may focus mainly on selecting commercial options, applying discounts and producing a proposal. Manufacturing CPQ must also answer whether the product can be built, which components are required, how it should be engineered and what data production needs. The manufacturing CPQ guide provides broader context on this category.

What is the manufacturing CPQ process flow?

The manufacturing CPQ process flow is the controlled sequence used to convert customer requirements into a validated product definition and quote. It connects commercial activity with product engineering and operations.

Stage	Primary question	Typical output
1. Customer need	What must the product do?	Requirements, application data and target specifications
2. Product configuration	Which valid product choices meet the need?	Configured product and selected options
3. Technical validation	Can the selected combination work safely and correctly?	Validated configuration, warnings or engineering tasks
4. Engineering definition	What product-specific design is required?	Calculations, dimensions, CAD data, drawings or engineering instructions
5. BOM and manufacturing data	Which parts and assemblies are needed?	Configurable BOM, EBOM, MBOM or manufacturing package
6. Cost and price	What will the product cost and what should the customer pay?	Cost breakdown, price, discounts and margins
7. Quote and approval	How should the offer be presented and controlled?	Customer quote, assumptions, lead time and approvals
8. Handoff	How does the approved result enter execution?	Order, ERP transaction, engineering job or production release

Stage 1: Capture the customer need

The process begins before a product option is selected. A salesperson, dealer, application engineer or customer may describe the required duty, environment and operating conditions rather than naming a specific model.

For a pump manufacturer, the requirements might include flow rate, pressure, fluid type, temperature, material compatibility, motor voltage, installation arrangement and regulatory requirements. For industrial machinery, they may include throughput, workpiece dimensions, available floor space, cycle time, safety requirements and automation interfaces.

A manufacturing CPQ application can capture these requirements through guided questions, technical input fields, imported data or a dealer portal. Guided selling presents questions in an order that helps the user reach an appropriate product family. It is not the same as a rules engine: guided selling helps select a suitable solution, while configuration rules determine whether selected features are technically compatible.

Requirements should be represented as structured data wherever possible. Free-text notes can preserve context, but they are difficult to validate and cannot reliably drive calculations, BOM selection or CAD automation.

Important requirement data

Application and operating conditions
Required capacity, performance or duty point
Dimensions, weights and connection standards
Materials, coatings and environmental conditions
Power, voltage, controls and communication requirements
Compliance, certification and documentation needs
Delivery location, quantity and requested date
Customer-specific standards or approved components

Stage 2: Select the product family and configure the product

Once the need is structured, the user selects a product family and configures its features. A product model defines available options, attributes, components, rules and relationships. The model may represent a pump, valve assembly, air-handling unit, conveyor, electrical cabinet, trailer or complete production machine.

Configuration can use several approaches:

Rules-based configuration: explicit rules allow, require or prohibit options. For example, a high-temperature seal may require a specific material and exclude a standard elastomer.
Constraint-based configuration: the system evaluates relationships and limits across many variables. For example, motor power, impeller diameter, frame size and flow may need to remain within engineering limits.
Guided selling: questions narrow the product choice based on customer requirements. The result may then be checked by configuration rules.

A configuration model should distinguish commercial options from technical attributes. A customer may choose a stainless-steel housing as an option, while the resulting wall thickness, fastener material and manufacturing operation are derived values that the customer never selects directly.

The product configuration guide explains product models, dependencies, constraints and configuration validation in more detail.

Stage 3: Validate technical constraints

Validation prevents a quote from being created for a product that cannot be built, will not perform as required or violates a company policy. Validation may happen continuously as the user configures the product or as a formal review before quoting.

Typical rules include:

an option requires another option;
two materials or components are incompatible;
a dimension must remain within a defined range;
a motor must match the voltage and load;
a pressure rating must exceed the application requirement;
a selected component is unavailable for a particular product family;
a certification requires specific construction or documentation;
a customer-specific standard limits approved suppliers or parts.

Validation can produce errors, warnings or review tasks. An error blocks the configuration. A warning may allow the user to proceed while recording an assumption. A review task routes the case to engineering, compliance, purchasing or another specialist.

Rules should be tested against valid and invalid combinations. A large rule set can become difficult to maintain if rules are duplicated, embedded in code without documentation or owned by no clear business team. Product configuration governance is therefore as important as the rule technology.

Stage 4: Perform engineering calculations and design automation

Some products can be selected from a fixed catalog. Others require calculations that determine product dimensions or components. Manufacturing CPQ may perform these calculations directly, call an engineering service or create a task for an engineer.

For a pump, calculations may determine required head, power, impeller selection and operating range. For a heat exchanger, they may calculate surface area and connection sizes. For a conveyor, they may determine frame length, belt width, drive requirements and support spacing. For a vehicle body, they may calculate clearances, payload effects and mounting requirements.

Design automation can use these results to create a product-specific design. Parametric computer-aided design, or CAD, systems can update dimensions and component selections. The output may include a three-dimensional model, a two-dimensional drawing, a specification sheet or manufacturing instructions. Not every CPQ platform includes CAD automation, so this capability must be verified separately.

Engineering automation is particularly valuable when the same design logic is repeated across many orders. However, it requires governed engineering formulas, compatible CAD templates, reliable input data and a process for handling cases outside the automation envelope. The CAD and engineering automation guide covers these relationships.

Stage 5: Generate the bill of materials and manufacturing data

A validated configuration can drive a bill of materials, or BOM. A BOM is a structured list of the components, materials and quantities required for a product or assembly. In a manufacturing CPQ process, BOM generation may be immediate, conditional or delegated to an ERP, product lifecycle management system or engineering system.

Several BOM concepts should be distinguished:

Configurable BOM: a product structure containing optional, conditional or variable components that are resolved for a particular configuration.
EBOM: an engineering bill of materials, organized around the designed product and engineering relationships.
MBOM: a manufacturing bill of materials, organized around how the product is assembled or produced.

An industrial machine might have one configured product definition, an EBOM describing the designed assembly and an MBOM that adds work instructions, packaging, consumables or production-specific grouping. These structures may be related but are not interchangeable.

CPQ may also derive routings, labor assumptions, purchased components, alternates, tooling requirements and documentation. In other implementations, CPQ creates a configuration identifier and passes the commercial result to an enterprise resource planning system, or ERP, which owns the official item and BOM transaction.

The BOM, pricing and quoting guide explains how configurable BOMs connect to costing and quote generation.

Stage 6: Calculate cost, price and lead time

Costing and pricing are related but different activities. Costing estimates the internal resources required to produce the configured product. Pricing determines what the customer is charged.

Cost inputs may include materials, purchased parts, labor, machine time, subcontracting, freight, tooling, engineering effort, warranty exposure and overhead allocations. Pricing may apply list prices, customer agreements, regional adjustments, quantity breaks, project discounts, channel margins, surcharges and target margin rules.

A manufacturing CPQ process should make clear which values are calculated, which are retrieved from a source system and which can be overridden. For example, material cost may come from ERP, a standard component price may come from a product information management system, and a project discount may require sales management approval.

Lead time can also be configuration-dependent. A standard motor may be available from stock, while a custom coating, nonstandard material or engineered frame may add procurement and production time. A quote that shows price without realistic delivery assumptions is incomplete for many industrial buyers.

Stage 7: Generate the quote and manage approvals

The quoting stage turns the validated commercial result into a customer-facing document. A manufacturing quote commonly contains:

configured product description and option summary;
technical specifications and performance data;
quantities, unit prices and total price;
discounts, surcharges, taxes or freight assumptions;
estimated lead time and delivery terms;
scope boundaries, exclusions and customer responsibilities;
warranty, validity period and payment terms;
drawings, images, datasheets or compliance documents when appropriate.

Approval workflows should be based on business risk, not only price. A quote may need engineering approval for a nonstandard operating point, finance approval for a low margin, legal approval for unusual terms or operations approval for a capacity constraint.

Document generation should use the same configuration and pricing data used to create the quote. Re-keying selected options into a word processor or spreadsheet creates a risk that the document will not match the product being offered.

Stage 8: Handoff from quote to order and production

When the customer accepts the quote, the approved configuration becomes an order candidate or an engineering release. The handoff depends on the manufacturing workflow.

Workflow	Typical CPQ handoff	Example
Configure-to-order (CTO)	Validated configuration, item identifiers and resolved BOM enter order processing	Standard pump package with selectable materials and motor sizes
Engineer-to-order (ETO)	Requirements, calculations and engineering tasks create a project-specific design	Large custom material-handling machine
Make-to-order (MTO)	Demand triggers procurement or production after order acceptance	Configured electrical enclosure built after approval
Assemble-to-order (ATO)	Standard modules are combined after order receipt	Modular conveyor assembled from stocked sections

The handoff may involve customer relationship management, or CRM, for the opportunity and account; ERP for order, inventory, purchasing and financial transactions; product lifecycle management, or PLM, for product definitions and revisions; product data management, or PDM, for CAD files and documents; manufacturing execution systems, or MES, for production execution; and CAD for design outputs. These systems have different responsibilities and should not be treated as interchangeable.

The manufacturing workflow guide explains CTO, ETO, MTO and ATO processes, while the CPQ integration guide covers system boundaries and data exchange.

How the process differs by manufacturing environment

Configure-to-order

CTO works best when the product architecture, options and manufacturing structures are known in advance. Automation can validate selections, resolve a BOM, calculate price and create an order with limited manual engineering.

Engineer-to-order

ETO begins with a customer need but requires project-specific design. CPQ can capture requirements, identify a product platform, calculate preliminary dimensions, estimate engineering effort and create a controlled handoff. It should not be presented as fully automated if engineers must still design and approve the product.

Dealer and distributor sales

Dealer users may need a simplified interface, controlled access to prices and product guidance without seeing internal costs or engineering rules. The manufacturer must still ensure that the resulting configuration can be produced and supported.

Self-service and ecommerce

Self-service configuration can work for bounded products with clear rules, stable pricing and predictable fulfillment. Products requiring application engineering, site surveys or safety review may need a hybrid workflow that routes complex cases to specialists.

Systems and data architecture

A manufacturing CPQ solution commonly sits between customer-facing channels and engineering or enterprise systems. The CPQ application may own the configuration session and quote, while other systems remain authoritative for specific data.

System	Typical responsibility
CRM	Accounts, contacts, opportunities and sales activity
CPQ	Configuration session, rules, calculations, pricing logic and quote
ERP	Items, inventory, purchasing, orders, finance and operational costing
PLM	Product structures, revisions, change processes and lifecycle governance
PDM	CAD files, engineering documents and controlled design data
CAD	Parametric models, drawings and design outputs
PIM	Product attributes, descriptions, media and channel content
MES	Production dispatch, execution, quality and shop-floor records

In practice, ownership must be agreed for each data object. For example, CPQ may calculate a configuration-specific option set, PLM may own released engineering structures, ERP may own sellable item numbers and costs, and CAD may generate the geometric model. Integration should transfer identifiers, revisions, quantities, units and status as well as descriptive text.

Benefits of a controlled manufacturing CPQ flow

Fewer configuration errors: rules prevent incompatible options from reaching the quote.
Faster response: repeatable calculations and document generation reduce manual work.
More consistent pricing: cost and price logic is applied systematically.
Better engineering leverage: engineers spend less time answering repetitive selection questions.
Improved production handoff: approved configurations can carry structured BOM and specification data.
Traceability: the company can record who configured, reviewed and approved the quote.
Improved channel control: dealers can sell complex products within defined technical and commercial boundaries.

Limitations and common failure points

CPQ does not eliminate product complexity. It exposes and formalizes it. Implementation can be difficult when product options are poorly defined, engineering knowledge exists only in documents, prices are maintained in disconnected spreadsheets or BOM ownership is unclear.

Common failure points include:

trying to automate products whose engineering rules have not been documented;
treating every custom request as a simple option;
using one product structure for sales, engineering and manufacturing without mapping their differences;
allowing uncontrolled manual overrides;
ignoring units, revisions, effective dates and regional variations;
building integrations before agreeing on data ownership;
failing to test negative cases and unusual but valid applications;
assuming that a vendor’s generic CPQ capability includes CAD, BOM, ETO or PLM functions.

Some configurations should remain subject to engineering review. A good process makes the boundary visible and routes exceptions deliberately rather than hiding them in manual workarounds.

Implementation considerations

Manufacturers should begin with a defined product family and a measurable workflow problem. Map the current process from customer inquiry through quote and order release. Identify where users re-enter data, where errors occur, which decisions require engineering and which systems own the relevant information.

Before building the model, document:

features, options, attributes and valid ranges;
dependencies, exclusions and required combinations;
engineering formulas and their owners;
component selection and BOM logic;
cost sources, price rules and approval thresholds;
quote templates, assumptions and revision controls;
interfaces to CRM, ERP, PLM, PDM, CAD, PIM and MES;
exception paths for ETO and nonstandard requests.

Use representative examples for testing: a normal configuration, an invalid combination, a boundary value, a discontinued component, a revision change, a low-margin quote and an ETO case. Test not only the user interface but also the outputs: configuration identifier, BOM, CAD file, price, lead time, quote document and downstream transaction.

Ownership should continue after deployment. Product management may own commercial options, engineering may own technical rules, manufacturing may own assembly logic, finance may own pricing policy and IT may own integrations. A release and change-control process is necessary when products, components, suppliers or regulations change.

The CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance. Buyers evaluating platforms can also use the manufacturing-focused CPQ comparison and selection resources.

How to measure the process

Useful measures should cover speed, quality and downstream usefulness rather than quote volume alone. Possible measures include quote cycle time, percentage of quotes requiring engineering intervention, configuration error rate, quote-to-order conversion, margin variance, time from order to engineering release, percentage of orders requiring rework and the proportion of BOM data accepted without manual correction.

Metrics need clear definitions. For example, quote cycle time may begin when all required technical inputs are available rather than when an incomplete inquiry first arrives. Otherwise, the measure may encourage premature quotes instead of accurate ones.

Conclusion

A manufacturing CPQ process flow connects customer requirements to a valid product, an engineering definition, manufacturing data, cost, price and a controlled quote. The strongest implementations do not treat CPQ as a document generator. They establish a reliable product model, make configuration rules explicit, separate EBOM and MBOM responsibilities, automate appropriate engineering work and exchange governed data with CRM, ERP, PLM, PDM, CAD and MES systems.

The right level of automation depends on the product. Standard CTO products may support near-real-time configuration and order handoff. ETO products may use CPQ to structure requirements and accelerate preliminary engineering while retaining expert review. In both cases, the objective is the same: provide a commercially accurate offer that the manufacturer can build, deliver and support.

Semantic map

The following relationships summarize the entities and data flows described in this guide:

Customer requirements lead to product configuration.
Product configuration is evaluated by configuration rules.
Configuration rules prevent invalid combinations.
Engineering calculations determine product-specific parameters.
Validated configurations generate configurable BOMs.
EBOMs describe engineered product structures.
MBOMs describe manufacturing assembly structures.
CAD automation generates product-specific design outputs.
Costing estimates resources required to build the product.
Pricing converts cost and commercial policy into a customer price.
CPQ generates quotes from configuration and pricing data.
CRM stores opportunity and customer context.
ERP manages orders, inventory, purchasing and financial transactions.
PLM governs product definitions, revisions and lifecycle changes.
MES supports production execution after order release.
ETO requires engineering review for project-specific designs.

Frequently asked questions

1. What is a CPQ process flow in manufacturing?

It is the sequence that converts customer requirements into a validated configuration, engineering and manufacturing data, cost, price and a formal quote.

2. What does CPQ stand for?

CPQ stands for configure, price, quote. In manufacturing, configure may include technical validation and engineering outputs in addition to selecting commercial options.

3. How does manufacturing CPQ differ from sales CPQ?

Sales CPQ often concentrates on product selection, discounts and proposals. Manufacturing CPQ may also manage constraints, calculations, BOMs, CAD outputs, costing and production handoff.

4. What happens first in the CPQ process?

The process starts by capturing structured customer requirements such as duty, dimensions, materials, environment, performance and compliance needs.

5. What is the role of configuration rules?

Configuration rules define valid and invalid combinations, required options, exclusions, ranges and technical dependencies.

6. Is guided selling the same as product configuration?

No. Guided selling asks questions to recommend a product or configuration path. Product configuration validates the selected features and their technical relationships.

7. Can CPQ generate a bill of materials?

Some manufacturing CPQ systems generate or resolve BOMs, while others pass configuration data to ERP, PLM or another system that owns the BOM. This capability must be verified for each platform.

8. What is the difference between an EBOM and an MBOM?

An EBOM represents the engineered product structure. An MBOM represents how the product is assembled or produced. They may contain different groupings, parts and manufacturing information.

9. Does every CPQ system include CAD automation?

No. CAD automation may be a native capability, an integration or an external engineering service. Buyers should verify supported CAD systems, templates, outputs and revision handling.

10. How does CPQ support engineer-to-order products?

CPQ can capture requirements, select a product platform, perform preliminary calculations, estimate engineering effort and create a controlled engineering handoff. It does not necessarily replace project engineering.

11. How does CPQ calculate manufacturing prices?

It can combine material, labor, purchased-component, freight, engineering and overhead inputs with price lists, margins, discounts, surcharges and approval rules.

12. Which systems commonly integrate with manufacturing CPQ?

Common integrations include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on the product model and the responsibilities assigned to each system.

13. What information should appear in a manufacturing quote?

A quote should normally include the configured product, technical specifications, quantities, price, lead time, assumptions, exclusions, terms and relevant drawings or documentation.

14. Why are manufacturing CPQ implementations difficult?

They require product rules, engineering knowledge, pricing data, BOM logic, system ownership and exception handling to be made explicit and maintained over time.

15. Should every configuration be fully automated?

No. Standard, repeatable configurations are good automation candidates. Novel, safety-critical or highly customized designs may require engineering review.

16. What is the difference between CTO and ETO?

Configure-to-order uses predefined product structures and options. Engineer-to-order requires project-specific engineering before or during order fulfillment.

17. How does CPQ support configure-to-order production?

It validates options, resolves the configuration, calculates price and can pass item, BOM and specification data into order and production systems.

18. What should be tested before launching a CPQ process?

Test valid, invalid, boundary, discontinued, revised, low-margin and ETO scenarios, including the resulting configuration, BOM, price, quote, CAD output and downstream transactions.

19. Who should own manufacturing CPQ rules?

Ownership is usually shared: product management for commercial options, engineering for technical rules, manufacturing for assembly logic, finance for pricing and IT for integrations.

20. What is the main objective of manufacturing CPQ?

The objective is to create an accurate, technically valid and commercially acceptable offer that the manufacturer can reliably build, deliver and support.

October 8, 2026

BOM in CPQ: How Bills of Materials Fit into Configure-Price-Quote

A bill of materials (BOM) in Configure, Price, Quote (CPQ) is the structured list of components, quantities and relationships generated or selected for a specific product configuration. In manufacturing CPQ, the BOM connects what a customer selects with what engineering, purchasing, production and finance need to cost, price, quote and eventually build the product.

The basic flow is:

A salesperson, dealer, engineer or customer configures a product.
Configuration rules validate options, dimensions, materials and dependencies.
The CPQ system resolves the selections into a configurable BOM or product-specific BOM.
Component quantities and attributes support costing and pricing.
The approved configuration and commercial data are assembled into a quote.
Relevant BOM data may be sent to enterprise systems such as an Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM) or Manufacturing Execution System (MES) platform.

Not every CPQ platform generates manufacturing-ready BOMs. Some systems only use product options to calculate prices and produce a proposal. Buyers should therefore verify whether a platform supports BOM generation, which BOM type it produces, how rules are maintained and whether the output is suitable for engineering or production.

This guide explains how BOMs fit into manufacturing CPQ, how they relate to configuration and pricing, how EBOMs and MBOMs differ, and what manufacturers should evaluate during implementation.

What is a BOM in CPQ?

A BOM in CPQ is a structured representation of the parts, assemblies, materials and quantities required for a configured product. The BOM may be generated dynamically from configuration choices or retrieved from predefined product structures. It can support commercial calculations, engineering review, manufacturing planning or several of these purposes at once.

A typical BOM line may contain:

item number or material number;
component description;
quantity and unit of measure;
parent assembly;
effective date or revision;
make-or-buy status;
cost and price references;
optional attributes such as material, finish, size or voltage;
manufacturing or procurement notes;
links to drawings, specifications or CAD files.

In a simple sales CPQ application, the BOM may be only a commercial bundle used to calculate a price. In manufacturing CPQ, the BOM can be the result of a deeper product model containing constraints, engineering calculations, variant logic and relationships between configured features.

For example, configuring an industrial pump may involve selecting flow rate, pressure, fluid type, motor power, seal material, impeller material, connection standard and enclosure rating. Those choices can determine the pump assembly, motor, coupling, baseplate, seal kit, control panel, fasteners and documentation included in the BOM.

The BOM is therefore not merely a list printed on a quote. It is an output of the product configuration model and a potential input to costing, engineering, ERP, PLM, purchasing and production.

How BOM generation fits into the CPQ architecture

Manufacturing CPQ usually contains several related data and logic layers. The exact architecture varies by product and vendor, but the following pattern is common.

Layer	Purpose	Manufacturing example
Product model	Defines products, features, options, components and relationships.	A pump family with available impellers, motors and seal types.
Configuration rules	Controls valid, invalid, required and conditional choices.	A high-temperature seal is required for a specified fluid and temperature range.
Engineering calculations	Derives technical values from customer or application inputs.	Calculating motor size from flow, head and efficiency requirements.
BOM logic	Selects components and calculates quantities or structures.	Adding a reinforced baseplate when motor weight exceeds a threshold.
Cost model	Applies material, labor, overhead, supplier and manufacturing costs.	Calculating cost from selected steel grade, machining time and purchased motor.
Pricing model	Converts cost and commercial rules into customer prices.	Applying customer terms, currency, margin, freight and volume discounts.
Quote document	Communicates scope, price, assumptions, validity and commercial terms.	A proposal showing the configured equipment, options, exclusions and price.
Enterprise integration	Transfers approved data to surrounding systems.	Sending an order-ready structure and item references to ERP and PLM.

These layers should be related but not confused. A configuration rule determines whether a combination is valid. A BOM rule determines which components result from that combination. A cost rule determines what the selected components cost. A pricing rule determines what the customer is charged. A quote document presents the result.

For more background, see the guide to product configuration and configuration rules and the overview of BOM generation, pricing and quote automation.

From customer selections to a configured BOM

1. Capture requirements and configuration inputs

The process begins with inputs such as product family, capacity, dimensions, operating environment, materials, accessories, certifications and delivery requirements. These inputs may be entered by an internal salesperson, sales engineer, dealer, customer or engineering user.

In an industrial enclosure example, the inputs could include width, height, depth, ingress protection rating, mounting method, door arrangement, paint system and electrical components. Some values are discrete options, while others are numerical variables or free-form engineering requirements.

2. Validate the configuration

The CPQ rules engine checks the proposed configuration. Rules may require an option, exclude a combination, recommend an alternative or request engineering review.

There are several related approaches:

Rules-based configuration uses explicit if-then logic, dependencies and compatibility rules.
Constraint-based configuration evaluates relationships and limits across variables, such as dimensions, load, capacity, temperature or power.
Guided selling asks questions and recommends suitable products or options, but may not provide the engineering depth required to validate a complex product.

A guided selling interface can be useful for selecting a suitable product family. It is not automatically a substitute for a constraint solver or engineering rules engine.

3. Resolve components and quantities

After validation, BOM logic determines which components belong in the configured structure. A selected option can add an item, replace another item, change a quantity, alter a component attribute or create a new subassembly.

For example, selecting a dual-pump skid might:

change the top-level equipment quantity from one pump to two;
add a common skid frame;
add two motors and two couplings;
add a shared control cabinet;
add isolation valves and check valves for each pump;
change cable and pipe lengths based on layout dimensions;
require additional instrumentation.

The result may be a multi-level BOM rather than a flat list. A top-level skid contains pump assemblies, each pump assembly contains a motor and hydraulic components, and the control panel contains electrical subassemblies.

4. Apply calculations and attributes

Some BOM values cannot be selected directly. They must be calculated. A configured conveyor may require belt length based on conveyor dimensions. A heat exchanger may require surface area and tube count. A vehicle body may require material quantities based on length, width and payload.

The CPQ system may also assign attributes to BOM lines. A generic motor item might become a specific motor variant with a defined power, voltage, frequency, enclosure and efficiency class. In other cases, CPQ may pass calculated requirements to an ERP or PLM system that selects the final material number.

5. Calculate cost and price

Once the BOM is resolved, the system can use its lines as inputs to costing. Costing may include component purchase prices, manufacturing operations, labor, setup, subcontracting, freight, tooling, scrap, overhead and engineering effort. Pricing then applies commercial policies such as margin, discount, currency, customer segment and approval thresholds.

However, BOM generation and costing are separate capabilities. A CPQ platform may generate a commercial BOM without calculating detailed manufacturing cost. Conversely, a system may calculate price from a product model without producing a production-ready BOM.

6. Produce the quote and route approvals

The quote normally includes a customer-readable description rather than every internal BOM line. It may show major assemblies, options, quantities, technical specifications, exclusions, lead time, price and terms. Internal users may see a more detailed breakdown for margin analysis, review and approval.

Approval workflows can be triggered by low margin, unusual discounts, non-standard materials, extended lead time, engineering risk or an ETO requirement. Engineer-to-order (ETO) products require new or modified engineering work, so the BOM may remain provisional until engineering completes its review.

EBOM, MBOM and configurable BOM

Manufacturers should distinguish among several BOM concepts.

BOM type	Meaning	Typical purpose
EBOM	Engineering Bill of Materials: the product structure from a design or engineering perspective.	Defines designed assemblies, parts, revisions and technical relationships.
MBOM	Manufacturing Bill of Materials: the structure used to plan and build the product.	Includes manufacturing assemblies, operations, work-center relationships, consumables or packaging where applicable.
Configurable BOM	A rules-driven structure containing alternatives, optional items, quantities or conditions.	Represents a product family before one customer configuration is finalized.
Configured or order BOM	The resolved structure for one specific order or quote.	Supports a particular customer requirement, order, build or engineering review.

A CPQ system may own the configurable product model and produce a configured BOM, while PLM owns the authoritative EBOM and ERP or manufacturing systems manage the MBOM. In other architectures, CPQ may read item and structure data from PLM or ERP and return only configuration selections and commercial information.

These responsibilities must be defined explicitly. Treating an EBOM and an MBOM as interchangeable can create problems with assembly sequence, phantom assemblies, work instructions, bulk materials, packaging and shop-floor reporting.

Read more about manufacturing and CPQ terminology, including EBOM, MBOM, CTO and ETO.

Manufacturing examples

Industrial pump configuration

A pump manufacturer may sell several product families with options for capacity, pressure, fluid, temperature, impeller diameter, seal type, motor, coupling, baseplate and controls.

The configuration model can validate that:

the selected impeller supports the required flow and head;
the motor has sufficient power and the correct electrical specification;
the seal material is compatible with the fluid and temperature;
the casing material satisfies corrosion requirements;
the selected flange standard matches the connection requirement;
the baseplate supports the selected motor and pump arrangement.

The resulting BOM could contain a pump casing, impeller, shaft, mechanical seal, bearings, motor, coupling, guard, baseplate, fasteners, documentation and optional instrumentation. A CAD or engineering system may use the same configuration to generate a drawing or dimensional layout, but that capability is not present in every CPQ implementation.

HVAC equipment

An air-handling unit configuration may include airflow, static pressure, casing dimensions, filters, coils, fans, heaters, dampers, controls and access panels. Dimensions can influence the number of modules, panel quantities, coil size, fan selection and shipping sections.

A quote-only CPQ tool may calculate a price from these choices. A deeper manufacturing CPQ system may generate a variant BOM, calculate performance, create a product-specific drawing and pass an order structure to ERP or PLM. The buyer must verify which of these outputs are actually supported.

Specialty vehicle

A specialty vehicle may be configured with chassis, wheelbase, axle rating, body length, storage modules, electrical systems, hydraulic equipment and safety options. A body length change may affect frame members, floor panels, wiring harnesses, lighting, fasteners and weight calculations.

The BOM may need to reflect both optional content and calculated quantities. It may also need revision control because vehicle programs often evolve while orders remain open.

How BOM data supports costing and pricing

The BOM provides a product-specific basis for cost and price, but it does not automatically make the calculation accurate. The quality of the result depends on item master data, supplier costs, operation rates, labor assumptions, waste factors, currency handling and the date on which values are effective.

Costing inputs

purchased component cost;
raw material weight, length, area or volume;
machine and labor rates;
setup and changeover time;
subcontracted operations;
scrap and yield factors;
freight, packaging and customs costs;
engineering or project effort for ETO work;
tooling and one-time charges.

Pricing inputs

target margin or markup;
customer-specific price agreements;
volume breaks;
discount authority;
channel or dealer margins;
currency and exchange-rate policy;
tax, freight and surcharge treatment;
commercial risk and contingency;
approval thresholds.

Some businesses calculate cost and price in CPQ. Others use CPQ to assemble the commercial structure and rely on ERP for authoritative cost or price data. Integration design should define which system owns each value and how revisions, effective dates and failed transactions are handled.

BOMs and CAD, PLM and ERP integration

BOM-related CPQ architecture commonly involves several enterprise systems with different responsibilities.

System	Typical responsibility	Possible CPQ relationship
Customer Relationship Management (CRM)	Accounts, opportunities, contacts and sales activity.	Starts a configuration or stores the quote and opportunity reference.
ERP	Items, inventory, purchasing, costing, orders, production and finance.	Provides item and price data or receives an approved order structure.
PLM	Product definitions, revisions, engineering changes and lifecycle control.	Provides approved product structures or receives configured engineering data.
Product Data Management (PDM)	CAD files, documents and design data management.	Links configured products to models, drawings or controlled documents.
CAD	Computer-Aided Design models and drawings.	Uses configuration inputs to generate geometry or documentation where supported.
Product Information Management (PIM)	Commercial and technical product content.	Supplies descriptions, images, specifications and channel content.
MES	Execution and tracking of manufacturing operations.	Receives production-relevant structures or order data through ERP or direct integration.

These systems are not interchangeable. A CRM opportunity is not a BOM. A PLM EBOM is not necessarily a manufacturing MBOM. A CAD assembly is not automatically an ERP item structure. CPQ must translate or map data between these contexts when the workflow requires it.

Important integration questions include:

Which system is authoritative for item numbers and revisions?
Does CPQ create new items or only select existing items?
Is the BOM transferred as a flat list, hierarchical structure or both?
How are configured dimensions and calculated attributes passed downstream?
How are engineering changes reflected in open quotes?
What happens when an item, price or revision cannot be found?
Can the receiving system distinguish a quote BOM from an order or production BOM?
Are integrations synchronous, asynchronous or manually approved?

See the guide to CPQ integration with ERP, CRM, PLM, PDM, CAD and MES for broader architecture considerations.

CTO, ETO, MTO and ATO BOM workflows

BOM behavior depends on the manufacturing strategy.

Model	Meaning	BOM implication
Configure-to-order (CTO)	A predefined product is assembled after the customer selects allowed options.	CPQ can often resolve a known configurable BOM from approved variants.
Engineer-to-order (ETO)	Engineering designs or significantly modifies the product for the order.	CPQ may create a preliminary BOM and trigger engineering work before final release.
Make-to-order (MTO)	Production starts after an order, using a defined product or specification.	The BOM may be created or released when the order is accepted.
Assemble-to-order (ATO)	Standard subassemblies are stocked and combined for the order.	CPQ selects a combination of existing modules and may generate an assembly structure.

In CTO, the CPQ BOM can be relatively deterministic. In ETO, it may represent requirements rather than a final production structure. A system should make this status visible so that a customer-facing quote is not mistaken for an approved manufacturing release.

These workflows are discussed in more detail in the guide to configure-to-order, engineer-to-order and related manufacturing workflows.

Benefits of BOM-driven CPQ

More accurate configuration and pricing

When price and cost are derived from the actual configured content, the quote is less dependent on manual spreadsheet interpretation. This is especially valuable when options change material, capacity, labor, purchased components or manufacturing effort.

Faster sales-to-engineering handoff

A structured configuration and BOM give engineering a defined starting point. Engineers can focus on exceptions, calculations and new design work instead of re-entering every option from a sales document.

Better visibility of scope

A resolved BOM exposes included components, optional content, exclusions and quantities. This reduces ambiguity during commercial review and helps identify missing accessories or services.

Improved approval control

Approvals can use calculated margin, component cost, non-standard selections, lead time and engineering status rather than relying only on the total quote value.

Reusable product knowledge

Rules and product structures become a governed model that can be reused across direct sales, dealers, ecommerce, internal applications and customer service, subject to the capabilities of the chosen platform.

Limitations and risks

A commercial BOM may not be production-ready

A CPQ-generated BOM may omit routing, operations, work instructions, consumables, packaging, phantom assemblies or shop-floor details. It should not be sent directly to production without confirming its intended use.

Product models become difficult to maintain

Large product families can contain thousands of options and dependencies. Poorly governed rules create contradictions, duplicate logic and unexpected combinations. Ownership, naming standards, version control and automated regression testing are essential.

Data synchronization is complex

Item numbers, costs, prices, revisions and availability change in ERP, PLM and supplier systems. A stale CPQ model can produce an invalid or unprofitable quote even when the configuration logic is correct.

Engineering calculations require validation

Calculations for load, pressure, thermal performance, electrical sizing or structural requirements may require specialist review. A CPQ calculation should not be treated as an engineering approval unless the manufacturer has validated and governed it for that purpose.

Variant explosion can affect performance

When many dimensions, options and conditional components interact, the theoretical number of variants can become very large. The implementation may need modular architectures, constraint solvers, parameterized items or integration with engineering systems rather than storing every possible finished BOM.

Quote and order revisions can diverge

If a customer changes the configuration after approval, the system must show which BOM, cost, price, revision and document version correspond to the change. Otherwise, sales, engineering and production may work from different definitions.

Implementation guidance

Define the purpose of the BOM first

Document whether CPQ needs to produce a commercial BOM, costing BOM, EBOM, MBOM, order BOM or a preliminary ETO structure. One output may not satisfy every downstream process.

Establish data ownership

Assign ownership for products, options, item numbers, revisions, costs, prices, engineering formulas and manufacturing structures. A governance matrix should identify the system of record and the synchronization method for each data object.

Model the product before copying spreadsheets

Existing spreadsheets often mix options, prices, formulas, exceptions and manual judgment. Before migrating them, separate product attributes, configuration rules, BOM logic, cost data and approval policies.

Use stable identifiers

Every component, option, assembly and revision should have a consistent identifier. Descriptions alone are not sufficient for reliable integration because similar descriptions may refer to different materials, revisions or units of measure.

Test combinations, not just individual rules

Testing should include valid configurations, invalid combinations, boundary values, revision changes, quantity calculations, missing data, currency changes, discounts, approvals and downstream integration failures.

Define release states

Useful states may include draft, technically valid, commercially approved, engineering review, order-ready and production-released. The names vary, but the distinction between a quote configuration and a released manufacturing structure should be explicit.

Measure operational outcomes

Relevant measures can include quote cycle time, configuration error rate, engineering rework, margin variance, approval duration, percentage of quotes requiring manual correction, order-entry effort and integration failure rate. The right measures depend on the business process and baseline data.

The broader manufacturing CPQ implementation guide covers requirements, migration, testing, governance, deployment and maintenance.

What to ask CPQ vendors about BOM capability

Does the platform generate a hierarchical BOM, a flat commercial list or both?
Can it represent configurable BOMs with optional, alternative, conditional and calculated components?
Can BOM logic calculate quantities from dimensions, capacity or other variables?
Does it distinguish commercial, engineering and manufacturing structures?
Can it import or synchronize items and revisions from ERP or PLM?
Can it return configured data to CAD or engineering automation tools?
Does it support BOM versioning and effective dates?
Can users compare BOM changes between quote revisions?
How are costs, prices and currencies sourced and refreshed?
Can the system mark a configuration as requiring engineering review?
What APIs and integration events are available?
How are errors handled when an item or downstream transaction is unavailable?
Can dealers or customers see a simplified view while engineering users see detailed data?
What testing and rule-governance tools are included?
Which capabilities are standard, which require configuration and which require custom development?

Vendor evaluation should focus on the manufacturer’s actual product complexity and downstream process rather than on a generic feature checklist. The manufacturing CPQ comparison and selection resources can help structure an evaluation.

Semantic map

The following relationships summarize how BOMs connect configuration, costing, quoting and manufacturing systems:

CPQ configures configurable products.
Configuration rules prevent invalid combinations.
A configured product generates a configured BOM.
A configurable BOM represents product variants.
A configured BOM identifies components and quantities.
BOM components contribute to product cost.
Costing supports price calculation.
Pricing determines the commercial quote value.
A quote communicates configured scope and commercial terms.
Engineering review validates non-standard or ETO requirements.
EBOM represents an engineering product structure.
MBOM represents a manufacturing product structure.
CPQ exchanges item and order data with ERP.
CPQ may exchange product structure data with PLM.
CAD automation generates product-specific drawings when supported.
Approved configuration data can support production planning.

Frequently asked questions

What does BOM mean in CPQ?

BOM means Bill of Materials. In CPQ, it is the component and quantity structure associated with a configured product and may support costing, pricing, quoting, engineering or production.

Does every CPQ system generate a BOM?

No. Some CPQ systems calculate prices and create quotes without generating a BOM. Manufacturers should verify whether BOM generation is supported and whether the output is commercial, engineering or manufacturing-oriented.

How does CPQ create a BOM?

CPQ applies product rules, constraints, option dependencies and calculations to customer inputs, then selects components, assemblies and quantities for the resulting configuration.

What is the difference between a configurable BOM and a configured BOM?

A configurable BOM contains alternatives, options and conditional logic for a product family. A configured BOM is the resolved structure for one particular customer configuration or order.

Is a CPQ BOM the same as an EBOM?

Not necessarily. An EBOM is an engineering product structure. A CPQ BOM may be a commercial or order structure and may require engineering or PLM validation before it becomes an authoritative EBOM.

Is a CPQ BOM the same as an MBOM?

No. An MBOM is organized for manufacturing execution and may include operations, manufacturing assemblies, consumables or packaging that are absent from a commercial CPQ BOM.

Can BOM data be used to calculate price?

Yes, when component costs, quantities and pricing rules are available. The accuracy depends on current item data, supplier costs, labor and overhead assumptions, margins and commercial policies.

Can CPQ calculate manufacturing cost?

Some manufacturing CPQ systems can calculate detailed or estimated cost, while others use costs supplied by ERP or another system. This capability must be verified for the specific platform and implementation.

How does configuration affect the BOM?

Configuration choices can add, remove or replace components, change quantities, alter attributes or trigger calculated dimensions and subassemblies.

What is an example of a BOM rule?

A BOM rule could add a larger motor, reinforced frame and upgraded coupling when a machine is configured for a higher load or capacity range.

Can CPQ generate a CAD model from a BOM?

Some platforms integrate with CAD or engineering automation tools, but BOM generation alone does not create CAD geometry. CAD automation requires suitable parametric models, mappings and validated engineering logic.

How does CPQ support engineer-to-order products?

CPQ can capture requirements, calculate preliminary values, create a preliminary BOM and route the configuration to engineering. The final BOM may not exist until design work and technical approval are complete.

What happens when an item changes in ERP?

The implementation should define synchronization and error handling. CPQ may refresh the item, block the configuration, use an approved replacement or route the quote for review, depending on governance.

Can a BOM appear on the customer quote?

Sometimes. Customer quotes usually show selected equipment, major assemblies and options rather than every internal component. The visible level should match commercial clarity and confidentiality requirements.

How does a BOM affect quote approvals?

The BOM can provide the component cost, non-standard content, engineering effort and lead-time information used to trigger margin, technical or management approvals.

What BOM data should CPQ send to ERP?

The required data may include item numbers, quantities, units, configuration attributes, revisions, customer references and order status. The exact payload depends on whether ERP creates the order, production structure or only a sales document.

Why are BOM revisions important in CPQ?

Revisions show which product definition, component set, cost basis and rules were used for a quote or order. They help prevent discrepancies when products change during a sales cycle.

What is the main risk of using a CPQ BOM for production?

The main risk is assuming that a commercial or configured BOM contains all manufacturing data. Production may also require routings, operations, work instructions, revisions, quality data and manufacturing-specific structures.

How should manufacturers test BOM generation?

Testing should cover normal configurations, invalid combinations, boundary dimensions, option replacements, quantity calculations, revision changes, price changes, approval paths and failed ERP or PLM transactions.

In practice, BOM capability is one of the clearest differences between generic sales CPQ and manufacturing-oriented CPQ. A quoting tool may tell a salesperson what to charge. A manufacturing CPQ architecture can additionally explain what the customer is buying, which components are required, what it costs, whether it can be engineered and how the data should move toward production.

September 23, 2026

Quote Automation for Complex Manufactured Products

Quote automation for complex manufactured products is the use of configurable product models, engineering rules, costing logic, pricing rules and document generation to produce accurate quotations with less manual work. In a manufacturing context, automation must do more than calculate a selling price. It may need to validate dimensions, select compatible components, calculate performance, create a configurable bill of material (BOM), request engineering review and produce a quote that reflects what can actually be designed, purchased and built.

This capability is commonly delivered through configure, price, quote (CPQ) software. Manufacturing CPQ connects the commercial quotation process with product configuration and downstream systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD) and manufacturing execution systems (MES). The exact scope varies by platform: some CPQ tools focus mainly on guided selling and price calculation, while others support rules-based engineering, BOM generation, CAD automation and engineer-to-order workflows.

For example, a salesperson quoting an industrial pump may select flow rate, pressure, fluid type, temperature, motor, seal material, connection standard and enclosure. The system can reject incompatible combinations, calculate the required pump size, select valid components, apply material and labor costs, add appropriate margins, route exceptions for approval and generate a quotation. Where supported, it can also create a product-specific BOM, CAD model or drawing.

For background, see the guide to manufacturing CPQ, the detailed explanation of product configuration and configuration rules, and the overview of BOM, pricing and quoting.

What quote automation means in manufacturing

Quote automation is the controlled transformation of a customer requirement into a commercial and technical offer. The input may be a salesperson’s selections, an application engineer’s requirements, a dealer’s guided configuration or data submitted through an ecommerce channel. The output usually includes a validated configuration, price, lead-time assumptions, scope and exclusions, and a formal quote document.

Generic sales CPQ often automates product selection, discounts and proposal documents. Manufacturing CPQ adds industrial product logic. Its model may include dimensions, tolerances, materials, ratings, capacity calculations, electrical requirements, component compatibility, manufacturing constraints, supplier availability and engineering review conditions.

Capability	Generic sales CPQ	Manufacturing-oriented CPQ
Product selection	Options and packages	Options, dimensions, variants, components and technical requirements
Validation	Basic dependencies and exclusions	Rules, constraints, calculations, standards and engineering limits
Pricing	List prices, discounts and currencies	Material, labor, purchased parts, overhead, freight, margin and configuration-specific pricing
Output	Quote and proposal	Quote, configuration record, BOM, technical specification and possibly CAD outputs
Downstream connection	Customer relationship management (CRM) and order systems	CRM, ERP, PLM, PDM, CAD, MES, supplier and manufacturing systems

How automated quoting works

A robust quote automation process is a chain of dependent decisions rather than a single price calculation. The typical sequence is configuration, validation, engineering calculation, structure generation, costing, pricing, approval and document production.

1. Capture customer requirements

The process starts with structured requirements. Depending on the product, this could include required output, dimensions, operating environment, material, regulatory standard, power supply, delivery date, quantity and site conditions. A guided interface can ask questions in a logical order and hide options that are not relevant to the selected product family.

Structured requirements are preferable to free-text notes because they can be validated and used by later calculations. Free text may still be necessary for special instructions, but it should not be the only record of an important technical requirement.

2. Select and validate the product configuration

The CPQ product model represents product families, features, options, variants, components and relationships. Rules determine what can be selected together. A rule might state that a stainless-steel wetted path is required for a corrosive fluid, that a particular motor is unavailable above a specified load, or that a high-temperature seal must be selected when fluid temperature exceeds a threshold.

Rules-based configuration typically uses explicit conditions such as “if option A is selected, require option B” or “exclude option C.” Constraint-based configuration goes further by evaluating limits and relationships across variables, such as a maximum shaft load, available installation space or required heat-transfer capacity. Guided selling is different again: it helps a user reach a suitable product by asking business or application questions, but it may not fully validate the underlying engineering design.

More detail on these distinctions is available in the guide to product configuration.

3. Perform engineering calculations

Some products can be quoted from a fixed option matrix. Others require calculations. A pump may need a performance selection based on flow and head. An air-handling unit may require airflow, static pressure, coil capacity and casing dimensions. A vehicle body may require axle loading, payload and frame constraints.

Engineering calculations can be implemented inside CPQ, exposed through a calculation service, or performed by an external engineering application. The important design question is how the calculation result becomes a controlled configuration decision. If a calculation is performed manually in a spreadsheet but the result is not recorded in the product model, the quote may remain difficult to reproduce and audit.

4. Generate a product structure or BOM

A validated configuration can be mapped to a configurable BOM. A BOM is a bill of material: the components, quantities and relationships required for a product or assembly. Manufacturing environments commonly distinguish between an engineering BOM (EBOM), which describes the design structure, and a manufacturing BOM (MBOM), which describes how the product is assembled or produced.

Quote automation may generate a preliminary configurable BOM, an EBOM, an MBOM or a sales-oriented material list. These are not interchangeable outputs. A sales BOM may be sufficient for pricing, while production requires manufacturing operations, routings, substitutes, phantom assemblies, work centres and revision-controlled part numbers.

Some systems generate only a commercial list of selected items. Others can create detailed structures or pass configuration parameters to ERP or PLM for authoritative BOM creation. Buyers should verify the actual output and ownership of each structure rather than assuming that a CPQ-generated BOM is production-ready.

5. Calculate cost

Costing estimates what the manufacturer expects to spend to fulfil the configuration. Cost elements may include raw materials, purchased components, labor, subcontracting, setup, engineering effort, freight, installation and overhead. Cost data may come from ERP, a costing database, supplier records or manually maintained values.

Costing and pricing are related but distinct. Cost answers “what will this configuration cost us?” Pricing answers “what should we charge the customer?” Keeping the two concepts separate supports margin analysis, approval thresholds and controlled discounting.

6. Apply pricing and commercial rules

The pricing engine can combine base prices, option prices, quantity breaks, customer agreements, regional conditions, currencies, surcharges, escalation clauses, freight and discounts. A configured enclosure may add material cost, machining cost and a commercial surcharge. A rush delivery request may trigger a capacity or expedition fee rather than simply changing the product price.

Pricing rules should be versioned and traceable. If a quote is revised after a price-list change, the business should be able to identify which price list, cost basis, exchange rate and approval policy were used.

7. Route exceptions and approvals

Not every quote should be automatically approved. The workflow may route a quote to sales management when the margin falls below a threshold, to engineering when a non-standard dimension is requested, to legal when contractual terms change, or to operations when the delivery date conflicts with capacity.

Approval workflows should show the reason for the exception and the data supporting the decision. A vague “special approval required” status creates delay. A useful workflow identifies whether the issue is technical risk, commercial margin, credit exposure, delivery feasibility or a non-standard customer requirement.

8. Generate the quote document

The final document may include the configured product description, itemized or grouped pricing, quantities, delivery assumptions, validity period, payment terms, exclusions, warranty language and technical attachments. For complex equipment, the document may also include performance data, a preliminary drawing, a specification sheet or a configuration summary.

Document automation should be based on the validated configuration rather than copied text. Otherwise, the price may reflect one option set while the description or drawing reflects another.

Reference architecture for manufacturing quote automation

Quote automation normally sits between customer-facing channels and enterprise engineering and operations systems. A typical architecture contains the following layers:

Experience layer: salesperson, application engineer, dealer, distributor, customer portal or ecommerce interface.
Configuration layer: product models, options, dependencies, constraints, calculations and validation services.
Commercial layer: cost models, price lists, discount rules, currencies, taxes, freight and approval policies.
Engineering output layer: specifications, configurable BOMs, EBOM or MBOM requests, CAD parameters, drawings and technical documents where supported.
Enterprise integration layer: APIs, middleware or file-based exchanges with CRM, ERP, PLM, PDM, CAD, PIM and MES.
Governance layer: version control, permissions, audit history, testing, release management and ownership of product data.

CRM, or customer relationship management, generally stores accounts, opportunities and customer interactions. ERP, or enterprise resource planning, typically manages items, inventory, purchasing, costs, orders and financial information. PLM, or product lifecycle management, controls product definitions, revisions and lifecycle processes. PDM, or product data management, commonly manages CAD files and engineering data. PIM, or product information management, manages product content for commercial channels. MES, or manufacturing execution system, supports production execution. CAD, or computer-aided design, creates engineering models and drawings.

These systems may exchange data, but they are not substitutes for one another. The CPQ integration guide explains how these system boundaries affect architecture and data ownership.

Manufacturing example: quoting a configured industrial pump

Consider a manufacturer selling centrifugal pumps for industrial water, chemical and process applications. A quote may require the following inputs:

flow rate and differential head;
fluid composition, density and temperature;
pump material and wetted-part material;
seal type and elastomer;
connection standard and size;
motor power, voltage, frequency and enclosure;
baseplate, coupling guard and instrumentation;
certification, documentation and delivery requirements.

The configuration model can use the application inputs to identify a suitable pump family and impeller range. Rules can prevent a material from being used with an incompatible fluid, prevent a motor from being selected for an unsuitable voltage, and require a high-temperature seal when the operating temperature exceeds a defined limit.

The system can then select a pump assembly, motor, coupling, baseplate, seal kit and instruments. It can calculate a preliminary cost from material and purchased-part prices, apply labor and overhead assumptions, and produce a selling price using customer and channel rules. If the requested duty point falls outside standard performance limits, the quote can be routed to an application engineer instead of being rejected or silently accepted.

Depending on the implementation, the output may be a quote-level BOM, a technical selection sheet, a CAD assembly, a drawing request or an ERP sales-order configuration. These outputs should be clearly labelled by maturity. A preliminary quote BOM is not automatically an approved manufacturing BOM.

Where quote automation fits different manufacturing workflows

Workflow	Role of quote automation	Typical output
Configure-to-order (CTO)	Selects proven modules and options within a defined product model	Validated configuration, price, standard BOM and order data
Make-to-order (MTO)	Triggers production of a product after the customer order, often with limited configuration	Quote, demand information and item or variant selection
Assemble-to-order (ATO)	Combines stocked or standard subassemblies after selection	Configuration, component demand and assembly structure
Engineer-to-order (ETO)	Captures requirements and identifies engineering work for a non-standard design	Budgetary quote, engineering scope, assumptions and approval tasks

CTO is generally the easiest environment for high automation because the product rules and outputs are repeatable. ETO requires more human review because the design may not exist when the quote starts. Automation can still improve ETO by capturing requirements, estimating engineering effort, creating a preliminary structure and identifying assumptions, but it should not imply that an unverified design is production-ready.

See the guide to configure-to-order, engineer-to-order and related manufacturing workflows for a fuller comparison.

Benefits of quote automation for manufacturers

Shorter response cycles

Automating repeatable configuration, calculations and document production reduces the number of manual handoffs between sales, application engineering and pricing teams. The benefit is greatest where quotes repeatedly use the same product families and rules.

Fewer configuration and pricing errors

Validation can prevent combinations that a salesperson may not know are technically incompatible. Central pricing logic can also reduce inconsistent discounts and forgotten surcharges. Automation does not eliminate errors if the underlying model or price data is wrong; it moves the control point earlier in the process.

Better engineering capacity

Engineers can spend less time reviewing standard configurations and more time on genuine exceptions, new designs and complex applications. This requires a clear boundary between standard, reviewable and non-standard work.

More consistent manufacturing data

A configuration record linked to a BOM or ERP item can reduce re-entry from quote to order. This is valuable when the quoted product contains many options, quantities or technical attributes.

Improved margin visibility

When cost elements are linked to the configuration, commercial teams can see the effect of material substitutions, custom dimensions, expedited delivery and discounting before committing to a price.

Traceable decisions

Versioned rules, prices, approvals and configuration snapshots make it easier to explain why a quote had a particular scope and price. This supports revision management and post-order analysis.

Limitations and risks

Incorrect product models produce repeatable errors

Automation amplifies the logic it is given. An incomplete dependency, outdated part number or incorrect calculation can create many incorrect quotes quickly. Model validation and test cases are essential.

Engineering knowledge is difficult to encode

Experienced engineers often use tacit knowledge, judgement and exceptions. Converting that knowledge into maintainable rules requires workshops, examples, ownership and agreement on what is standard.

Cost data may not be current

A sophisticated pricing engine cannot compensate for stale supplier prices, missing labor standards or inconsistent overhead assumptions. Data freshness and ownership should be part of the design.

BOM maturity may be misunderstood

A CPQ-generated list may support pricing but lack the revisions, operations and manufacturing context needed for production. The handoff to PLM or ERP must define which system creates and controls the released structure.

ETO remains partially manual

Quote automation can organize ETO work, but it cannot reliably remove engineering review where the product, performance or compliance basis is genuinely new.

Integration creates operational dependencies

Real-time calls to ERP, PLM or CAD may fail because of unavailable services, permissions, latency or inconsistent master data. The implementation needs error handling, reconciliation and a defined fallback process.

Rules can become difficult to maintain

Duplicated logic across CPQ, ERP, CAD and spreadsheets creates conflicting outcomes. A governance model should identify where each rule is authoritative and how changes are released.

Data required for automated quoting

A manufacturing quote automation project normally requires more than a product catalogue. The data foundation may include:

product families, variants and option definitions;
part numbers, revisions, units of measure and lifecycle status;
compatibility, exclusion and requirement rules;
engineering formulas, limits, standards and calculation inputs;
configurable BOM relationships and quantities;
material, purchased-part, labor and overhead costs;
price lists, discounts, customer agreements and currencies;
lead-time, availability and sourcing assumptions;
document templates, technical descriptions and revision references;
approval thresholds and exception categories.

Data should be classified by owner. Product engineering may own technical rules, manufacturing engineering may own production structures, finance or commercial operations may own pricing policies, and ERP administration may own item and cost master data. A CPQ project should not hide these ownership decisions inside application configuration.

Implementation approach

Define the first product scope

Start with a product family that has meaningful quote volume, repeatable rules and measurable business pain. Avoid selecting the most complex product as the first model unless the organization has the resources to manage its engineering exceptions.

Document the current quote process

Map every input, spreadsheet, calculation, approval, system lookup and manual handoff. Identify where errors occur and distinguish standard configurations from exceptions. This process map is more useful than a feature checklist when evaluating software.

Build a governed product model

Define features, options, attributes, constraints, calculations and outputs in a structured model. Use real historical quotes and known invalid combinations as test cases. Decide whether rules belong in CPQ, an engineering service, ERP, PLM or another system.

Separate configuration, cost and price

Do not use a single field to represent an option’s cost, price and commercial description. A selected motor may have a cost, a list price, a customer-specific price, a freight effect and a technical description. These values may come from different sources and change under different controls.

Design the system handoff

Specify what happens when a quote is accepted. Does CPQ create an ERP sales order, send a configuration identifier, request a BOM, create a PLM object, upload CAD parameters or simply pass a PDF to a salesperson? Each exchange needs field mapping, error handling and a clear system of record.

Test combinations and revisions

Testing should include valid configurations, invalid combinations, boundary values, missing data, price changes, currency changes, revisions, approval exceptions and integration failures. Test the generated document as well as the internal configuration and price.

Release and govern the model

Product models need version control, change requests, named owners and release dates. A rule change may affect open opportunities, existing quotes and active orders. The organization should decide whether old quotes retain the old model version or are recalculated under the new one.

The manufacturing CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance in more detail.

How to evaluate quote automation software

Buyers should evaluate the complete quote-to-order use case rather than counting generic CPQ features. Useful questions include:

Can the system model the product’s dimensions, options, dependencies and engineering constraints?
Can non-developers maintain rules, or does every change require custom code?
What types of calculations are supported, and how are calculation versions controlled?
Does the platform generate a sales BOM, configurable BOM, EBOM or MBOM?
How are part numbers, revisions, substitutes and quantities handled?
Can the system connect to authoritative ERP, PLM, PDM, CAD and CRM data?
Can it create CAD models or drawings, or does it only pass parameters to another system?
How are standard configurations separated from ETO exceptions?
Can it show cost, margin, price and approval reasons independently?
How are quote revisions, expired prices and historical configurations stored?
What APIs, webhooks, integration tools and error-monitoring capabilities are available?
How are dealers, distributors, application engineers and internal sales users supported?
What happens when an integration or external calculation service is unavailable?

Vendor documentation and a proof of concept should be used to verify these answers. A demonstration of a simple option-selection flow does not prove that a platform can handle engineering calculations, production structures or CAD automation.

Key measures after deployment

Useful measures should connect automation to manufacturing outcomes. Examples include quote cycle time, percentage of quotes completed without engineering intervention, configuration error rate, quote-to-order conversion, gross-margin variance, approval turnaround time, percentage of quotes using current price data, re-entry between systems and time required to maintain a product model.

Speed alone is not sufficient. A fast quote that contains an invalid motor, incomplete BOM or unsupported delivery promise can increase downstream cost. Quality, traceability and handoff accuracy should be measured alongside response time.

Related concepts

Quote automation is closely related to CAD and engineering automation when a configuration drives models, drawings or calculations. It also depends on BOM generation, costing and pricing and on integration architecture for reliable movement of data. Manufacturers comparing commercial approaches can use the manufacturing CPQ comparison and selection resources.

Semantic map

The following relationships summarize the main entities and data flows described in this guide:

CPQ configures configurable manufactured products.
Configuration rules prevent invalid product combinations.
Constraint-based configuration evaluates engineering limits.
Guided selling collects customer requirements.
Engineering calculations determine technical selections.
A configured product generates a quote-level BOM.
An EBOM represents an engineering product structure.
An MBOM represents a manufacturing product structure.
Costing calculates the expected cost of a configuration.
Pricing converts cost and commercial rules into a selling price.
Approval workflows review commercial and technical exceptions.
Quote documents describe the validated configuration.
CAD automation generates product-specific drawings when supported.
CPQ exchanges customer and configuration data with CRM.
CPQ exchanges item, cost and order data with ERP.
PLM controls product revisions and lifecycle information.
PDM manages engineering files and CAD data.
ETO quoting identifies work that requires engineering review.
CTO quoting uses pre-engineered product rules and modules.
Product model governance controls changes to quoting logic.

Frequently asked questions

What is quote automation for complex manufactured products?

It is the automated conversion of customer requirements into a validated configuration, cost, selling price, approval workflow and quote document. Depending on the platform, it may also produce BOMs, technical specifications or CAD outputs.

How is manufacturing quote automation different from sales CPQ?

Sales CPQ commonly focuses on product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally handle engineering constraints, calculations, configurable BOMs, CAD parameters, production data and ERP or PLM handoffs.

Does quote automation generate a BOM?

Some platforms generate a quote-level or configurable BOM, while others send configuration data to ERP or PLM for BOM creation. Buyers must verify whether the output is a sales BOM, EBOM, MBOM or production-ready structure.

Can CPQ calculate the cost of a configured product?

Many manufacturing CPQ systems support cost models, but the depth varies. Costing may include materials, purchased parts, labor, overhead, freight and engineering effort. The source and freshness of the cost data are critical.

What is the difference between costing and pricing in CPQ?

Costing estimates the manufacturer’s expense to produce or deliver the configuration. Pricing determines the amount charged to the customer using list prices, margins, discounts, agreements, surcharges and other commercial rules.

Can quote automation handle engineer-to-order products?

It can support ETO by capturing requirements, estimating engineering work, recording assumptions and routing exceptions. It should not represent an unverified custom design as a standard, production-ready configuration.

Can a CPQ system create CAD drawings?

Some platforms support CAD automation or connect to CAD automation services. Others only store selections or pass parameters to another system. This capability must be verified for the required CAD tool, model types, drawings and revision process.

What product data is needed to automate quotes?

Typical data includes product families, options, part numbers, rules, calculations, BOM relationships, costs, prices, lead times, technical descriptions, revisions and approval policies.

Where should configuration rules be maintained?

The answer depends on the architecture. Rules may be maintained in CPQ, PLM, ERP, CAD or an external service. The important requirement is to define one authoritative owner for each rule and prevent conflicting copies.

How does quote automation connect with ERP?

CPQ may retrieve item, cost, inventory or customer data from ERP and send back a quote, configuration identifier, BOM request or sales order. The integration can use APIs, middleware or controlled file exchanges.

Does quote automation replace application engineers?

No. It can automate repeatable selections and identify exceptions, allowing engineers to focus on non-standard applications, new designs, performance review and technical risk.

How are invalid configurations prevented?

Rules and constraints can require compatible options, exclude combinations, enforce numeric limits and trigger calculations. The quality of prevention depends on the completeness and maintenance of the product model.

Can quote automation manage different currencies and customer prices?

Many commercial CPQ systems support currencies, price lists, customer agreements and discount rules. Manufacturers should verify exchange-rate control, effective dates, tax handling and how historical quotes retain their original pricing basis.

What is a configurable BOM?

A configurable BOM is a product structure containing rules or selection conditions that determine which components and quantities apply to a particular configuration. It may require transformation into an approved EBOM or MBOM before production.

How should manufacturers test an automated quoting model?

Use historical quotes, valid and invalid combinations, boundary values, price changes, revisions, approval exceptions, missing data and integration failures. Test the configuration, price, BOM, document and downstream transaction together.

What are the main risks of automated quoting?

Common risks include incorrect rules, stale costs, unclear BOM ownership, duplicated logic, integration failures, unsupported ETO assumptions and documents that do not match the configured product.

How should a manufacturer choose a quote automation platform?

Evaluate product-model depth, rules, calculations, BOM outputs, pricing, CAD and engineering integration, ERP and PLM connectivity, workflow, governance, APIs, implementation effort and support for CTO, MTO, ATO and ETO processes.

What is the first product family to automate?

A suitable first candidate usually has substantial quote volume, repeatable configuration rules, available product data and a clear business problem. It should be complex enough to demonstrate value but bounded enough to govern effectively.

How can a manufacturer measure quote automation success?

Measure quote cycle time, engineering effort, configuration errors, margin variance, approval time, re-entry, use of current data and downstream order accuracy. Speed should be assessed alongside technical and commercial quality.

September 22, 2026

Product Bundles and Solution Pricing in Manufacturing CPQ

Product bundles and solution pricing in manufacturing CPQ allow a company to quote a complete engineered solution rather than pricing isolated parts. A bundle may combine a base machine, drive system, control panel, safety equipment, installation accessories and service coverage. The CPQ system validates whether the selected components work together, calculates costs and prices, produces the relevant bill of materials (BOM), routes exceptions for approval and generates a customer-ready quote.

In this context, CPQ means configure, price, quote. Manufacturing CPQ extends beyond generic sales quoting: it can connect product rules and engineering calculations to configurable BOMs, computer-aided design (CAD) outputs, enterprise resource planning (ERP), product lifecycle management (PLM) and production processes. Not every CPQ platform supports all of these capabilities, so manufacturers must verify the depth of product modeling, bundle logic, costing, downstream integration and engineering automation before selecting a system.

A useful starting point is the guide to CPQ software for manufacturing. For the specific product-modeling foundation, see product configuration, and for the downstream commercial and manufacturing data flow see BOM, pricing and quoting.

What are product bundles and solution pricing?

A product bundle is a commercially and technically related group of products, assemblies, options, services or consumables sold as one solution. A bundle can be fixed, configurable or partially configurable. A fixed bundle always contains the same items. A configurable bundle allows choices such as capacity, material, voltage, motor, enclosure, accessories or service level. A solution bundle can also include multiple related products that must be engineered or delivered together.

Solution pricing is the calculation of a price for the complete configured solution rather than simply adding unrelated item prices. It may include component prices, configuration-dependent costs, engineering effort, labor, freight, installation, warranty, risk margins, discounts and commercial adjustments.

For example, a pump manufacturer might sell a chemical-transfer package containing:

a centrifugal pump selected by flow rate, head and fluid compatibility;
a motor selected by power, voltage and hazardous-area requirements;
a baseplate and coupling guard;
valves, strainers and instrumentation;
a control panel and variable-frequency drive;
documentation, testing and commissioning services.

The bundle is not valid merely because every item exists in the catalog. The motor must match the pump duty, the materials must be compatible with the fluid, the control panel must support the selected voltage and the enclosure may need to meet a specified environmental or hazardous-location rating. The final price must reflect the resulting engineering and manufacturing requirements.

How bundles differ from simple product kits

Manufacturers should distinguish a commercial bundle from a manufacturing kit, sales package or configured solution. The terms are sometimes used interchangeably, but they can represent different data and operational behavior.

Concept	Meaning in manufacturing	Typical CPQ requirement
Fixed bundle	A predefined group of items sold together.	Bundle definition, price and component availability.
Configurable bundle	A package with selectable options and dependencies.	Rules, constraints, option pricing and validation.
Solution	A combination of products, assemblies, services and engineering work that addresses a customer requirement.	Cross-product compatibility, calculations, approvals and often project-level pricing.
Kit	A set of parts grouped for picking, assembly or delivery.	Kit structure, inventory behavior and possibly a configurable BOM.
Package or system	A technically integrated equipment group delivered as a functional unit.	System rules, interfaces, engineering outputs and production handoff.

A simple sales bundle may only add several stock items to a quote. A manufacturing solution model may need to create a new assembly structure, select engineered components, calculate dimensions and send data to ERP or PLM. The implementation should therefore define whether the bundle is only a commercial construct, a manufacturing structure, or both.

How manufacturing CPQ models a bundle

A bundle model normally contains a hierarchy of products and assemblies. At the top is the solution or package. Under it are mandatory components, optional modules, substitution groups, accessories, services and engineering outputs.

Bundle structure

A typical industrial equipment bundle might be modeled as follows:

Solution: packaged water-treatment skid.
Primary equipment: pump, tank, filter and heat exchanger.
Drive and controls: motor, variable-frequency drive, panel and sensors.
Mechanical integration: frame, piping, fittings, guards and supports.
Commercial options: extended warranty, spare-parts kit, commissioning and training.
Engineering outputs: configured BOM, specification sheet, layout drawing and installation requirements.

Each node can have attributes, valid values, quantities, dependencies, costs, prices and fulfillment behavior. A component may be included automatically when another option is selected. For example, selecting a high-temperature application may require a different seal material, insulation package and temperature-rated sensor.

Rules and constraints

Rules-based configuration uses explicit conditions such as “if voltage is 480 V, use a 480 V control package.” Constraint-based configuration evaluates permitted relationships and limits, such as motor power, shaft speed, flow, pressure and enclosure requirements. Guided selling asks questions in a sequence that helps a user reach a valid configuration, but it may not provide the same depth of technical constraint solving.

A bundle model may contain several types of rules:

Inclusion rules: selecting a fire-rated enclosure adds a fire-rated door assembly and approved cable glands.
Exclusion rules: two incompatible communication modules cannot be selected together.
Dependency rules: a remote monitoring option requires a gateway and a suitable network connection.
Quantity rules: a long conveyor requires additional supports at defined intervals.
Calculation rules: pump size, motor rating, material thickness or cable size is calculated from technical inputs.
Approval rules: a nonstandard material, discount or delivery commitment requires review.

Detailed guidance on product options, dependencies and validation is available in the product configuration guide.

Solution pricing architecture

Solution pricing should separate the different reasons why a price changes. This makes the model easier to test, explain and maintain.

Pricing layer	Examples	Manufacturing considerations
Component price	Pump, motor, valve or panel list price.	Item revisions, currencies, units and effective dates.
Option price	Stainless-steel construction, upgraded controls or additional sensors.	May replace a standard component rather than add to it.
Quantity price	Additional conveyors, filters or spare parts.	Quantity may be calculated from dimensions or capacity.
Configuration surcharge	Special coating, hazardous-area compliance or nonstandard testing.	Should be tied to a clear technical trigger.
Engineering price	Application engineering, design work or custom documentation.	Often depends on ETO complexity and approval.
Service price	Installation, commissioning, training or maintenance.	May depend on site, duration, travel and scope.
Commercial adjustment	Customer discount, dealer margin or project-level adjustment.	Requires authority limits, approval thresholds and auditability.

The price engine may calculate a list price, net price, cost, gross margin and price explanation. A manufacturer should preserve the distinction between cost and price. Cost may include purchased components, labor, overhead, freight and engineering effort. Price is the amount offered to the customer after margins, discounts and commercial policies are applied.

Bundle pricing strategies

Several pricing approaches can be combined:

Component aggregation: add the prices of all selected items and services.
Bundle price: assign a defined price to a valid combination.
Replacement pricing: subtract the standard component and add the upgraded component.
Tiered pricing: apply different prices based on quantity, capacity or order volume.
Formula pricing: calculate price from dimensions, power, material weight or processing time.
Cost-plus pricing: apply a margin or markup to calculated cost.
Project pricing: combine equipment, services, risk allowances and commercial terms at solution level.

Pricing rules should also handle effective dates, currencies, units of measure, regional price lists, customer-specific agreements and channel margins. If the CPQ price differs from ERP or finance data, the integration must define which system is authoritative for each value.

From configured bundle to BOM

A configured solution can generate one or more BOM structures. A configurable BOM represents possible components and selection logic before a customer configuration is finalized. An engineering BOM (EBOM) represents the product from an engineering and design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced. These structures may be related but are not interchangeable.

For a packaged machine, CPQ might generate:

a quote-level commercial BOM showing customer-visible assemblies;
an EBOM for engineering review and design release;
an MBOM or ERP order structure for purchasing, routing and production;
a spare-parts list and service BOM for after-sales use.

Whether CPQ directly creates an EBOM or MBOM depends on the platform architecture and integration design. Some systems produce a structured order configuration that ERP, PLM or a product data management (PDM) system transforms into the appropriate downstream structure. Others can generate production-relevant BOM lines directly. This capability must be verified rather than assumed.

For a deeper treatment of BOM structures and quote generation, see BOM, pricing and quoting in manufacturing CPQ.

Relationship with CAD and engineering automation

Bundles become more valuable when technical selections drive engineering outputs. A CPQ platform may pass configuration parameters to CAD automation, a rules-based design service or a separate engineering application. Possible outputs include a parametric 3D model, 2D drawing, dimensional specification, load calculation or equipment layout.

For example, a conveyor solution may use belt width, length, incline angle, product weight and throughput to determine frame sections, drive power, support spacing and guarding. The resulting dimensions can affect both the BOM and the price. If the system only changes the quote description without updating engineering data, the bundle is commercially configured but not fully engineered.

CAD automation is not a universal CPQ feature. Manufacturers should verify whether a prospective system can:

store or calculate the parameters required by the CAD model;
call an external CAD or engineering service;
generate drawings or neutral files;
maintain revision and approval status;
return calculated dimensions and components to the CPQ model;
handle failures, incomplete inputs and manual engineering review.

The CAD and engineering automation guide explains how these capabilities fit beside configuration and quoting.

Approvals and commercial governance

Solution pricing often creates approval requirements that do not exist for standard products. Approval triggers may include a margin below threshold, an unusual payment term, a nonstandard material, a custom delivery date, a safety-critical application or a large engineering commitment.

A practical approval workflow should show:

which rule or threshold triggered the approval;
what cost, price, margin or technical value is affected;
which person or role must review the exception;
whether the approval changes the configuration, price or terms;
which version of the configuration and pricing model was approved.

Approvals should not be used to compensate for missing product rules. If sales repeatedly requests approval for a combination that is always valid, the product model may need a new rule or standard option. Conversely, an approval should not override a genuine safety or technical constraint without a controlled engineering process.

Quote documents for bundled solutions

The quote should communicate enough detail for the customer to understand the proposed solution without exposing internal manufacturing structures unnecessarily. A bundle quote may contain:

solution summary and application assumptions;
selected equipment and major options;
technical specifications and exclusions;
commercial price by system, assembly or service category;
delivery, installation and commissioning scope;
warranty, payment and validity terms;
drawings, rendered views or preliminary layouts where available;
approval notes and revision information.

Customer-facing descriptions and internal BOM descriptions should be governed separately. A sales quote might describe “stainless-steel product-contact construction,” while the internal structure contains specific grades, fasteners and purchased parts. Both representations must remain linked to the same approved configuration.

Enterprise-system relationships

Bundle pricing normally involves several systems with different responsibilities.

System	Typical responsibility	Example exchange with CPQ
CRM, or customer relationship management	Accounts, opportunities, contacts and sales activity.	Opportunity context, customer and quote status.
ERP, or enterprise resource planning	Items, inventory, purchasing, orders, finance and production transactions.	Item masters, costs, orders, availability and order structures.
PLM, or product lifecycle management	Product revisions, engineering releases, change control and lifecycle data.	Released options, revisions, EBOMs and engineering status.
PDM, or product data management	CAD files, drawings and design metadata.	CAD references, revisions and generated design files.
CAD	Geometry, drawings and design calculations.	Parameters, models, layouts and drawings.
PIM, or product information management	Descriptions, attributes, media and channel content.	Customer-facing product information and option content.
MES, or manufacturing execution system	Shop-floor execution, work instructions and production status.	Released orders, routings or configuration-specific instructions.

These systems are not interchangeable. A CPQ platform may own the selling configuration and calculated quote, while ERP owns the order and financial transaction. PLM may own engineering revisions, and CAD or PDM may own design files. The integration architecture should document ownership, synchronization frequency, identifiers, revision behavior and error handling. More guidance is available in CPQ integrations for manufacturing.

Bundle workflows by manufacturing strategy

Bundles can support several operating models, but the required depth differs.

Assemble-to-order (ATO): standard modules are assembled after the order. CPQ must select compatible modules and produce an order structure.
Make-to-order (MTO): the product is made after the order using a relatively standard design. Pricing, availability and production data are central.
Configure-to-order (CTO): customers select from predefined options and constraints. A valid configuration can usually map to known BOM and routing patterns.
Engineer-to-order (ETO): the order requires new or materially changed engineering. CPQ must capture requirements, estimate engineering work and hand off controlled inputs for design.

A bundle can begin as CTO and become ETO when a customer requests a nonstandard capacity, interface or material. The system should make that transition explicit rather than pretending every solution is a standard configuration. See manufacturing CPQ workflows for related order-to-production patterns.

Benefits and limitations

Potential benefits

Fewer incompatible combinations reach the customer or engineering team.
Prices reflect selected options, calculated quantities and engineering scope.
Sales engineers can quote complete solutions with less manual spreadsheet work.
Configured BOM data can reduce re-entry between sales, engineering and ERP.
Approval decisions become traceable and tied to configuration and margin data.
Quote documents can present consistent technical and commercial information.

Important limitations

A CPQ model is only as accurate as its product, cost and rule data.
Complex engineering calculations may require specialist applications or manual review.
Dynamic pricing can become difficult to maintain if formulas are undocumented.
Different BOM structures may require transformation between CPQ, PLM and ERP.
Frequent product changes create governance and regression-testing demands.
Large bundles can produce performance, usability and version-control challenges.
Commercial bundling does not automatically solve inventory, capacity or scheduling constraints.

Implementation approach

A successful implementation starts with a defined scope rather than attempting to model every product and exception at once.

Select a representative bundle: choose a product family with meaningful configuration, pricing and downstream impact.
Map the current workflow: document how requirements, options, costs, approvals, BOMs, drawings and orders move between teams.
Define system ownership: identify where items, costs, prices, rules, revisions, CAD files and customer data are maintained.
Separate standard and engineered content: mark which choices are CTO-valid and which trigger ETO review.
Build the product model: create attributes, options, dependencies, constraints, calculations and bundle structures.
Design the price model: define cost sources, price lists, formulas, discounts, margins, currencies and approval thresholds.
Define output structures: specify quote lines, configurable BOMs, EBOM or MBOM mappings, drawings and ERP order data.
Test realistic scenarios: include valid, invalid, boundary, obsolete, partially specified and exception configurations.
Establish governance: assign rule ownership, release procedures, version control, audit records and change-impact testing.
Measure operational results: track quote cycle time, configuration corrections, approval delays, engineering rework and order-data errors.

Implementation planning should include data migration, integration testing, user adoption and ongoing maintenance. The manufacturing CPQ implementation guide covers these concerns in more detail.

Evaluation checklist for manufacturing buyers

When evaluating CPQ software for bundled industrial solutions, ask vendors to demonstrate a complete scenario rather than isolated features:

Can the system model nested bundles, substitutions and cross-product dependencies?
Can technical constraints prevent invalid combinations before quote submission?
Can calculated dimensions, capacities or quantities affect both BOM and price?
Can the system distinguish customer-visible bundle lines from internal component structures?
Can it calculate cost, margin, price and discount independently?
Can approval rules identify technical, commercial and engineering exceptions?
Can it produce the required quote, specification, BOM or order outputs?
Which capabilities are native, and which require custom development or external services?
How are product revisions, effective dates and obsolete options governed?
How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
Can the model support dealer, distributor, internal sales engineering and customer self-service channels?
How are failed calculations, integration errors and incomplete ETO requirements handled?

Vendor profiles and comparisons can help structure research, but manufacturers should validate documented capabilities through a scenario-based demonstration and technical proof of concept. See manufacturing CPQ software profiles and CPQ comparison and selection guidance.

Semantic map

The following relationships summarize how product bundles connect configuration, pricing, engineering and manufacturing execution:

CPQ configures configurable products.
Configuration rules prevent invalid combinations.
Product bundles combine products, assemblies and services.
Solution pricing calculates a commercial price for a configured solution.
Configured products generate configurable BOMs.
Engineering rules determine component compatibility.
Cost calculations inform solution pricing.
Approval rules govern commercial and technical exceptions.
CAD automation generates product-specific drawings.
EBOMs represent engineering product structures.
MBOMs represent manufacturing assembly structures.
CPQ exchanges item and order data with ERP.
CPQ exchanges revisions and released structures with PLM.
CRM provides opportunity and customer context to CPQ.
ETO requirements trigger engineering review.
Quote documents communicate approved solution scope.

Frequently asked questions

1. What is a product bundle in manufacturing CPQ?

A product bundle is a group of related equipment, components, options and services sold as one configurable solution. It may also produce a structured BOM for engineering or production.

2. How is solution pricing different from adding item prices?

Solution pricing can include compatibility-driven substitutions, calculated quantities, engineering effort, services, risk allowances, discounts and project-level approvals in addition to component prices.

3. Can a bundle contain products from different product families?

Yes. A pump package, for example, may contain a pump, motor, valves, controls, piping and services. Cross-family rules must validate interfaces, capacities, materials and electrical requirements.

4. Does every CPQ system generate a BOM?

No. Some CPQ platforms generate quote lines or order configurations only. Others generate configurable BOMs or integrate with ERP and PLM to create downstream structures. This must be verified for each product.

5. What is a configurable BOM?

A configurable BOM describes possible components and selection logic before a specific customer configuration is finalized. It differs from an EBOM or MBOM, which represent engineering or manufacturing structures.

6. Can CPQ generate an EBOM?

Some systems can generate or export engineering-oriented structures, while others pass configuration data to PLM or engineering tools. The supported revision, release and transformation process should be documented.

7. Can CPQ generate an MBOM?

Some platforms or integrations can create manufacturing-relevant structures, but this is not universal. ERP or manufacturing systems may own the MBOM and transform data received from CPQ or PLM.

8. How do bundle rules prevent configuration errors?

Rules enforce inclusions, exclusions, dependencies, quantities, technical limits and required approvals. They can prevent incompatible motors, materials, controls or accessories from reaching the quote.

9. What happens when a bundle requires custom engineering?

The configuration can be routed to an ETO workflow. CPQ may capture requirements, estimate engineering effort, flag assumptions and hold the quote for engineering review.

10. Can solution pricing include installation and commissioning?

Yes. Services can be modeled as bundle components or calculated charges. The model may use site conditions, duration, travel, labor rates and scope assumptions.

11. How should costs and prices be separated?

Costs represent internal or supply-side economic inputs such as materials, labor and engineering. Prices are customer charges after margins, discounts, terms and commercial policies are applied.

12. Can bundle pricing vary by customer or region?

It can, provided the pricing model supports customer agreements, regions, currencies, channels, effective dates and approval controls. The authoritative source for each price should be defined.

13. Is CAD automation required for manufacturing bundles?

No. Many bundles can be quoted without automated CAD. CAD automation becomes important when selections change geometry, dimensions, drawings, layouts or engineering calculations.

14. How does CPQ connect bundles to ERP?

Depending on the architecture, CPQ may exchange item identifiers, prices, configuration data, BOM lines, customer information and order details with ERP. Ownership and error handling must be designed explicitly.

15. How does PLM differ from ERP in a bundle workflow?

PLM generally manages product revisions, engineering releases and lifecycle data. ERP manages transactions such as purchasing, inventory, costing, orders and production. Both may receive different outputs from CPQ.

16. Can distributors use manufacturing CPQ bundles?

Yes. A dealer or distributor channel can use a controlled bundle model with permitted options, channel pricing, customer-specific discounts and quote outputs while protecting technical rules.

17. What approval triggers are common for solution pricing?

Common triggers include low margin, unusual discounts, nonstandard materials, safety-sensitive applications, custom delivery commitments, large engineering effort and exceptional commercial terms.

18. How should bundle models be tested?

Test valid and invalid combinations, boundary values, substitutions, obsolete options, price changes, revision changes, incomplete requirements, integration failures and ETO escalation paths.

19. What is the main limitation of a bundle model?

It can become difficult to maintain when rules, prices, BOM mappings and engineering exceptions are undocumented or owned by different teams without coordinated governance.

20. What should manufacturers ask during a CPQ demonstration?

Ask the vendor to configure a realistic multi-product solution, apply technical rules, calculate cost and price, trigger an approval, generate the required BOM and quote, and show the ERP, PLM or CAD handoff.

September 22, 2026

Price Books and Product Configuration in Manufacturing CPQ

In manufacturing CPQ, a price book is a controlled set of prices, discounts, surcharges, costs, currencies and commercial conditions that a Configure, Price, Quote (CPQ) system applies to a valid product configuration. Product configuration determines what can be sold; the price book determines how that valid configuration is valued for a particular market, customer, channel or date.

The two functions must work together. A configured industrial pump may require a specific motor, seal, impeller material and control panel. Configuration rules confirm that the combination is technically valid. The price book then assigns prices to the selected options, applies quantity or customer terms, adds engineering or freight charges where appropriate and produces a quote. In manufacturing CPQ, the same configuration may also generate a bill of materials (BOM), engineering outputs and data for enterprise systems.

This is different from a generic sales CPQ application that simply selects products from a catalogue and applies discounts. Manufacturing price management often depends on dimensions, materials, capacity, regional conditions, production costs, engineering effort and downstream manufacturing data.

What is a price book in manufacturing CPQ?

A manufacturing CPQ price book is a structured pricing model containing the commercial values and rules used to price products and options. It can include base prices, component prices, calculated prices, customer-specific prices, channel discounts, minimum margins, validity dates, currencies, taxes, freight, installation and non-recurring engineering charges.

A price book is not the product model itself. The product model defines products, features, options, dependencies and constraints. The price book references those product elements and supplies monetary values or pricing logic.

Element	Primary question	Manufacturing example
Product model	What can be configured?	Which pump sizes, materials and seal types are compatible?
Configuration rules	Which combinations are valid?	A high-temperature seal is required for a specified fluid temperature.
Price book	What should the valid configuration cost or sell for?	A stainless-steel casing adds a defined amount or uses a calculated rate.
Cost model	What does the manufacturer expect to spend?	Material, labor, machining and purchased-component costs.
Quote document	How is the commercial offer presented?	Line items, options, terms, delivery assumptions and totals.

How product configuration and price books work together

The normal sequence is configuration first, pricing second, although the user interface may show indicative prices while the product is being configured.

Select a product family. A salesperson or dealer starts with a pump, conveyor, switchgear assembly, industrial vehicle or other configurable product.
Capture requirements. Inputs may include flow, pressure, voltage, load, dimensions, temperature, material, environment and required delivery date.
Apply configuration rules. The CPQ system filters invalid options, recommends compatible choices or blocks combinations that cannot be engineered or manufactured.
Resolve the configuration. The system records selected options, calculated values, quantities and any unresolved engineering questions.
Calculate costs and prices. Price rules read the configuration and retrieve or calculate the values required for the commercial offer.
Generate downstream outputs. Depending on the platform, CPQ may create a configurable BOM, engineering request, CAD output, order payload or ERP quote.
Route approvals. Discounts, low margins, unusual terms, non-standard options or engineering effort can trigger approval workflows.
Generate the quote. The final document presents the configured product, included and excluded items, price, delivery assumptions and commercial terms.

The configuration result should be the shared reference for pricing, BOM generation and quoting. Re-keying selected options into a separate spreadsheet or ERP screen creates opportunities for discrepancies between what was quoted and what is eventually manufactured.

See the detailed guide to product configuration and configuration rules for a deeper explanation of product models, dependencies and constraints.

Price book architecture for configurable products

Base product prices

A base price represents a standard product or starting configuration. For example, a centrifugal pump family may have base prices for each frame size. The base price should have a clear scope: it may include a standard motor and coupling, or it may represent only the bare pump.

Option and component prices

Options can be priced as fixed additions, replacements, quantities or formula-driven values. A stainless-steel wetted-part package may add a fixed amount. A longer conveyor frame may be priced per metre. A larger motor may replace the standard motor rather than add its full list price.

Formula-based pricing

Some products cannot be priced accurately with a simple option table. Formula-based pricing can use dimensions, capacity, surface area, weight, power, material grade or production time. An enclosure might be priced from width, height, depth and material. A heat exchanger may require a calculation based on area and selected metallurgy.

Formula inputs must be governed carefully. A pricing formula should not be used to approve a technically invalid configuration. Engineering rules validate the product; pricing formulas value the valid result.

Customer, channel and market price books

Manufacturers may maintain different commercial views for direct sales, distributors, original equipment manufacturers (OEMs), service partners or export markets. A price book can be selected by customer account, sales channel, territory, currency, contract or business unit.

These variations should not create hidden product rules. A distributor discount may change the selling price, while a voltage option or material restriction belongs in the product model. Separating commercial rules from engineering rules improves maintenance and auditability.

Effective dates and version control

Price books normally require effective-from and effective-to dates. A quote created before a raw-material price increase may need to retain the earlier price, while a new quote uses the current book. Version control is particularly important when open opportunities, blanket orders and engineering revisions overlap.

Pricing, costing and margins

Pricing and costing are related but not identical. Costing estimates what the manufacturer expects to spend. Pricing determines what the customer is charged. A CPQ system may support one, both or neither in depth, so buyers should verify the documented capability.

Calculation	Typical inputs	Purpose
Material cost	Material type, quantity, weight, waste and current rates	Estimate direct material expenditure
Purchased-part cost	Supplier item, quantity, currency and procurement price	Value motors, valves, drives and other bought-in parts
Labor or process cost	Operations, work centres, setup and run time	Estimate manufacturing effort
Engineering charge	Design hours, review effort and non-standard requirements	Recover ETO or application-engineering effort
Sell price	Cost, margin, market, customer terms and discount	Produce the commercial offer

A manufacturer may use a cost-plus model, target margin, price matrix, market price, contract price or a combination. For example, the cost of a custom mounting frame may be calculated from steel weight and fabrication hours, while the sell price is controlled by a product-family margin policy.

Discounting should be applied after the system has established the applicable list or calculated price, unless the commercial model explicitly requires another sequence. Approval thresholds may use gross margin, absolute discount, total order value, contribution margin or deviation from an approved price corridor.

How configuration affects BOM generation and quoting

A valid configuration can drive a configurable BOM. A BOM is a bill of materials: the list of components, quantities and relationships required for a product. In manufacturing, it is important to distinguish an engineering BOM (EBOM), which describes the product from an engineering perspective, from a manufacturing BOM (MBOM), which organizes items and operations for production.

CPQ may generate a sales or configured BOM that is later transformed into an EBOM or MBOM by PLM, ERP or manufacturing engineering systems. Other implementations may generate a production-ready structure directly. This depends on the product model, integration architecture and platform capability.

For a configurable electrical cabinet, the selected enclosure size, breaker ratings, busbar arrangement, cable-entry position and accessories can determine:

which components appear in the configured BOM;
the quantity of breakers, terminals and cable glands;
the estimated material cost;
the description shown on the quote;
the engineering or panel-layout work required;
the data sent to ERP or a manufacturing system.

Pricing and BOM logic should be coordinated but not conflated. A line item may be commercially bundled while remaining several manufacturing components. Conversely, a component can appear in the BOM without being shown as a separate quoted line.

Rules that connect configuration to price

Manufacturing CPQ commonly uses several types of rules. They solve different problems.

Rule type	Function	Example
Compatibility rule	Prevents invalid combinations	A motor voltage must match the selected control panel.
Selection rule	Adds or removes dependent options	Selecting outdoor installation adds a weatherproof enclosure requirement.
Calculation rule	Derives a technical or commercial value	Frame length is calculated from conveyor travel distance.
Pricing rule	Assigns or modifies a price	A hazardous-area certification adds a defined surcharge.
Approval rule	Routes an exception for review	A discount below the approved margin requires management approval.

Rules should have clear ownership. Product engineering may own compatibility and technical calculations. Product management may own standard option structures. Finance or commercial operations may own discount policies and price-book governance. IT or a CPQ administrator may implement and test the rules, but should not become the only person who understands the product model.

Illustrative example: pricing a configurable industrial pump

Consider a pump configured for a chemical-processing application. The user selects flow rate, discharge pressure, casing material, impeller material, seal type, motor power, hazardous-area certification and control method.

The configuration model may enforce the following:

the selected impeller must meet the required operating point;
the motor must provide sufficient power with an engineering margin;
the seal material must be compatible with the fluid and temperature;
hazardous-area certification requires an approved motor and terminal arrangement;
the selected control method must be compatible with the motor and drive;
some casing materials may be unavailable for the selected pressure class.

After validation, the pricing engine can calculate the base pump price, material upgrades, motor price, seal package, certification surcharge, control-panel price, engineering charge and freight assumption. The configured BOM can include the casing, impeller, shaft, seal, motor, coupling, baseplate, instrumentation and documentation package.

If the customer requests a non-standard operating point, the system may create an engineer-to-order (ETO) task rather than silently pricing the configuration as standard. The quote can show a provisional price or an allowance, with final approval required after engineering review.

Quote documents and commercial transparency

A quote document should make the relationship between configuration and price understandable without exposing unnecessary internal logic. Depending on the sales process, it may include:

configured product name and description;
key technical parameters and selected options;
included accessories and exclusions;
quantity, unit price and extended price;
discounts, surcharges, taxes and freight assumptions;
estimated lead time or delivery conditions;
engineering, installation, commissioning or documentation charges;
validity period and applicable terms;
approval notes or conditions for non-standard requirements.

A customer-facing document should not imply that an engineering drawing, delivery date or certification is final if those items still require review. Quote templates need status indicators and carefully defined language for provisional configurations.

Integration with ERP, CRM, PLM, PDM and CAD

Each enterprise system has a different responsibility. Customer relationship management (CRM) software manages accounts, opportunities and sales activities. Enterprise resource planning (ERP) manages commercial transactions, inventory, purchasing, production and financial processes. Product lifecycle management (PLM) manages product structures, revisions and engineering lifecycle information. Product data management (PDM) commonly manages CAD files and related design data. Computer-aided design (CAD) systems create engineering models and drawings.

CPQ can sit between customer requirements and these systems, but the exact boundary must be designed rather than assumed.

System	Potential exchange with CPQ
CRM	Opportunity, account, salesperson, quote status and commercial activity
ERP	Items, prices, customers, inventory context, orders, costs and financial data
PLM	Product revisions, approved structures, lifecycle status and engineering definitions
PDM	CAD documents, files, metadata and revision references
CAD	Parameters, model selections, drawings, layouts and design outputs
MES	Manufacturing execution data, operations or production instructions in selected architectures
PIM	Product descriptions, attributes and commercial content for channels

Integration can be real-time, scheduled, event-driven or file-based. A price book may be mastered in CPQ, ERP or a dedicated pricing system. Product attributes may be mastered in PLM or PIM. Duplicating the same price and product rule in multiple systems creates version conflicts, so every important data element should have an identified system of record.

See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD and other systems.

Manufacturing workflows: CTO, ETO, MTO and ATO

Price-book design depends partly on the manufacturing strategy.

Configure-to-order (CTO): the customer selects from a controlled product model and the resulting configuration can be produced using known structures and processes.
Engineer-to-order (ETO): the sale triggers new or modified engineering work. Pricing may need engineering estimates, assumptions and later revision.
Make-to-order (MTO): production starts in response to an order, often using a defined product or configuration.
Assemble-to-order (ATO): standard modules are stocked or prepared and assembled after the order.

In CTO and ATO, price books can often be relatively deterministic. In ETO, the price model may need allowances, engineering hours, risk factors, review stages and change control. A CPQ implementation should show where automated pricing ends and engineering quotation begins.

Learn more about configure-to-order, engineer-to-order and related manufacturing workflows.

Benefits of integrating price books with configuration

Faster quoting: sales engineers do not need to rebuild option prices manually for every valid configuration.
Fewer commercial errors: incompatible options, omitted accessories and incorrect replacement pricing are easier to control.
More consistent margins: discounts and surcharges can be evaluated against cost and policy.
Better engineering handoff: the selected configuration and assumptions accompany the quote.
Traceable BOM and price relationships: commercial line items can be connected to the components that drive cost.
Controlled regional and channel pricing: different books can be governed without cloning the entire product model.
More reliable quote documents: the document can be generated from the validated configuration rather than manually re-entered data.

Limitations and implementation risks

Connecting price books to a product configurator does not automatically produce accurate manufacturing prices. Common risks include:

Incomplete product data: missing option relationships or obsolete items lead to invalid configurations and inaccurate prices.
Ambiguous ownership: no team knows who approves price changes, engineering rules or product revisions.
Overly complex formulas: pricing logic becomes difficult to test and explain.
Duplicated masters: CPQ, ERP and spreadsheets contain different versions of prices or components.
Bundling problems: a customer-facing bundle hides manufacturing components needed for costing or production.
Unmanaged exceptions: sales teams use manual overrides for non-standard products without recording the reason.
Weak effective dating: old opportunities are repriced unintentionally after a new price release.
Insufficient testing: a price change fixes one product family but breaks a related configuration or channel.

A price book should not be treated as a spreadsheet import alone. It is part of a governed product and commercial data model.

Implementation approach

1. Define the commercial and engineering scope

Start with a limited product family and document the quote-to-order process. Identify which options are standard, which require engineering review and which are not currently supported.

2. Map product and price data

Inventory product families, option codes, units of measure, revisions, costs, price lists, currencies, discount schedules, customer agreements and quote templates. Identify duplicates and obsolete records before migration.

3. Separate rule categories

Document compatibility, selection, calculation, pricing and approval rules separately. This makes testing and ownership clearer.

4. Establish systems of record

Decide whether CPQ, ERP, PLM, PDM or another system owns each product, price, cost, customer and revision attribute. Define synchronization frequency and conflict handling.

5. Model the BOM and quote views

Specify which components are shown to the customer, which remain internal, how configurable BOMs map to EBOM or MBOM structures and how replacements, quantities and phantom assemblies are handled.

6. Test combinations and commercial scenarios

Test valid and invalid configurations, boundary dimensions, price-book dates, currencies, customer discounts, low-margin cases, engineering exceptions and revisions. Recalculate the same quote after a price release to confirm intended behavior.

7. Govern releases

Use controlled changes, approvals, effective dates and audit history. A price release should identify affected product families, customers, quotes and integrations. Product and commercial teams should be able to review changes without relying on undocumented code.

The wider CPQ implementation guide covers data migration, architecture, testing, governance, deployment and maintenance.

How to evaluate a CPQ configurator for price-book use

When evaluating a CPQ configurator, ask vendors and implementation partners to demonstrate a real manufacturing scenario rather than a simple catalogue discount. Useful tests include:

Can the system represent dependencies between dimensions, materials, motors and accessories?
Can a price be fixed, formula-based, quantity-based or derived from a replacement component?
Can different price books be selected by customer, channel, currency, region and effective date?
Can the system distinguish cost, list price, net price and margin?
Can a configuration generate a BOM or pass structured data to another system?
Can non-standard configurations be routed to engineering without being treated as standard?
Can users see why an option is unavailable or why approval is required?
Can rules and prices be tested independently and audited after release?
Can quote documents show technical selections and commercial conditions accurately?
What is documented for ERP, CRM, PLM, PDM, CAD and API integration?

Do not assume that a platform offering price books also provides deep product configuration, CAD automation, BOM generation, engineering calculations or PLM integration. Verify each capability, its data requirements and the implementation responsibility.

Semantic map

Price books and product configuration form a connected manufacturing data chain: customer requirements lead to a validated product configuration; the configuration drives prices, costs and potentially BOM and CAD outputs; the resulting quote can move through approval into ERP, PLM, CRM or production workflows.

Product requirements connect to product configuration.
Product configuration connects to compatibility and calculation rules.
Validated options connect to price-book entries and pricing formulas.
Configured products connect to configurable BOMs.
Configurable BOMs connect to EBOM, MBOM or ERP structures.
Configuration parameters can connect to CAD automation and engineering calculations.
Price and cost results connect to margin and approval rules.
Approved configurations connect to quote documents and order processes.
CPQ connects commercial, engineering and manufacturing systems through integrations.

Frequently asked questions

What is the difference between a price book and a product configurator?

A price book supplies prices and commercial rules. A product configurator determines which product options and combinations are valid. Manufacturing CPQ connects the two so that a valid engineered configuration receives an appropriate price.

Can a price book contain configuration rules?

It can contain price-dependent conditions, but technical compatibility rules should normally reside in the product model or rules engine. Keeping technical and commercial logic separate makes both easier to govern.

Does every CPQ system generate a BOM?

No. Some CPQ systems generate configurable BOMs, while others pass selections to ERP, PLM or an engineering application that creates the structure. This capability must be verified for the specific product and integration architecture.

How does configuration affect product pricing?

Configuration selects the components, dimensions, materials and services that drive the price. The pricing engine can then apply fixed option prices, replacement prices, formulas, customer terms and discounts.

Can one product have multiple price books?

Yes. Manufacturers commonly maintain books for regions, currencies, distributors, OEM contracts, customer accounts or sales channels. Effective dates and selection priorities should be explicitly governed.

Should costs and prices be stored in the same price book?

They may be managed in the same CPQ model, but cost and sell price should remain distinct data elements with separate visibility and governance. Costs support margin analysis; prices support the commercial offer.

How are dimensions used in a manufacturing price book?

Dimensions can select a price tier or feed a formula. For example, conveyor length may determine material quantity, fabrication effort, freight class and selling price.

How are discounts applied to configured products?

Discounts can be applied by product family, customer, channel, quantity, contract or total quote value. Approval rules should evaluate the resulting margin and any exceptions.

What happens when a configuration requires engineering work?

The CPQ process can create an ETO or engineering-review task, include an allowance or estimate, and prevent the quote from being treated as fully final until engineering confirms the design.

Can CPQ price a configurable BOM?

Yes, where the platform supports BOM-driven pricing. It can value components, quantities, replacements and assemblies, although the final production BOM may be created or transformed in ERP or PLM.

How do EBOM and MBOM affect CPQ pricing?

An EBOM describes the engineered product, while an MBOM organizes production requirements. CPQ may use a sales BOM or configured structure and pass it to systems that create or manage the EBOM and MBOM.

Can price books include freight and installation?

They can, if the CPQ design includes those commercial elements. Freight may depend on weight, dimensions, destination and shipping class, while installation may depend on scope, location and engineering assumptions.

How should price-book revisions be controlled?

Use version numbers, effective dates, approvals, audit history and regression testing. Define whether existing quotes retain their original price or are recalculated under a new release.

What is a price override in manufacturing CPQ?

A price override is a deliberate change to the calculated or approved price. It should record the user, reason, amount, margin impact and approval status rather than silently replacing the system result.

Can a CRM own the manufacturing price book?

A CRM may display or consume pricing, but it is not automatically the best system of record for complex product, cost and manufacturing logic. Ownership should be selected according to data complexity, governance and integration requirements.

How does CAD automation relate to price books?

CAD automation uses configuration parameters to create product-specific models or drawings. Its outputs may affect BOM content, engineering effort and price, but CAD generation and price-book management are separate capabilities.

What should manufacturers test before launching a price book?

Test valid and invalid configurations, formula boundaries, replacements, currencies, discounts, effective dates, customer contracts, margin approvals, BOM results, quote documents and integration payloads.

September 21, 2026

Lead-Time Calculation During Product Configuration

Lead-time calculation during product configuration is the process of estimating when a specific configured product can be completed and delivered. In manufacturing CPQ, the calculation may use the selected options, generated bill of materials (BOM), inventory, supplier lead times, engineering effort, production operations, capacity, approvals and shipping rules.

A manufacturing CPQ system, meaning Configure, Price, Quote software, should not treat lead time as a fixed number attached to a product family. A pump with a standard motor, stocked seal and existing design may have a very different lead time from the same pump with a special alloy, custom impeller, non-standard voltage and customer-specific drawings.

The result can be an estimated lead time, a production date, a promised ship date or a delivery-date range. The quality of that result depends on the product model, BOM data, manufacturing calendars, inventory accuracy and the integration between CPQ and systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) and computer-aided design (CAD).

Lead time is therefore part of the configuration, costing and quoting process. It should be calculated from the selected product characteristics and the work required to fulfill them, rather than copied from a generic catalog record.

Why lead time belongs in manufacturing CPQ

Generic sales CPQ often calculates price, discount and quote totals. Manufacturing CPQ must frequently determine whether the selected product can be engineered, sourced and produced within a realistic time frame. This requires more than a sales promise.

During configuration, the system may identify:

which components are required by the configured product;
whether components are in stock, allocated or subject to replenishment;
which operations are required and in what sequence;
whether engineering calculations, CAD changes or approvals are needed;
whether selected options trigger supplier or subcontractor lead times;
whether the product is configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO) or engineer-to-order (ETO);
whether available production capacity supports the requested date.

The calculated result can then appear in the quote document alongside price, assumptions, validity period, configuration summary and delivery terms. See the guide to BOMs, pricing and quoting for the relationship between these outputs.

What data is required for lead-time calculation?

A useful lead-time model combines commercial, product, engineering and operational data. A CPQ configurator may hold some of this data directly, while other values are retrieved from connected enterprise systems.

Data category	Examples	Effect on lead time
Product configuration	Dimensions, materials, motor size, voltage, pressure rating, accessories	Determines required components, operations and engineering rules
Configured BOM	Raw materials, purchased parts, subassemblies and optional items	Identifies dependent procurement and production work
Inventory	Available, reserved, safety stock and incoming quantities	Changes whether a part can be issued immediately
Routing	Cutting, machining, welding, painting, assembly, inspection and testing	Defines processing time and operation sequence
Supplier data	Standard and expedited supplier lead times, order calendars	Determines external procurement constraints
Engineering work	Selection calculations, drawing updates, design review and approval	Adds effort before or during production
Calendars and capacity	Shifts, holidays, work centers, queues and maintenance periods	Converts work duration into realistic dates
Logistics	Packaging, carrier service, export documentation and transit	Converts completion date into delivery date

How the calculation works

1. Validate the configuration

The system first evaluates product rules and constraints. For example, a valve configuration may require a particular body material for a corrosive fluid, prohibit a pressure rating with a selected actuator, and require a positioner when a control signal is specified.

Invalid combinations should be blocked before lead time is calculated. Otherwise the system may produce a date for a product that cannot be engineered or manufactured. Rules may also assign lead-time effects. A standard motor may add no additional delay, while a custom motor may add six supplier weeks.

Rules-based configuration applies explicit if-then logic. Constraint-based configuration evaluates permitted and prohibited combinations across multiple parameters. Guided selling asks questions and recommends suitable options, but it does not by itself guarantee a manufacturable configuration. These distinctions are explained further in the product configuration guide.

2. Generate or resolve the configured BOM

The configured BOM identifies the materials, components and subassemblies needed for the selected product. A configurable BOM may contain conditional items, quantities, alternates and phantom assemblies. The CPQ result may be an engineering bill of materials (EBOM), a manufacturing bill of materials (MBOM), or data that is transformed into one of these structures by an ERP or PLM system.

An EBOM describes the product from an engineering perspective. An MBOM describes how it will be manufactured, including plant-specific operations and production structure. They are related but not interchangeable. For lead-time calculation, the system needs to know which structure contains the relevant purchasing and manufacturing dependencies.

For example, selecting a stainless-steel pump casing can change the BOM from a stocked cast iron casing to a made-to-order casting. That one option can affect material procurement, machining, inspection and the final assembly sequence.

3. Check inventory and procurement

The system evaluates whether required items are available. It should distinguish unrestricted stock from reserved stock, quality-hold stock, safety stock and expected receipts. A simplistic check that only looks for a part number can produce an unreliable date.

For unavailable items, the calculation may use supplier lead time, purchase-order status, minimum order quantities, receiving time and inspection time. Long-lead components can become the critical path. The critical path is the sequence of dependent activities that determines the earliest possible completion date.

Inventory and supplier data commonly come from an ERP system or supplier-management process. CPQ should show whether the value is real-time, periodically synchronized or maintained manually. A quote should not present a precise date if the underlying availability is stale.

4. Add engineering and design effort

Standard configurations may use an approved design and require no additional engineering. Other configurations may need sizing calculations, CAD model updates, drawings, design review, customer approval or a new part number.

Engineering effort can be modeled as fixed activities, conditional activities or calculated work. For example, a conveyor configured within an approved dimensional range may use an existing parametric design. A conveyor outside that range may trigger ETO work, including structural analysis and a new fabrication drawing.

CAD automation can generate product-specific drawings or models, but not every CPQ platform provides CAD automation. Where it is used, the calculation should account for generation, review and release time. See CAD and engineering automation in CPQ.

5. Calculate manufacturing operations

Manufacturing duration may include setup time, run time, queue time, movement, subcontracting, inspection, testing and rework allowances. These values can be assigned to routing operations, work centers or product families.

Processing time and elapsed time are different. A machine may require four hours of work but be scheduled three days later because the work center has a queue. A lead-time engine should therefore distinguish:

touch time: the time employees or equipment actively work on the product;
queue time: waiting before an operation begins;
transfer time: movement between operations or facilities;
calendar time: elapsed time after shifts, weekends and holidays are applied.

If CPQ cannot access finite-capacity scheduling, it may calculate a standard or quoted lead time rather than a capacity-constrained promise. That limitation should be visible to users.

6. Apply dependencies and calendars

Activities can run sequentially or in parallel. Purchased components may be ordered while engineering completes, but final assembly cannot begin until all required parts are available. A proper calculation represents these dependencies rather than adding every duration together.

Calendars may differ by plant, work center, supplier and customer location. The model should account for working days, shutdowns, time zones, regional holidays and planned maintenance. A five-day supplier lead time may mean five supplier working days, not five calendar days.

7. Add inspection, approval and logistics time

Quality inspection, factory acceptance testing, customer approval, packaging and documentation can affect the final date. These activities are particularly important for electrical equipment, medical equipment, pressure equipment and engineered machinery.

The delivery date should be distinguished from the manufacturing completion date. Transit, export controls, customs, installation and site commissioning may be outside the CPQ calculation or may be added as separate logistics stages.

Example: configuring an industrial pump

Consider a centrifugal pump configured for a chemical-processing application. The user selects flow, head, fluid, temperature, casing material, seal type, motor, baseplate and control panel.

The configuration rules validate that the selected seal and casing are suitable for the fluid. Engineering calculations select the impeller diameter and motor rating. The configured BOM includes the casing, impeller, shaft, seal, motor, coupling, baseplate, fasteners and control components.

Activity	Illustrative dependency
Engineering selection	Required before the final BOM and drawing release
Special alloy casing	Supplier casting and inspection create a long-lead dependency
Custom motor	Purchased in parallel with casing procurement
Machining	Starts after casting receipt and inspection
Assembly	Starts after machined parts and motor availability
Performance test	Follows assembly and precedes shipment

The final estimate is driven by the longest dependent path, not by the sum of every item. If the casing takes eight weeks and the motor takes six weeks, the motor does not necessarily add six weeks to the casing if procurement occurs in parallel. However, a late engineering approval or failed inspection can move the promised date.

The quote should state assumptions such as supplier availability, approval timing, delivery location and whether the date is estimated or committed.

Lead time across CTO, MTO, ATO and ETO

Workflow	Lead-time characteristic
Configure-to-order (CTO)	Uses predefined options and approved product structures; lead time is often driven by inventory, assembly and scheduling
Make-to-order (MTO)	Production begins after the order; material procurement and manufacturing are important dependencies
Assemble-to-order (ATO)	Subassemblies are stocked and final configuration or assembly occurs after order entry
Engineer-to-order (ETO)	Customer requirements trigger new engineering, design approval and often new manufacturing data

These models should not be collapsed into one generic lead-time rule. An ETO product may need a quotation-stage engineering estimate, followed by a revised date after design release. More detail is available in the manufacturing workflow guide.

Integration architecture

A practical architecture assigns ownership to the appropriate system:

CPQ: captures requirements, validates configuration, calculates commercial values and presents the quote;
CRM: stores account, opportunity and customer interaction data;
ERP: manages items, inventory, purchasing, routings, orders and often standard lead times;
PLM: manages product structures, revisions, engineering change and release status;
PDM: manages engineering files and CAD document relationships;
CAD: creates or updates geometry, drawings and models when automation is available;
MES: records and sometimes schedules shop-floor execution;
PIM: manages product information for channels and catalogs, but usually does not replace ERP or PLM scheduling data.

Data flows may include configuration selections from CPQ to ERP and PLM, availability from ERP to CPQ, engineering outputs from CAD or PDM, and order status from ERP or MES back to the customer-facing process. Integration patterns and API design should be addressed during architecture planning; see CPQ integrations.

Lead-time limitations and risks

Stale data: inventory and supplier dates may change after the quote is created.
Insufficient capacity data: a standard duration is not the same as a scheduled completion date.
Unmodeled engineering work: custom calculations, reviews and drawing changes are often omitted.
Ambiguous BOM ownership: an EBOM may not contain the manufacturing operations required for scheduling.
Hidden dependencies: tooling, certifications, subcontracting and customer approvals can become critical-path activities.
False precision: a date down to the day may be misleading when supplier or capacity uncertainty is high.
Overly rigid rules: lead-time logic becomes difficult to maintain if every exception is hard-coded in the configurator.

Where uncertainty is material, the quote can provide a range, a target date with assumptions, or separate dates for engineering release, production completion and delivery. Any promise should be governed by the company’s commercial and production policies.

Implementation recommendations

Define the business meaning of lead time. Decide whether the output means engineering completion, ship date, customer delivery date or a committed promise.
Map the critical path. Identify procurement, engineering, production, inspection and logistics activities that can delay fulfillment.
Start with high-value product families. Model the configurations where lead-time accuracy has the greatest commercial or operational impact.
Assign data ownership. Document whether CPQ, ERP, PLM, PDM, MES or a supplier process owns each value.
Separate rules from transactional data. Product constraints belong in the product model; current inventory and purchase-order status should normally come from operational systems.
Test realistic scenarios. Include standard, long-lead, unavailable, substituted, engineered and invalid configurations.
Version the model. A quoted lead time should be traceable to the product rules, BOM revision, supplier assumptions and calendars used at calculation time.
Monitor estimate versus actual. Compare quoted, planned and completed dates to identify unreliable routing, supplier or engineering assumptions.

Implementation should be treated as a product-data and process-governance project, not only as a user-interface project. The CPQ implementation guide covers requirements, testing, governance and maintenance in more detail.

How lead time connects to costing, pricing, BOMs and quote documents

Lead time is not the same as price, but the two often share data. Expedited procurement, overtime, premium freight or additional engineering can change cost and therefore price. Conversely, a low-cost option may have a longer supplier lead time.

The configured BOM supports material costing and procurement analysis. Routing data supports labor and machine costing. Engineering tasks can be priced as an engineering charge or absorbed into product cost. Approval rules may prevent a salesperson from promising an accelerated date without margin review or operational approval.

A complete quote may therefore contain the configuration summary, BOM or line-item description, price, validity period, estimated lead time, delivery assumptions, exclusions, approval status and next steps. The quote should make clear which values are calculated and which are manually entered.

Semantic map

The following relationships summarize how lead-time calculation fits into manufacturing CPQ:

Configuration selections determine product requirements.
Product requirements determine the configured BOM.
The configured BOM determines procurement and production dependencies.
Inventory and supplier data determine material availability.
Routing and capacity data determine manufacturing duration.
Engineering rules determine design and approval work.
The critical path determines the earliest feasible completion date.
ERP, PLM, CAD and MES integrations provide operational and engineering data.
Lead-time results support pricing, approvals and quote documents.
Actual completion data improves future lead-time estimates.

FAQ

What is lead-time calculation in CPQ?

It is the calculation of how long a configured product will take to engineer, source, manufacture, test and deliver.

Why is a fixed product lead time often inaccurate?

Options such as materials, motors, dimensions, custom controls and engineering requirements can change the BOM, suppliers, operations and critical path.

Does every CPQ system calculate manufacturing lead time?

No. Some CPQ systems calculate only price and quote content. Buyers should verify support for BOMs, routings, inventory, capacity and enterprise integrations.

What is the difference between quoted and committed lead time?

A quoted lead time is an estimate based on stated assumptions. A committed lead time is an approved promise supported by operational planning and commercial policy.

Can CPQ calculate lead time without ERP integration?

It can use static product rules and standard durations, but accuracy is limited without current inventory, purchasing and order data.

How does a BOM affect lead time?

The BOM identifies the components and materials that must be available, purchased, fabricated, assembled or inspected.

Is an EBOM the same as an MBOM?

No. An EBOM describes the engineering product, while an MBOM describes the manufacturing structure and may include plant-specific operations.

How do configuration rules affect delivery dates?

Rules validate options and can add conditional procurement, engineering, inspection or production activities to the calculation.

What is the critical path in a configured product?

It is the dependent sequence of activities that determines the earliest possible completion date.

Can lead time and price be calculated together?

Yes. The same configuration can drive BOM costing, expedited charges, engineering fees, production assumptions and the quoted delivery estimate.

How is ETO lead time different from CTO lead time?

ETO includes customer-specific engineering and design release, while CTO normally uses predefined and approved product options.

Should lead time be shown as a date or a range?

A date is appropriate when data and capacity are reliable. A range or date with assumptions is safer when supplier, engineering or scheduling uncertainty is significant.

How are supplier lead times used?

Supplier lead times are applied to unavailable purchased parts, usually with order, receiving, inspection and calendar rules.

Does CAD automation reduce lead time?

It can reduce manual design and drawing effort when the configuration is within the supported parametric model, but review and release activities may still be required.

How should customer approvals be included?

Approval activities should be modeled as dependencies when production or procurement cannot proceed until the customer accepts drawings, specifications or test plans.

What happens when inventory data is stale?

The calculated date may be unreliable. The system should show the data timestamp or use a cautious estimate and require confirmation before commitment.

Can CPQ calculate finite production capacity?

Only when it has suitable scheduling or capacity data, directly or through integration. Otherwise it normally uses standard durations rather than a fully scheduled promise.

Which teams own lead-time rules?

Ownership is usually shared by product management, engineering, supply chain, manufacturing planning, sales operations and IT, with clear governance for changes.

September 21, 2026

How Pricing Engines Work in Manufacturing CPQ

A pricing engine in manufacturing CPQ is the software component that calculates the commercial price of a valid configured product. It uses the selected options, dimensions, materials, quantities, manufacturing data, cost records, customer terms, currencies, discounts and margin policies to produce a price that can be quoted and approved.

In a simple sales CPQ system, pricing may mean adding products, quantities and discounts to a price list. Manufacturing CPQ usually requires more. A configured pump, industrial enclosure, conveyor, machine or specialty vehicle may have dimensions, performance requirements, materials, motors, controls and safety options that change the bill of materials (BOM), manufacturing effort and final price. The pricing engine must therefore work with the product configuration and, in some implementations, with engineering calculations, cost estimates and generated manufacturing data.

The pricing engine is not the same as the product configuration engine. The configuration engine determines whether a product combination is valid. The pricing engine determines what that valid combination costs and what the customer should be charged. They normally operate as connected services in a broader configure, price, quote (CPQ) workflow.

For a broader explanation of BOM generation, pricing and quote automation, see the related CPQ Guide resource.

What a manufacturing CPQ pricing engine does

A manufacturing pricing engine transforms product and commercial data into a price calculation. A typical calculation may include:

base product or assembly price;
configured options and accessories;
quantity-based pricing;
dimensions, capacity or performance calculations;
materials and purchased components;
labor, machine time and subcontracting;
setup, tooling, engineering and testing charges;
freight, packaging and installation;
customer, channel or project-specific discounts;
currency conversion, taxes and payment terms;
target margin and approval thresholds.

The engine may calculate a selling price directly from a price list, or it may first calculate an estimated or standard cost and then apply a markup or margin rule. More advanced manufacturing implementations calculate prices from a generated or derived BOM, routing assumptions, engineering formulas or external costing services.

Where pricing fits in the manufacturing CPQ workflow

Pricing is one stage in a chain of dependent decisions. A typical workflow is:

Product selection: A salesperson, dealer, engineer or customer selects a product family.
Configuration: The user selects features such as capacity, dimensions, motor type, material and controls.
Validation: Rules and constraints identify incompatible or incomplete selections.
Engineering calculation: The system may calculate performance, sizing, power, loads or other technical values.
BOM derivation: The configured product is mapped to components, assemblies and quantities.
Cost calculation: Material, labor, purchased parts, overhead and special work are estimated or retrieved.
Price calculation: Price lists, markups, discounts, surcharges, freight and commercial policies are applied.
Approval: Exceptions such as low margin, unusual terms or non-standard engineering are routed for review.
Quote generation: The system produces a customer-facing quote and, where supported, internal BOM, CAD or order data.

Not every CPQ platform performs every step. Some systems calculate price and produce a proposal while relying on an enterprise resource planning (ERP) system for costs and a product lifecycle management (PLM) or product data management (PDM) system for engineering data. Buyers should verify which system owns each calculation and how results are exchanged.

Core data used by a pricing engine

Product and option data

The engine needs a product model that identifies base products, options, accessories, variants and dependencies. For example, a pump model may have selectable flow range, head, impeller material, seal type, motor rating, voltage and control package. Each selection can add a price, replace a standard component or trigger a calculation.

Product configuration is governed by rules. A stainless-steel wetted path may be required for a chemical application. A particular motor may be unavailable at a selected voltage. A larger impeller may require a larger housing. These rules belong primarily to the configuration model, but their outcomes provide inputs to pricing.

See the guide to product configuration, options and configuration rules for a deeper treatment of product models and constraints.

Price lists and price components

A price list may contain prices for finished products, options, spare parts, services or standard assemblies. The data can be organized by currency, market, customer class, sales channel, effective date or legal entity.

Price components may be additive, substitutive or conditional:

An additive component adds a charge for an accessory.
A substitutive component replaces the standard price when a premium material is selected.
A conditional component applies only when a feature, market, quantity or delivery condition is present.

For example, a standard carbon-steel enclosure might have a base price, while stainless steel replaces the material cost and adds fabrication labor. A washdown finish may add a separate coating charge. The engine must avoid charging twice when one option replaces another.

Cost data

Cost-based pricing requires reliable cost data. Common sources include ERP item costs, supplier prices, standard costs, manufacturing routings, labor rates, machine rates, subcontractor estimates and engineering-service rates.

Cost can be stored at different levels of accuracy. A standard cost may be adequate for an early budgetary quote. A detailed estimate may be necessary for an engineered-to-order (ETO) machine involving custom design, purchased components and fabrication. The system should identify whether a result is an estimate, a standard cost or an approved project cost.

Customer and commercial data

Customer records may determine contract prices, discount groups, currencies, territories, payment terms, freight rules and tax treatment. A customer relationship management (CRM) system may provide the account and opportunity context, while the CPQ system applies the pricing logic.

Customer-specific pricing should be governed carefully. A broad discount stored against an account can unintentionally override a product-specific floor price or create a margin problem. Effective dates and versioning are important when contracts, supplier costs or exchange rates change.

Common pricing methods in manufacturing CPQ

Method	How it works	Typical use	Main limitation
Price list	Retrieves a fixed price for a product, option or assembly.	Standard products and repeatable options.	Limited flexibility for engineered variation.
Option-based pricing	Adds or replaces prices based on selected features.	Configured equipment with known option premiums.	Can become difficult to maintain with many interactions.
Formula pricing	Uses dimensions, capacity, quantity or technical values in a formula.	Cut-to-size products, tanks, conveyors and fabricated assemblies.	Requires controlled formulas, units and validation.
Cost-plus pricing	Calculates cost and adds a markup or target margin.	Custom machinery and ETO work.	Depends on accurate and timely cost data.
Matrix pricing	Uses several factors such as product, region, quantity and customer class.	Dealer and industrial distribution channels.	Large matrices can be hard to govern.
Project or negotiated pricing	Starts with calculated values and permits controlled commercial adjustments.	Large capital equipment and strategic projects.	Requires approvals, auditability and version control.

How rules and formulas affect price

Pricing rules express commercial consequences of configuration decisions. A rule might state that a high-temperature seal adds a defined charge, that a larger frame requires a larger motor, or that a custom paint system adds material and labor costs.

Rules can be simple or conditional. A simple rule adds a price for a selected option. A conditional rule may evaluate several values:

if material = stainless steel and pressure_class = high:

The actual calculation might then select a different component cost, apply a fabrication multiplier and require engineering approval. In production systems, such logic should be represented in a maintainable rule model rather than hidden in ad hoc spreadsheets or code whenever possible.

Formula pricing is common when dimensions or performance influence cost. A fabricated duct, tank or conveyor may use length, width, gauge, material density and labor factors. A pump package may use motor power, enclosure class, controls and accessories. Unit consistency is essential: millimeters and inches, kilograms and pounds, or kilowatts and horsepower must not be mixed without explicit conversion.

Costing, margin and selling price

Manufacturing CPQ should distinguish at least three concepts:

Cost: What the manufacturer expects to spend on materials, labor, overhead, purchased items or external services.
Price: What the manufacturer charges before or after discounts and commercial adjustments.
Margin: The difference between selling price and relevant cost, expressed as an amount or percentage.

A markup and a margin are not interchangeable. If cost is 1,000 and the business applies a 20 percent markup, the price is 1,200. If the business requires a 20 percent gross margin, the price is 1,250 because the cost represents 80 percent of the selling price. The pricing engine must use the organization’s defined convention consistently.

A practical pricing calculation may be:

derive configured components;
retrieve or estimate material and purchased-part costs;
add labor, machine, engineering and subcontracting costs;
apply overhead or cost factors where appropriate;
apply target margin or markup;
add logistics, installation or service charges;
apply approved discounts and customer terms;
check minimum price and margin thresholds.

Some businesses price from a published list and use cost only for margin analysis. Others use cost-plus rules for every engineered quotation. Both approaches can be valid if the ownership, timing and accuracy of the data are understood.

Relationship between pricing and BOM generation

A bill of materials (BOM) lists the components and quantities required for a product or assembly. A configurable BOM represents the component structure selected or derived for a particular configuration. Pricing may use this structure, but a quote BOM and a manufacturing BOM are not necessarily identical.

An engineering BOM (EBOM) describes the product from an engineering perspective. A manufacturing BOM (MBOM) organizes the product for production, including manufacturing assemblies, operations or plant-specific structures. A CPQ system may generate a sales BOM, an EBOM-like structure, an MBOM, or only a commercial summary. The implementation must define which output is required.

For example, selecting a conveyor length may add frame sections, guards, belts, supports and drive components. The pricing engine may price each component and labor operation, while the ERP later creates the production order. In another architecture, CPQ may send only a configured item and option codes to ERP, where the BOM is resolved using ERP rules.

Pricing in configure-to-order and engineer-to-order

Configure-to-order (CTO) products are assembled from predefined options and standard components. Pricing can often be calculated from maintained price components and a configurable BOM. Examples include standard pumps, switchgear packages and material-handling modules.

Engineer-to-order (ETO) products require new or substantially modified engineering for a specific order. Pricing may need engineering hours, design risk, prototype work, custom tooling, non-standard materials and project contingencies. A CPQ system may calculate an initial estimate and then send the opportunity for engineering review rather than presenting the result as a fixed production price.

Make-to-order (MTO) means production begins in response to an order, while assemble-to-order (ATO) uses stocked components assembled after the order. CTO, MTO and ATO can overlap operationally, but they describe different aspects of product and fulfillment behavior. The pricing design should reflect the actual workflow instead of assuming that every configurable product is CTO.

The relationship between commercial configuration and engineering handoff is described in the guide to manufacturing workflows such as CTO and ETO.

Approvals and pricing governance

Manufacturing quotes often require approvals when the result falls outside normal policy. Approval conditions may include:

margin below a product-family threshold;
discount above the salesperson’s authority;
price below a minimum floor;
non-standard payment or delivery terms;
custom engineering or tooling;
unusual material, supplier or warranty requirements;
an ETO configuration with unresolved cost uncertainty.

Approval workflows should preserve the configuration, calculation inputs, price version, approver, decision and timestamp. If a salesperson changes a motor, dimension or discount after approval, the system should recalculate and determine whether approval is required again.

Integration architecture

Pricing engines rarely operate in isolation. Typical system responsibilities are:

System	Possible responsibility
CRM	Account, opportunity, contact and sales-process context.
ERP	Items, inventory, standard costs, purchasing, orders, financial data and sometimes BOM resolution.
PLM	Product definitions, revisions, engineering change control and lifecycle status.
PDM	Engineering files, CAD documents, metadata and revision control.
CAD	Parametric models, drawings and design outputs where automation is supported.
PIM	Commercial product information, descriptions, attributes and channel content.
MES	Manufacturing execution, production status and shop-floor data.
CPQ	Configuration interaction, pricing logic, quote composition and commercial workflow.

Integration can be synchronous, such as requesting a current cost during configuration, or asynchronous, such as publishing an approved quote and BOM to ERP. APIs, integration middleware and scheduled data synchronization may all be used. The important question is not whether a system has an integration label, but which system is authoritative for each data element and what happens when systems disagree.

See CPQ integration with ERP, CRM, PLM, PDM, CAD and other systems for architecture and ownership considerations.

Pricing and CAD or engineering automation

Some manufacturing CPQ implementations use engineering calculations or computer-aided design (CAD) automation. A user might enter tank dimensions, airflow, load capacity or vehicle wheelbase. The system can use those values to select components, calculate technical requirements and estimate price.

CAD automation may generate a product-specific model or drawing after configuration. That output can provide dimensions, material quantities or manufacturing information used by pricing, but the relationship is implementation-specific. A CPQ platform may support CAD integration, call an external engineering service or have no CAD capability at all.

Pricing should not depend on an unverified drawing result. Where engineering automation is used, the implementation should define calculation tolerances, failure handling, revision control and the point at which an engineer must review the output. More information is available in CAD and engineering automation for CPQ.

Benefits of a manufacturing pricing engine

Faster quotation: Sales and application engineers can calculate repeatable configurations without rebuilding spreadsheets.
Better price consistency: Rules reduce variation between salespeople, plants and dealers.
Improved margin control: Cost and price can be evaluated before a quote is released.
Traceable assumptions: The quote can retain the selected options, price version and approval history.
Fewer configuration errors: Invalid options are blocked before they produce a misleading price.
Stronger handoff: The same configuration can support the quote, BOM, engineering review and order entry.
Better channel support: Dealers can receive controlled prices without maintaining private spreadsheets.

Limitations and common failure modes

A pricing engine cannot compensate for poor product data. Common problems include outdated costs, duplicate price rules, unclear ownership, missing option dependencies and formulas that are understandable only to their original author.

Pricing can also become unreliable when the system treats every product as a fixed catalog item even though dimensions, material grades or engineering effort vary significantly. Conversely, excessive customization can create an unmaintainable model with thousands of exceptions.

Other risks include:

using standard cost as if it were a real-time project estimate;
mixing markup and margin definitions;
applying discounts before or after surcharges without documenting the sequence;
failing to version price lists and rules;
allowing manual overrides without reason codes or approval;
sending a commercial BOM to ERP when ERP requires a different manufacturing structure;
not recalculating after a configuration change;
ignoring currency, tax, freight and delivery-date effects;
embedding critical pricing logic in spreadsheets outside governance.

Implementation considerations

Define calculation ownership

Document whether CPQ, ERP, PLM, a costing application or an external service owns each value. For example, PLM may own the released option structure, ERP may own standard cost, and CPQ may own customer discount rules.

Model the product before the price

Start with valid product configurations and their dependencies. Pricing rules built on an unstable product model will need constant correction. Separate technical validity rules from commercial rules so that engineers can maintain constraints without changing sales policy unnecessarily.

Establish a pricing hierarchy

Define the order in which base prices, option adjustments, formulas, surcharges, discounts, taxes and freight are applied. Record whether a rule replaces, adds to or discounts another value.

Test representative scenarios

Test standard, maximum, minimum, boundary and invalid configurations. Include different currencies, quantities, customer classes, plants, effective dates, discounts and approval conditions. Compare calculated results with independently reviewed examples.

Govern changes and releases

Assign owners for product rules, price lists, cost data, formulas and approval policies. Use version control, effective dates, test environments and release procedures. A price change should be traceable to its source and should not silently alter previously issued quotes unless that behavior is intentional.

The broader CPQ implementation guide covers data migration, testing, governance, deployment and maintenance.

How to evaluate a manufacturing CPQ pricing engine

When comparing CPQ software, ask vendors and implementation teams:

Can the engine price option-based, formula-based and cost-plus products?
Can it use dimensions, quantities, engineering calculations and derived components?
How are price rules versioned, tested and assigned to owners?
Can it distinguish standard, estimated and project-specific costs?
How are currencies, taxes, freight, installation and payment terms handled?
Can it calculate margin and enforce price floors?
Can discounts and overrides require approvals?
Does it generate a configurable BOM, and what type of BOM?
Which system is authoritative for item and cost data?
How are ERP, CRM, PLM, PDM, CAD and external costing services integrated?
Can a revised configuration trigger a complete recalculation?
Are formulas, rules and price components visible to administrators?
Can the system support CTO, MTO, ATO and ETO scenarios?
How are failed calculations, missing costs and engineering exceptions presented?

Do not evaluate pricing by feature count alone. A platform with a simple price-list engine may be suitable for standard configurable products, while an ETO manufacturer may require governed formulas, cost rollups, engineering review and integration with ERP or PLM.

Semantic map

The following relationships summarize how pricing connects configuration, engineering, BOMs, enterprise systems and quoting in manufacturing CPQ.

CPQ configures complex manufactured products.
Configuration rules prevent invalid combinations.
Valid configurations provide inputs to pricing.
Pricing engines calculate commercial values.
Cost data supports margin analysis.
Configured products generate configurable BOMs.
Engineering calculations influence component selection and price.
CAD automation can generate product-specific drawings.
ERP provides or receives item, cost and order data.
PLM governs product definitions and revisions.
Approvals control discounts and margin exceptions.
Quote documents communicate configured products and prices.

Frequently asked questions

1. What is a pricing engine in manufacturing CPQ?

It is the calculation component that determines the cost or selling price of a valid configured product using options, quantities, formulas, costs, discounts, margins and commercial terms.

2. Is a CPQ pricing engine the same as a product configuration engine?

No. The configuration engine validates the technical product combination. The pricing engine calculates its cost and price. They exchange data but have different responsibilities.

3. Can a pricing engine calculate the price of an engineered machine?

Yes, if it has the required product rules, cost data, engineering formulas and approval workflow. For complex ETO work, the result may be an estimate that requires engineering review rather than a final production price.

4. How does a CPQ system price configurable options?

It can add an option charge, replace a standard component price, use a formula, or retrieve a price based on product, customer, quantity, region or effective date.

5. What is the difference between cost and price in CPQ?

Cost represents expected expenditure to manufacture or deliver the product. Price is the amount charged to the customer. The pricing engine may use cost to calculate a target margin or markup.

6. Can manufacturing CPQ calculate margin?

Many systems can calculate margin when cost and price are available, but the exact capability and cost detail vary. The implementation must define which costs are included.

7. Does pricing depend on the BOM?

It can. A CPQ system may price the components and quantities in a configurable BOM, or it may use a high-level price model while ERP resolves the manufacturing BOM later.

8. What is the difference between an EBOM and an MBOM for pricing?

An engineering BOM describes the product from an engineering perspective. A manufacturing BOM organizes it for production. Pricing may use either, a sales BOM, or a separate commercial structure depending on the architecture.

9. How does ERP interact with a CPQ pricing engine?

ERP may provide item data, standard costs, currencies or customer terms. CPQ may send the configured product, price, BOM or order information back to ERP. The exact ownership must be defined.

10. Can a CPQ pricing engine use real-time supplier costs?

It can if the architecture integrates a current supplier or ERP source. Without such an integration, the engine may rely on maintained standard, average or manually updated costs.

11. How are discounts controlled in manufacturing CPQ?

Discount rules can be based on customer, channel, quantity, product family or contract. Approval thresholds can require review when discounts reduce price or margin below policy.

12. What happens when a salesperson changes a configured option?

A well-designed system revalidates the configuration and recalculates dependent components, costs, prices, margins and approvals. Previously approved results may need approval again.

13. Can pricing engines support multiple currencies?

Many can, but currency conversion, rounding, price-list ownership, tax treatment and exchange-rate timing must be explicitly configured and tested.

14. How does formula pricing work for manufactured products?

Formula pricing uses values such as length, area, weight, capacity, power or quantity to calculate a component, labor amount or surcharge. Units and boundary conditions must be controlled.

15. Does every manufacturing CPQ platform include costing?

No. Some platforms provide price-list and discount logic but rely on ERP, estimating software or custom services for detailed costing. Buyers should verify documented capabilities.

16. Can CPQ price ETO products?

It can support initial estimates, engineering charges and controlled exceptions, but ETO pricing often requires human review because design effort, supplier costs and production requirements may be uncertain.

17. How does CAD automation affect pricing?

CAD or engineering automation can calculate dimensions, materials or derived components that influence price. However, not every CPQ platform supports CAD automation, and generated outputs may require engineering validation.

18. How should pricing rules be maintained?

Assign owners, use versioning and effective dates, separate technical rules from commercial rules, test representative configurations and document the calculation sequence.

19. What should manufacturers test before deploying a pricing engine?

Test standard and boundary configurations, invalid combinations, quantity breaks, discounts, currencies, taxes, freight, revisions, cost changes, approval thresholds and integrations with downstream systems.

20. What is the main risk of spreadsheet-based manufacturing pricing?

Spreadsheets can contain hidden formulas, inconsistent versions, manual overrides and outdated costs. They may be useful during analysis, but governed CPQ logic provides stronger repeatability and traceability for recurring configurations.

September 21, 2026

Dynamic Pricing for Configurable Industrial Products

Dynamic pricing for configurable industrial products is the automated calculation of a product price as configuration, cost, market, customer and commercial conditions change. In a manufacturing Configure, Price, Quote (CPQ) system, the price is not simply selected from a static product catalogue. It is derived from the configured product, its components, engineering requirements, production route, commercial terms and applicable pricing rules.

For example, a pump manufacturer may need to price a unit based on flow rate, pressure, motor power, metallurgy, seal type, hazardous-area certification, control panel options, delivery location, customer agreement and current material costs. A valid configuration should produce not only a sales price, but also an explainable cost calculation, a manufacturing-relevant bill of materials (BOM), appropriate engineering outputs and a quote that can pass through the required approvals.

This makes manufacturing dynamic pricing different from generic sales CPQ. Generic CPQ may apply discounts to predefined products. Manufacturing CPQ may calculate a product-specific price from rules, dimensions, materials, purchased components, labor, overhead, logistics and engineering effort.

For background, see the manufacturing guide to BOMs, pricing and quoting and the broader guide to manufacturing CPQ.

What is dynamic pricing in manufacturing CPQ?

Dynamic pricing is a pricing method in which the system recalculates the price of a configured industrial product from current inputs rather than relying on one fixed price for every variation.

The inputs may include:

selected options, features and dimensions;
configuration rules and engineering constraints;
the resulting configurable BOM, engineering BOM (EBOM) or manufacturing BOM (MBOM);
material, component, labor and subcontracting costs;
quantity, production location, currency and delivery terms;
customer, channel, territory and contractual price lists;
target margin, minimum margin and discount limits;
freight, duties, installation, commissioning and service requirements;
lead time, capacity or expedited production requirements;
approval policies for unusual risk or low-margin transactions.

A dynamic price may therefore be calculated as a cost-plus price, a price-list adjustment, a formula-based price, a target-margin price, a market or customer-specific price, or a combination of these methods. The calculation should be deterministic and auditable: the same configuration and pricing context should produce the same result unless a controlled data change has occurred.

How configuration drives the price

Dynamic pricing begins with a product model. The product model represents the configurable structure of a machine, assembly or system and defines the available options, attributes, dependencies and constraints. A rules engine validates choices and may calculate derived values such as motor size, shaft diameter, panel rating, cable length or required cooling capacity.

Configuration and pricing are related but different functions. Configuration answers, What can be built? Pricing answers, What should this configured product cost and what price should be offered? A configuration can be valid but commercially unpriced, and a price rule should not be used to hide an invalid engineering combination.

Consider a configurable industrial air-handling unit. The buyer selects airflow, external static pressure, casing material, filter class, fan type, motor efficiency, controls and weather protection. The configuration engine may determine the fan size and motor rating. The pricing engine can then use those results to select component costs, apply labor factors, add the controls package and calculate a selling price.

Rules that influence price

Rule type	Manufacturing example	Pricing effect
Selection rule	A stainless-steel wetted path requires compatible seals.	Adds the price of the seal and material upgrade.
Dependency rule	A variable-frequency drive requires a compatible control enclosure.	Adds required hardware and assembly labor.
Calculation rule	A larger tank diameter requires more shell material.	Calculates material quantity and cost.
Exclusion rule	A selected motor cannot be paired with the chosen voltage.	Prevents an invalid configuration rather than changing price.
Commercial rule	Approved distributors receive a channel discount.	Applies a customer or channel-specific adjustment.
Approval rule	Margin below the approved threshold requires review.	Routes the quote for approval and may restrict discounting.

Rules should be separated where practical. Engineering rules protect product validity, cost rules calculate economic inputs, pricing rules determine the offer, and approval rules control commercial risk. Combining all of them in scattered formulas makes the model difficult to test and maintain.

Dynamic pricing and the configurable BOM

A bill of materials is a structured list of components, quantities and relationships required for a product or assembly. An industrial CPQ system may generate a configurable BOM during configuration, but the exact capability depends on the platform and its integration architecture.

An EBOM describes the product from an engineering perspective. An MBOM describes how the product is manufactured, including production structures, operations or shop-floor requirements. A configurable BOM is a rules-driven structure that resolves into a product-specific BOM after the customer selects options and values. These structures may be related but are not interchangeable.

The BOM can provide pricing inputs such as:

part numbers and configured quantities;
material grades, dimensions and weights;
purchased component prices;
manufacturing or assembly labor;
outside processing and subcontracting;
packaging, testing and inspection requirements;
replacement or supersession logic;
cost roll-up by assembly, product family or operation.

For a configured conveyor, for example, a change in belt width may alter the belt length, frame material, drive motor, guarding, supports and shipping dimensions. A robust pricing flow should recalculate the affected cost components rather than apply an arbitrary surcharge to the original price.

In some businesses, CPQ maintains a commercial or sales BOM while the ERP or product lifecycle management (PLM) system owns the authoritative production structure. The integration must define which system owns each field and when the configured result is transferred. A price calculated from an obsolete or incomplete BOM can be commercially attractive but operationally unreliable.

Pricing architecture for configurable products

A practical dynamic pricing architecture usually contains several layers.

1. Product and configuration model

This layer defines products, options, attributes, dimensions, compatibility, dependencies and configuration states. It may include guided selling for helping a user choose a suitable product, rules-based configuration using explicit if-then logic, or constraint-based configuration that evaluates relationships among multiple variables. These approaches can coexist, but they solve different problems.

2. Cost model

The cost model identifies the economic inputs required to produce or deliver the configured product. It may retrieve standard costs from an Enterprise Resource Planning (ERP) system, use supplier prices, calculate material quantities, estimate labor, add overhead or call an engineering calculation service.

Cost data requires effective dates, currencies, units of measure and ownership. A cost for a motor in euros per unit cannot be safely combined with a copper price in dollars per kilogram without controlled conversion and unit logic.

3. Pricing engine

The pricing engine converts cost and commercial context into a list price, net price or price breakdown. Common methods include:

Cost-plus pricing: adds a markup or margin to calculated cost.
Formula pricing: uses dimensions, quantities, indices or engineering variables in a defined formula.
Price-list pricing: starts with published or customer-specific prices and applies configuration adjustments.
Target-margin pricing: calculates a selling price intended to achieve a defined margin.
Matrix pricing: uses combinations such as product family, size, region and customer segment.
Contract pricing: applies negotiated terms, minimum quantities or agreed escalation clauses.

4. Commercial policy and approvals

Pricing policy determines who can change a price, discount or margin and under what conditions. Approval thresholds may depend on margin, total contract value, non-standard terms, engineering risk, delivery commitment or deviation from a price list.

5. Quote document and downstream transaction

The final calculation should produce a quote with clear line items, options, quantities, terms, validity dates, taxes where applicable, delivery assumptions and exclusions. After acceptance, the configured data may be sent to ERP, PLM, manufacturing execution system (MES), customer relationship management (CRM) or other systems. The handoff should preserve the configuration identity and calculation version.

Example: dynamic pricing for a configurable pump skid

Suppose a manufacturer sells pump skids for chemical processing. The customer selects flow, pressure, pump arrangement, motor type, wetted materials, seal package, base frame, instrumentation, enclosure rating and documentation level.

The configuration rules validate that the selected pump can meet the duty point and that the motor is compatible with the electrical supply. An engineering calculation determines the required motor power and approximate pipe sizes. The configured BOM then includes pumps, motors, valves, pipework, fittings, instruments, frame steel, control hardware and documentation.

The cost calculation may include:

current pump and motor purchase costs;
stainless-steel weight derived from frame and pipe dimensions;
fabrication and welding hours;
electrical assembly labor;
testing and inspection;
third-party certification;
packaging and freight.

The price calculation can apply a target margin, a customer contract adjustment and a quantity discount. If the resulting margin is below policy because of a volatile material price or an unusually expensive certification requirement, the quote is routed for approval. The quote document can show the selected configuration and commercial price without exposing confidential internal cost data.

If the customer changes the material from painted carbon steel to 316 stainless steel, the system should re-evaluate compatibility, BOM quantities, cost, labor, lead-time assumptions and margin. Applying only a fixed material surcharge would be simpler but may be inaccurate for a product whose dimensions and fabrication process also change.

Dynamic pricing across CTO, ETO, MTO and ATO workflows

Manufacturers use different fulfillment models, and pricing logic must match the workflow.

Workflow	Meaning	Pricing implication
Configure-to-order (CTO)	A product is selected from predefined options and assembled or produced after order.	Pricing can often use structured option prices, standard costs and a controlled configurable BOM.
Engineer-to-order (ETO)	Engineering work is created or substantially changed for the order.	Pricing must estimate engineering hours, design risk, validation, tooling and non-recurring effort.
Make-to-order (MTO)	Production starts after an order rather than from finished-goods stock.	Pricing may use order-specific material, labor and capacity assumptions.
Assemble-to-order (ATO)	Standard modules are combined after the order.	Pricing often combines module prices with assembly, testing and logistics rules.

ETO is particularly challenging because the final design may not yet exist. A CPQ system may need estimating rules, engineering rate tables, minimum charges, risk allowances and approval steps. It should distinguish a calculated production price from a preliminary estimate whose uncertainty is higher.

Integration with ERP, PLM, CAD and CRM

Dynamic pricing depends on reliable enterprise data, but no single system should automatically be assumed to own every data object.

System	Typical relationship with CPQ pricing
ERP	May provide item masters, standard costs, inventory context, currencies, customers, orders and financial data.
PLM	May own product structures, revisions, approved options, engineering changes and lifecycle status.
Product data management (PDM)	May manage CAD files, engineering documents and design metadata.
Computer-aided design (CAD)	May provide geometry, dimensions, mass properties, drawings or design-specific outputs when integrated.
CRM	May provide account, opportunity, sales channel and customer context.
Product Information Management (PIM)	May provide commercial descriptions, media and catalogue attributes.
MES	May provide manufacturing execution information, actual production feedback or shop-floor status.

Integration design should address data ownership, synchronization frequency, effective dates, error handling, revision control, units of measure and traceability. More integrations do not automatically produce better pricing. An unstable cost feed or ambiguous part revision can reduce confidence in every quote.

See the guide to CPQ integrations for a broader discussion of ERP, CRM, PLM, PDM, CAD, PIM and MES relationships.

Benefits of dynamic pricing

More accurate configuration-specific prices: the price reflects selected materials, components and requirements.
Faster quoting: sales and application engineers can calculate standard configurations without rebuilding spreadsheets.
Better margin control: the system can expose margin, cost drivers and approval exceptions before submission.
Consistent commercial policy: regional, customer and channel rules are applied consistently.
Improved engineering handoff: the quote retains the configuration and assumptions used to calculate price.
Traceable changes: users can identify which rule, cost, revision or price list produced a result.
Better product data: repeated configuration and pricing activity can reveal common options, unprofitable variants and obsolete rules.

Limitations and risks

Dynamic pricing is not a substitute for accurate product and cost data. Typical risks include:

Incomplete cost data: missing labor, freight, tooling or engineering effort creates false margins.
Overly complex formulas: undocumented exceptions become difficult to test and explain.
Stale prices: supplier, material or currency changes may not reach CPQ at the required frequency.
Conflicting ownership: different systems may contain different versions of a component, BOM or revision.
ETO uncertainty: early estimates may appear more precise than the available engineering information supports.
Margin distortion: allocating overhead or shared costs inconsistently can make product comparisons misleading.
Commercial resistance: sales teams may bypass the system if pricing rules do not reflect legitimate market or customer exceptions.
Performance problems: large product models and repeated engineering calculations may slow configuration.
Governance burden: every new option, supplier change or pricing policy may require controlled model maintenance.

Pricing transparency also requires care. A customer-facing configurator may show option prices and totals, while internal cost, margin and approval information should remain role-restricted.

Implementation approach

1. Define the pricing scope

Start with a product family and a measurable use case, such as standard pump packages, modular conveyors or electrical enclosures. Define whether the first release will calculate list price, net price, cost, margin, engineering estimates or all of these.

2. Map the current calculation

Document spreadsheets, ERP lookups, engineering formulas, manual surcharges, discount practices and approval decisions. The objective is to expose actual pricing logic, including exceptions that are not written in formal procedures.

3. Establish data ownership

Assign owners for product options, configuration rules, item numbers, BOMs, costs, price lists, discount policies, currencies and quote templates. Record effective dates and revision rules.

4. Separate engineering and commercial rules

Test whether each rule validates a configuration, calculates a cost, sets a price or controls approval. Separate responsibilities make troubleshooting and change management easier.

5. Build representative test cases

Test standard, maximum, minimum, boundary and invalid configurations. Include different currencies, quantities, customer types, plants, delivery terms, revisions and material prices. Reconcile results against approved manual calculations.

6. Connect downstream systems carefully

Begin with the minimum reliable integration. Confirm whether CPQ sends a sales configuration, EBOM, MBOM, order line, engineering request or merely a quote reference. Validate error handling when an item, cost or revision is missing.

7. Govern releases and monitor results

Use version control, approval workflows, regression testing and a change log for pricing rules. Monitor quote cycle time, pricing exceptions, approval frequency, margin variance, manual overrides, order rework and configuration errors.

The CPQ implementation guide covers requirements, migration, testing, governance, deployment and maintenance in more detail.

What to evaluate in a CPQ configurator

When evaluating a CPQ configurator for dynamic industrial pricing, ask vendors to demonstrate a real product model rather than a generic discount scenario. The demonstration should include dimensions, incompatible options, calculated components, a configurable BOM, cost roll-up, customer pricing, approval thresholds and quote revision history.

Can the platform represent the product’s actual dependencies and constraints?
Can users distinguish invalid configurations from valid but non-standard ones?
Can the system calculate quantities and derived attributes?
Can costs be versioned by date, plant, currency and supplier?
Can pricing rules be maintained by authorized business users?
Can the system show price and margin explanations?
Can it create or consume a configurable BOM?
Can it estimate engineering effort for ETO work?
Can it preserve configuration identity through ERP, PLM, CAD or CRM integration?
Can approvals be triggered by margin, discount, value, risk or non-standard requirements?
Can the organization test model changes before publishing them?

Do not assume that a product marketed as a CPQ configurator includes BOM generation, CAD automation, engineering calculations, 3D visualization or PLM integration. Verify each capability, its data requirements and its production limitations.

Related concepts

Dynamic pricing is closely connected to product configuration and configuration rules, CAD and engineering automation, and configure-to-order and engineer-to-order workflows. These subjects should be designed together because a commercial price that cannot be traced to a valid product definition will not reliably support order entry or production.

Semantic map

The article’s main relationships are:

Product configuration determines the selected industrial product.
Configuration rules prevent incompatible options and calculate derived attributes.
A configured product resolves into a configurable BOM or downstream product structure.
BOM quantities and component data provide inputs to cost calculation.
Cost models support margin and price calculation.
Pricing policies determine list price, net price, discounts and approvals.
Approvals control exceptions and commercial risk.
Quote documents communicate the configuration, price and assumptions.
ERP, PLM, CAD, CRM and MES exchange different types of product and commercial data.
CTO, ETO, MTO and ATO workflows require different levels of pricing certainty and engineering effort.

Frequently asked questions

What is dynamic pricing for configurable industrial products?

It is the automated calculation of a price from a specific product configuration, cost data, commercial rules and customer or order context instead of one fixed price for every variant.

How is dynamic pricing different from discounting?

Dynamic pricing determines a configuration-specific price from product and commercial inputs. Discounting is an adjustment applied to a price, often based on customer, quantity, channel or negotiation.

Does dynamic pricing require a CPQ system?

Not always. It can be implemented with custom software or integrated ERP tools, but CPQ is designed to connect product configuration, pricing, quoting and often BOM or engineering processes.

Can a CPQ system calculate manufacturing cost?

Some systems can calculate or roll up cost, while others retrieve cost from ERP or another service. The capability, cost detail and integration method must be verified for each platform.

Can dynamic pricing use a bill of materials?

Yes. A configured BOM can provide component quantities, materials and assemblies for cost and price calculation, although not every CPQ platform generates or owns a production BOM.

What is the difference between a configurable BOM and an EBOM?

A configurable BOM resolves from selectable rules and options. An EBOM represents an engineering product structure. A CPQ system may use one, both or an integration with PLM depending on the workflow.

Should CPQ own the MBOM?

Usually this depends on enterprise architecture. CPQ may generate commercial configuration data, while ERP, PLM or manufacturing systems own the authoritative MBOM. Ownership and synchronization must be explicitly defined.

How does material cost affect dynamic pricing?

Material cost can be retrieved by item, grade, quantity, weight, length or other calculated attributes. Effective dates, units, currency and supplier or plant context are needed for reliable results.

Can dynamic pricing support engineer-to-order products?

Yes, if the model can estimate engineering, tooling, testing, risk and non-recurring effort. ETO prices should communicate assumptions and uncertainty rather than imply that an unfinished design is fully known.

How does configuration affect margin?

Options can change material, purchased components, labor, engineering effort, freight and risk. A margin calculation should therefore use the resolved configuration and relevant cost assumptions.

What is target-margin pricing?

Target-margin pricing calculates a selling price intended to achieve a defined margin based on the estimated cost of the configured product.

Can dynamic pricing support customer-specific contracts?

Yes, if the pricing model supports customer or contract price lists, validity dates, currencies, quantities, exclusions and approval rules.

How are pricing exceptions approved?

Approval rules can route quotes based on margin, discount, total value, non-standard configuration, delivery commitment, engineering risk or contract terms.

How often should industrial pricing data be updated?

The frequency depends on the volatility and business impact of the data. Supplier components, metals, currencies and freight may require more frequent updates than stable labor standards or published option prices.

Can a customer see the cost calculation?

Usually the customer sees the configured items, prices and commercial assumptions rather than internal cost or margin. Role-based access should separate customer-facing and internal calculations.

Does dynamic pricing require CAD automation?

No. CAD automation is optional and separate from pricing, although CAD-derived dimensions, mass or design outputs can provide useful cost and engineering inputs for some products.

What should be tested before launching dynamic pricing?

Test valid and invalid configurations, boundary values, revisions, costs, currencies, quantities, customer terms, discounts, approvals, BOM results, integrations and quote documents.

What is the main implementation risk?

The main risk is automating incomplete or contradictory product and cost data. A sophisticated pricing engine cannot compensate for unclear product ownership, unreliable costs or undocumented exceptions.

September 20, 2026