CPQ software means Configure, Price, Quote software. In manufacturing, it is used to select and validate product options, apply technical and commercial rules, calculate costs and prices, generate customer quotes, and—when supported—produce manufacturing data such as bills of material, drawings or configured product records.
Manufacturing CPQ is more than a tool for adding discounts to a sales proposal. It can act as a controlled translation layer between a customer requirement and the engineering, commercial and production systems needed to fulfill it. For example, a CPQ application might help configure an industrial pump by checking flow, pressure, fluid, materials, motor size, seal type and certification requirements before calculating the price and creating a quote.
The exact scope varies considerably between products. Some CPQ platforms focus mainly on guided selling, configuration and quoting. Others support engineering calculations, configurable bills of material, computer-aided design (CAD) automation, 2D or 3D visualization, and integration with enterprise resource planning (ERP), product lifecycle management (PLM) or manufacturing execution systems (MES). Buyers should verify each capability rather than assume that every CPQ product provides the full manufacturing stack.
What does CPQ stand for?
CPQ stands for Configure, Price, Quote:
- Configure: select valid product options and define technical requirements.
- Price: calculate costs, list prices, customer-specific prices, discounts, freight, taxes or other commercial values.
- Quote: present the configured product, price, assumptions, delivery information and commercial terms in a formal quotation.
In a simple sales environment, these steps may be limited to selecting options and applying a price list. In a manufacturing environment, configuration can include dimensional calculations, capacity checks, component selection, material compatibility, electrical load validation, safety requirements and the creation of downstream product data.
A useful manufacturing definition is:
Manufacturing CPQ is software that controls the configuration and commercial definition of complex products, validates technical requirements, calculates a price and produces a quote or production-ready handoff according to the capabilities of the implementation.
For a broader overview, see the manufacturing CPQ guide.
How manufacturing CPQ works
A CPQ implementation normally combines a product model, rules, calculations, pricing data, document templates and integrations. The user may be a salesperson, sales engineer, distributor, dealer, customer or internal application engineer. The system guides that user through a controlled configuration process.
1. The user defines requirements
The process starts with a customer requirement rather than an internal part number. A user might specify pump flow and pressure, conveyor length and load, an air-handling unit capacity, a vehicle body configuration or the dimensions of a machine enclosure.
Requirements can be entered as selections, measurements, free text, imported data or answers to guided questions. A well-designed model asks only relevant questions. For example, a pump configuration may reveal seal and impeller options only after the user selects the fluid and operating temperature.
2. The product model presents valid choices
The product model represents the product structure, options, attributes, dependencies and rules. It may contain models, modules, features, components, accessories, services and replacement choices.
For example, a configurable electrical control panel model may include:
- enclosure size and material;
- incoming voltage and frequency;
- motor starter or variable-frequency drive selection;
- number and rating of motor circuits;
- operator interface and communication protocol;
- environmental protection rating;
- certification and documentation requirements.
The model should expose valid commercial choices without requiring the user to understand every internal component number. This is one difference between a product model and a static online catalog.
3. Rules validate the configuration
Configuration rules determine which combinations are allowed, required, recommended or prohibited. A rule might state that a particular motor is available only above a certain voltage, that a material is unsuitable for a specified chemical, or that a larger frame requires a different baseplate.
Common rule types include:
- Compatibility rules: prevent incompatible options from being selected together.
- Dependency rules: make one option require another option.
- Exclusion rules: prevent a combination that cannot be manufactured, certified or sold.
- Conditional visibility rules: display questions or options only when they are relevant.
- Validation rules: check ranges, units, capacities, clearances or required information.
- Selection rules: recommend or automatically select components based on requirements.
Manufacturing CPQ may use rules-based configuration, constraint-based configuration, guided selling or a combination of these approaches. Rules-based configuration explicitly evaluates conditions and actions. Constraint-based configuration solves for permissible values within technical limits. Guided selling simplifies the user experience by asking requirement-oriented questions and steering the user toward appropriate products. These approaches overlap, but they are not interchangeable.
4. Engineering calculations refine the product
Some products cannot be configured accurately using option dependencies alone. The system may need to calculate dimensions, capacity, performance or component sizes.
Examples include:
- selecting a pump impeller and motor from flow, head and efficiency requirements;
- calculating the number of conveyor sections from length and transfer requirements;
- sizing a heat exchanger from flow, temperature and duty values;
- choosing structural members from span, load and deflection constraints;
- calculating cable, breaker or enclosure requirements for an electrical assembly.
These calculations may be native to the CPQ platform, implemented through an external engineering service or handled by an integrated design application. A CPQ buyer should establish whether the required calculation method is supported, how units and rounding are handled, and how engineering formulas are tested and governed.
5. The system calculates cost and price
Pricing is separate from configuration. Configuration determines what the product is; pricing determines what the customer should be charged.
A manufacturing pricing model can include component costs, labor, purchased items, overhead assumptions, tooling, freight, installation, services, currency, regional price lists, customer agreements, quantity breaks, margins and approval thresholds. Some implementations calculate estimated manufacturing cost before applying a margin. Others use a maintained selling price for each option or a combination of both.
Pricing logic may also depend on technical attributes. A larger machine may require additional labor or shipping. A material change may affect both component cost and manufacturing process. A custom engineering requirement may add a non-recurring engineering charge rather than a standard option price.
6. The system generates the quote
The quote typically includes a description of the configured product, quantities, prices, discounts, lead-time assumptions, terms, exclusions and validity dates. It may also include images, technical specifications, performance curves, configuration summaries and customer-specific language.
Quote generation is not the same as proposal design. A document can look professional while still containing an invalid configuration. Manufacturing CPQ should generate the commercial document from the validated configuration and the approved price result, reducing the risk that the proposal and the intended product diverge.
7. The configuration is handed to downstream systems
After approval, the configured result may be sent to an ERP system for order processing, a PLM system for product and revision control, a product data management (PDM) system for design files, a CAD system for design automation, or a manufacturing execution system for production execution.
The handoff can include a configured product identifier, options, attributes, quantities, prices, a bill of material, routings, drawings, files, customer requirements or engineering tasks. The exact output depends on the product, the CPQ platform and the surrounding architecture.
What data does manufacturing CPQ require?
A CPQ project depends on more than a price list. Its data foundation usually includes the following.
| Data area | Typical content | Why it matters |
|---|---|---|
| Product structure | Models, modules, options, components and accessories | Defines what can be configured |
| Technical attributes | Dimensions, capacities, materials, ratings and performance values | Supports validation and calculations |
| Configuration rules | Dependencies, exclusions, constraints and required selections | Prevents invalid or incomplete products |
| Cost data | Material, labor, purchased-part and service costs | Supports margin and profitability decisions |
| Pricing data | Price lists, discounts, currencies and commercial policies | Produces a consistent customer price |
| Manufacturing data | Parts, quantities, revisions, routings or work instructions | Supports order and production handoff |
| Document data | Templates, specifications, drawings and certificates | Creates a complete customer or internal package |
Data ownership is often distributed. Engineering may own technical rules, product management may own options, finance may own pricing policies, manufacturing may own routings and IT may own integration services. A governance model is required to resolve conflicts and control changes.
CPQ, configurable products and manufacturing outputs
Configurable BOMs
A bill of material (BOM) lists the components required to build a product. A configurable BOM contains alternative, conditional or variable components that depend on the selected configuration.
For example, a machine may use one motor for a standard voltage and another for a high-voltage option. A CPQ system can identify the correct component when the electrical requirement is selected, provided the relevant product and BOM logic has been modeled.
EBOM and MBOM
An engineering bill of material (EBOM) describes a product from an engineering or design perspective. A manufacturing bill of material (MBOM) describes how that product is assembled or produced, including manufacturing-specific groupings, consumables, packaging or process requirements.
CPQ may generate or select an EBOM, an MBOM, a commercial BOM, or an intermediate configuration structure. It should not be assumed that a CPQ-generated BOM is automatically suitable for production. Transformation, approval, revision control and ERP or manufacturing-system ownership may still be required.
CAD and engineering automation
CAD automation connects configuration inputs to parametric models, assemblies, drawings or other design files. A configured machine might produce a dimensioned layout, a vehicle configuration might generate a body variation, or a tank selection might produce a product-specific drawing.
CAD automation is an advanced capability, not a mandatory component of every CPQ system. Where it is required, evaluate supported CAD platforms, template management, model regeneration, drawing rules, file naming, revision control, processing time and failure handling. The CAD and engineering automation guide covers these considerations in more detail.
Where CPQ fits in the manufacturing technology stack
CPQ usually sits between customer-facing channels and enterprise product, commercial and manufacturing systems. It should complement—not replace—systems with different responsibilities.
| System | Primary responsibility | Typical CPQ relationship |
|---|---|---|
| CRM | Customer, opportunity and sales activity management | Provides opportunity context and receives quote status or values |
| ERP | Orders, inventory, purchasing, finance and core enterprise transactions | Receives approved configuration, order and pricing data |
| PLM | Product definition, lifecycle, revisions and engineering governance | Provides controlled product data or receives configured product records |
| PDM | CAD files, documents and design data management | Stores or supplies controlled engineering files |
| CAD | Geometry, assemblies, drawings and design models | May be driven by configuration inputs |
| PIM | Product information for catalogs and commerce channels | May supply descriptions, attributes and media |
| MES | Shop-floor execution, production tracking and quality processes | May receive production-relevant configuration data |
These systems may exchange data through APIs, middleware, files, events or direct connectors. Integration design should identify the system of record for each data object. For example, CPQ may calculate a quote price, ERP may create the sales order, PLM may control the approved product definition and MES may control production execution.
See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD, PIM and MES for architecture considerations.
A manufacturing CPQ example: configuring an industrial pump
Consider a manufacturer selling centrifugal pumps for industrial applications. A sales engineer enters the required flow rate, discharge pressure, fluid type, temperature, installation arrangement, power supply and certification requirements.
- The configuration model identifies appropriate pump families.
- A performance calculation checks whether the selected pump can meet the duty point.
- Material rules exclude an impeller or seal material that is incompatible with the fluid.
- The system selects a motor and frame based on power, voltage and regional requirements.
- Accessory rules add a baseplate, coupling guard, instrumentation or documentation package.
- The cost model calculates material, purchased components and engineering effort.
- The pricing model applies the relevant customer price list, margin and discount authority.
- The quote includes performance information, scope, delivery assumptions and price.
- If supported, a configurable BOM, product record, drawing or ERP order structure is generated.
This example shows why manufacturing CPQ cannot be evaluated only by asking whether it can create a PDF quote. The important questions include whether the model can represent the product, whether the rules are maintainable, whether calculations are reliable, whether the selected components are traceable and whether the result can be used by engineering and production.
Manufacturing workflows supported by CPQ
Configure-to-order
Configure-to-order (CTO) uses a predefined product architecture with controlled options. The product is configured from known modules and manufactured or assembled after the order. CTO is often a strong fit for CPQ because the possible combinations can be modeled in advance.
Engineer-to-order
Engineer-to-order (ETO) requires significant engineering work for an individual order. CPQ can capture requirements, apply preliminary rules, estimate price and create an engineering work package, but it may not fully automate design or production. An ETO workflow should make the boundary between automated configuration and engineering review explicit.
Make-to-order and assemble-to-order
Make-to-order (MTO) products are produced after an order rather than from finished-goods inventory. Assemble-to-order (ATO) products are assembled from stocked or planned modules after order entry. CPQ may support either workflow by producing a valid configuration and the required component or assembly information.
The manufacturing workflows guide explains how CPQ fits into CTO, ETO, MTO and ATO processes.
Benefits of CPQ for manufacturers
- Fewer configuration errors: rules prevent or flag invalid combinations before order entry.
- Shorter quote preparation: reusable models and automated calculations reduce manual effort.
- More consistent pricing: common price logic, approval policies and discount controls reduce spreadsheet variation.
- Better sales-engineering capacity: experts can focus on exceptions and high-value technical work rather than repetitive checks.
- Improved handoff quality: validated options and requirements can accompany the order or engineering request.
- Faster product knowledge distribution: dealers and sales teams can use approved rules instead of relying on informal expertise.
- Traceability: the selected options, rule outcomes, prices and revisions can be recorded with the quote.
- Better visibility into product complexity: configuration data can reveal frequent exceptions, costly options and unprofitable combinations.
Benefits depend on model quality, data accuracy, user adoption and integration. Implementing a CPQ interface without maintaining its product rules will not solve inaccurate product data.
Limitations and risks
CPQ is not a substitute for disciplined product management or engineering governance. Common limitations include:
- Model complexity: large product portfolios can create difficult-to-maintain rule networks.
- Data ownership problems: conflicting part numbers, prices, revisions and option definitions can undermine trust.
- Incomplete engineering coverage: a sales configuration may not capture every design or manufacturing requirement.
- Integration dependency: stale ERP, PLM or CAD data can produce incorrect results even when the CPQ logic is sound.
- Exception handling: ETO products and unusual customer requirements still need human review.
- Performance concerns: complex calculations, CAD generation or large product models may affect response times.
- Governance burden: every new option, component, rule and price change requires testing and controlled release.
- False automation expectations: generating a quote does not automatically mean that an order is ready for production.
How to evaluate CPQ software for manufacturing
Evaluation should begin with representative products and real configuration scenarios rather than generic feature checklists. Test standard configurations, invalid combinations, boundary values, engineering exceptions, customer-specific pricing and downstream outputs.
| Evaluation area | Questions to ask |
|---|---|
| Configuration depth | Can the system model modules, attributes, dependencies, constraints and dimensions? |
| Rule maintenance | Who can create, test, approve and release rules? Are dependencies understandable? |
| Engineering calculations | Can formulas, units, tolerances and external calculation services be supported? |
| BOM output | Does it generate a configurable BOM, EBOM, MBOM or only a commercial summary? |
| CAD automation | Can it drive the required CAD templates and produce controlled files or drawings? |
| Pricing and costing | Can it handle cost rollups, margins, currencies, discounts, approvals and customer agreements? |
| Workflow | Does it support CTO, ETO, MTO, ATO, dealer and sales-engineering processes? |
| Integration | Are APIs, events, connectors and ownership boundaries suitable for the existing architecture? |
| Governance | Are versioning, testing, audit history and release management available? |
| Scalability | Can the system handle the number of products, rules, users, regions and transactions required? |
Documented vendor capabilities should be separated from capabilities that require customization, partner services or a separate application. The manufacturing CPQ comparison and selection resources can help structure an evaluation.
Implementing CPQ in a manufacturing business
A practical implementation usually starts with a bounded product family and a measurable workflow problem. Choose a product with meaningful configuration complexity but sufficiently reliable source data.
- Define the business case: identify quote delays, configuration errors, engineering workload, margin leakage or poor handoffs.
- Map the current workflow: document how requirements, options, prices, approvals, BOMs and orders move between teams.
- Inventory product data: reconcile part numbers, options, revisions, costs, prices, drawings and existing spreadsheets.
- Design the product model: separate customer-facing choices from internal components and engineering attributes.
- Capture and test rules: identify dependencies, exclusions, calculations, limits and unresolved exceptions.
- Define system ownership: decide which system owns product definitions, prices, customers, orders, CAD files and production data.
- Build integrations deliberately: specify data contracts, error handling, synchronization frequency and security.
- Test realistic scenarios: include valid, invalid, incomplete, boundary and exceptional configurations.
- Train users and administrators: explain both the workflow and the reason behind important rules.
- Establish governance: control changes to products, formulas, pricing, documents, integrations and releases.
Implementation planning should include migration, testing, deployment, adoption, maintenance and performance measurement. The CPQ implementation guide provides a framework for these activities.
Is CPQ software the same as a product configurator?
No. A product configurator focuses on defining a valid product from available options and requirements. CPQ includes configuration but also covers pricing and quoting. A manufacturing product configurator may produce a technical configuration without calculating a customer price, while a sales CPQ application may calculate a price without generating a production-ready BOM or CAD file.
Some platforms combine these functions in one application. Others integrate a configurator, pricing engine, document generator and engineering tools. The distinction matters when defining requirements and comparing software.
Semantic map
The main entities and relationships in this guide are:
- CPQ software connects customer requirements with product configuration, pricing and quoting.
- Product models represent configurable products, options, attributes and components.
- Configuration rules prevent invalid combinations and identify required selections.
- Engineering calculations translate requirements into technical selections or dimensions.
- Configured products can generate commercial summaries, BOMs, drawings or engineering tasks.
- Pricing models convert configuration data, costs and commercial policies into a quote price.
- CRM manages customer and opportunity context, while ERP manages orders and enterprise transactions.
- PLM and PDM manage product revisions and engineering files rather than replacing CPQ.
- CAD automation can generate product-specific geometry and drawings from configuration inputs.
- CTO, ETO, MTO and ATO define different relationships between configuration, engineering and production.
Frequently asked questions
1. What is CPQ software in manufacturing?
It is software that helps configure complex products, validate technical and commercial rules, calculate prices and generate quotes. Depending on the implementation, it may also generate BOMs, drawings, engineering outputs or production handoffs.
2. What does CPQ stand for?
CPQ stands for Configure, Price, Quote. The terms describe product selection and validation, price calculation, and quotation generation.
3. How is manufacturing CPQ different from sales CPQ?
Sales CPQ often focuses on guided selling, pricing, discounts and proposals. Manufacturing CPQ may additionally manage engineering constraints, calculations, configurable BOMs, CAD automation and order-to-production data.
4. Does every CPQ system generate a BOM?
No. Some systems produce only a configured quote or commercial product summary. Others can generate configurable BOMs or integrate with ERP, PLM or engineering systems to create downstream structures.
5. Can CPQ generate CAD drawings?
Some platforms support CAD or design automation, while others require a separate CAD automation service or integration. Buyers should verify supported CAD systems, templates, file outputs, revisions and exception handling.
6. Can CPQ replace ERP?
No. ERP normally manages orders, inventory, purchasing, finance and other enterprise transactions. CPQ can provide validated configuration and pricing data to ERP.
7. Can CPQ replace PLM?
No. Product lifecycle management systems manage product definitions, revisions, changes and lifecycle governance. CPQ may consume approved product data or create a configured product record, but the responsibility boundary must be defined.
8. Is a product configurator the same as CPQ?
No. A configurator determines a valid product. CPQ includes configuration plus pricing and quoting, although the two functions are frequently delivered together.
9. Can CPQ support engineer-to-order products?
It can support ETO by collecting requirements, applying preliminary rules, estimating price and creating an engineering task. It may not fully automate the custom design or eliminate engineering review.
10. What is the difference between CTO and ETO?
Configure-to-order uses a predefined product architecture and controlled options. Engineer-to-order requires significant product-specific engineering for an individual order.
11. What is the difference between EBOM and MBOM?
EBOM is an engineering view of product structure. MBOM is a manufacturing view describing how the product is assembled or produced. A CPQ output may be one of these or an intermediate configurable structure.
12. Does CPQ calculate manufacturing cost?
Some implementations calculate or roll up estimated material, labor, purchased-part and service costs. Others focus on selling price and margin rules. Costing capability must be verified for the target product and accounting model.
13. Who maintains CPQ configuration rules?
Ownership is commonly shared by product management, engineering, manufacturing, sales operations, finance and IT. A defined governance process is needed to approve, test and release changes.
14. Can distributors and dealers use manufacturing CPQ?
Yes, if the implementation supports the required channels, permissions, territories, price lists and product visibility. Dealer users may need a simpler guided experience than internal engineers.
15. Can customers configure products through CPQ?
Some implementations expose a self-service or ecommerce experience. The model should be designed so that customers see appropriate choices without exposing internal components or unsupported engineering complexity.
16. What integrations are common for manufacturing CPQ?
Common integrations include CRM, ERP, PLM, PDM, CAD, PIM, MES and ecommerce systems. The specific integration depends on which system owns each data object and workflow.
17. How should a company start a CPQ implementation?
Start with a defined product family and workflow problem, audit the source data, model representative rules, test real scenarios and establish system ownership before expanding the scope.
18. What are the main risks of implementing CPQ?
Typical risks include poor product data, unmaintainable rules, unclear ownership, weak integration design, inadequate testing and the assumption that quoting automation automatically creates production-ready information.
19. How does CPQ reduce configuration errors?
It applies dependencies, exclusions, constraints, calculations and required-field checks during configuration. This prevents or flags invalid combinations before a quote or order is released.
20. What should manufacturers evaluate in a CPQ vendor?
Evaluate configuration depth, rule maintenance, calculations, BOM and CAD outputs, costing, pricing, workflow support, integrations, governance, scalability and implementation requirements using real product scenarios.