CPQ Guide

Tag: pricing engine

  • 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.

  • Cost-Plus Pricing in Manufacturing CPQ

    Cost-plus pricing in manufacturing CPQ calculates the estimated or standard cost of a configured product and adds a defined markup, margin, fee or other commercial adjustment to determine the selling price. In a manufacturing environment, the cost may come from a configurable bill of materials (BOM), purchased components, labor operations, machine time, subcontracting, freight, overhead and engineering effort.

    The important distinction is that manufacturing CPQ does not apply markup to an abstract product record. It first interprets the customer’s selections, validates the configuration, determines the required components and operations, and then calculates a cost basis. The price is therefore connected to the actual product variant being quoted.

    For example, a pump manufacturer might configure a pump using a particular flow rate, pressure rating, impeller material, motor size, seal type, enclosure and certification package. Each selection can change the BOM, procurement cost, assembly time, testing requirements and final selling price. A manufacturing CPQ system can apply cost-plus rules to this calculated cost, route exceptions for approval and produce a quote that reflects the selected design.

    Cost-plus pricing is useful when costs are known or can be estimated reliably but market-based price lists are insufficient. It is especially relevant to engineered products, configure-to-order (CTO) products, make-to-order (MTO) products and engineer-to-order (ETO) projects. However, cost-plus pricing is not automatically accurate. Its quality depends on the product model, cost data, allocation rules, currency handling, revision control and governance behind it.

    What is cost-plus pricing?

    Cost-plus pricing is a pricing method in which a selling price is calculated by adding a markup or margin to a defined cost base.

    A simple markup formula is:

    Selling price = Cost base × (1 + markup percentage)

    If a configured machine has a cost base of 20,000 and the approved markup is 25%, the calculated selling price is 25,000 before taxes, freight or other adjustments.

    A margin-based formula is different:

    Selling price = Cost base ÷ (1 - target margin percentage)

    With a cost base of 20,000 and a target gross margin of 25%, the selling price is 26,666.67. A 25% markup and a 25% margin are not the same result, so the pricing model must state which method is being used.

    The cost base can include different categories:

    • material and purchased component cost;
    • direct manufacturing labor;
    • machine or production time;
    • subcontracting and outside processing;
    • engineering and design effort;
    • testing, inspection and certification;
    • packaging and logistics;
    • allocated manufacturing overhead;
    • project-specific risk or contingency allowances.

    Manufacturers should define whether the cost base represents standard cost, current estimated cost, average cost, quoted supplier cost, planned project cost or another controlled measure. Mixing these concepts can produce prices that appear precise but do not support reliable profitability decisions.

    How cost-plus pricing fits into manufacturing CPQ

    CPQ means configure, price, quote. In manufacturing CPQ, the three activities are connected but are not interchangeable.

    • Configure: select valid options, dimensions, materials, capacities, accessories and technical parameters.
    • Price: calculate cost, markup, margin, discounts, surcharges, freight and commercial terms.
    • Quote: present the configured product, price, assumptions, lead time and terms in an approved document.

    A generic sales CPQ application may calculate prices from a product catalog and discount schedule. A manufacturing-oriented CPQ implementation may also calculate engineering attributes, produce a configurable BOM, invoke CAD or engineering calculations, identify purchased parts and send manufacturing data to enterprise systems. These deeper capabilities are not present in every CPQ platform and must be verified during software evaluation.

    The normal data flow is:

    1. A salesperson, dealer or application engineer enters customer requirements.
    2. The product model presents valid options and applies dependencies and constraints.
    3. Configuration rules determine the selected components, quantities and technical values.
    4. A configurable BOM and, where supported, engineering outputs are generated.
    5. Cost data is retrieved or calculated for materials, labor, overhead and services.
    6. Cost-plus pricing rules apply markup, target margin, surcharges and discounts.
    7. Approval rules evaluate margin, deal size, risk and non-standard requirements.
    8. The system generates a quote and records the configuration and pricing assumptions.
    9. Approved data is transferred to CRM, ERP, PLM, PDM, CAD or other systems as appropriate.

    More detail on the relationship between configuration, dependencies and validation is available in the product configuration guide. BOM structures, costing and quote documents are covered in the BOM, pricing and quoting guide.

    Cost-plus pricing data model

    A reliable cost-plus model usually separates product configuration data, cost data and commercial pricing policy. Keeping these concerns distinct makes the model easier to maintain and audit.

    Data area Typical content Manufacturing purpose
    Product model Options, features, dimensions and dependencies Defines what can be configured
    Configuration rules Constraints, compatibility rules and calculations Prevents technically invalid products
    Configurable BOM Components, quantities, alternatives and effectivity Represents the selected product structure
    Cost records Material, labor, machine, supplier and overhead values Provides the cost basis
    Pricing policy Markup, margin, surcharges, discounts and currencies Converts cost into a commercial price
    Approval policy Thresholds, authorities and exception reasons Controls commercial and technical risk
    Quote content Scope, price, lead time, assumptions and validity Communicates the approved offer

    Cost data from the BOM

    A configurable BOM is a product structure whose components vary according to configuration choices. For example, a selected stainless-steel wetted path may replace carbon-steel components, while a higher pressure class may add stronger castings, a different seal and additional testing.

    The CPQ system may calculate component cost as:

    Component cost = quantity × unit cost × yield or waste adjustment

    It may then aggregate the component values and add operation costs. The BOM used for quoting may be an estimated commercial structure rather than the final production structure. This distinction should be explicit.

    An engineering BOM, or EBOM, describes a product from a design perspective. A manufacturing BOM, or MBOM, describes how it is assembled or produced. A CPQ-generated configurable BOM may support quoting and order entry without being a complete EBOM or MBOM. It should not be treated as production-ready unless the implementation has been designed and validated for that purpose.

    Labor, machine and overhead cost

    Material cost alone is often inadequate for industrial equipment. A configured control panel may require additional wiring, testing and documentation. A large conveyor may require more fabrication and assembly hours than a small version. An engineered skid may require design review, pressure testing and site-specific documentation.

    Cost calculations can use routing operations, standard times, work-center rates or manually maintained estimates. A simplified operation formula is:

    Operation cost = estimated hours × applicable rate

    The rate may represent direct labor, machine time, burden or a combined work-center rate. The implementation should document whether overhead is included in the rate, added as a separate percentage or excluded from the customer-facing price calculation.

    Rules that control cost-plus pricing

    Pricing rules should reflect both the product configuration and the commercial context. Common rules include:

    • apply different markup rates to standard assemblies, bought-out items and engineering services;
    • use higher margins for low-volume or high-risk configurations;
    • add a surcharge for stainless steel, hazardous-area certification or special testing;
    • apply minimum selling prices to configured products or product families;
    • use customer, channel or territory-specific commercial policies;
    • require approval when margin falls below a threshold;
    • require approval when estimated engineering hours exceed a limit;
    • use different currencies and valid price dates;
    • separate recurring service charges from one-time equipment pricing;
    • apply freight, installation, commissioning or site-service charges separately.

    These rules should not be used to compensate for invalid configuration logic. A pricing rule should not permit an incompatible motor, pressure rating or material combination simply because the calculated price is acceptable. Product validity belongs to the configuration model; commercial treatment belongs to the pricing model.

    Worked manufacturing example

    Consider a manufacturer quoting a configurable centrifugal pump package. The customer selects:

    • stainless-steel wetted components;
    • a higher pressure class;
    • a 30 kW motor;
    • a variable-frequency drive;
    • a mechanical seal suitable for the process fluid;
    • a control panel and factory performance test.

    The rules engine validates that the motor is compatible with the pump duty and that the selected seal is compatible with the fluid and temperature. The configured BOM includes the pump casing, impeller, shaft, seal, motor, drive, panel, base frame, cabling and test activities.

    Suppose the calculated cost basis is:

    Cost category Amount
    Materials and purchased components 18,400
    Assembly and wiring labor 2,100
    Testing and inspection 900
    Engineering and documentation 1,200
    Allocated overhead 1,400
    Total cost basis 24,000

    If the commercial policy applies a 30% markup, the calculated price is 31,200. If the policy targets a 30% gross margin, the price is 34,285.71. The quote should identify the applicable method internally, even if the customer sees only the final selling price.

    If the customer requests a discount that reduces the price below the approved margin threshold, the CPQ workflow can require a sales manager or commercial director to approve it. The approval record should retain the original cost, proposed price, effective margin, reason for exception and approver.

    Cost-plus pricing and engineering automation

    Engineering automation can improve cost accuracy when configuration selections affect dimensions, performance or production effort. Depending on the platform and integration design, the CPQ process may invoke parametric CAD, engineering calculations, sizing algorithms or document generation.

    For example, selecting a larger tank volume may change shell diameter, material quantity, support structure, transport requirements and fabrication hours. A calculation service could estimate dimensions and weight, while CAD automation could produce a product-specific drawing. The resulting attributes can feed the BOM and cost model.

    Not every CPQ product includes CAD automation, 3D visualization or engineering calculations. Some implementations connect CPQ to specialist CAD or calculation tools through APIs or middleware. The CAD and engineering automation guide explains these relationships and their implementation implications.

    Engineering automation also introduces risks. A calculation may be correct for one revision of a design standard but invalid after a material, supplier or manufacturing process changes. Engineering outputs therefore require version control, test cases, ownership and release management.

    Integration architecture

    Cost-plus pricing usually depends on data from several enterprise systems. These systems should be distinguished rather than treated as one product database.

    System Potential role in cost-plus CPQ
    CRM, or customer relationship management Opportunity, account, contact, sales stage and commercial context
    ERP, or enterprise resource planning Items, suppliers, inventory, standard costs, currencies, orders and financial data
    PLM, or product lifecycle management Released product definitions, revisions, effectivity and engineering change governance
    PDM, or product data management CAD files, drawings and controlled design data
    CAD, or computer-aided design Geometry, drawings, models and design automation
    PIM, or product information management Commercial descriptions, specifications and channel content
    MES, or manufacturing execution system Production execution, actual work data and shop-floor feedback

    The CPQ system may own the configuration logic and quoting workflow while consuming item and cost data from an ERP system. In another architecture, the CPQ platform may maintain a commercial product model and send an approved configuration to ERP for item creation or order processing. Neither pattern is universally correct.

    Integration decisions should cover cost update frequency, item and revision identifiers, currency conversion, units of measure, supplier pricing, error handling, offline quoting, effective dates and ownership of each field. The CPQ integration guide provides a broader framework for these decisions.

    Benefits of cost-plus pricing in manufacturing CPQ

    • Faster quoting: sales and application engineers can calculate prices without rebuilding every estimate manually.
    • Better configuration-price alignment: price changes follow selected materials, capacities, options and services.
    • More consistent margins: approved rules reduce arbitrary markups across sales channels.
    • Improved visibility: commercial teams can see the cost assumptions behind a quote.
    • Controlled exceptions: discount and low-margin requests can be routed for approval.
    • Better handoff: the quote can retain configuration, BOM and engineering assumptions for order entry.
    • Scenario analysis: teams can compare materials, suppliers, production methods or product variants.

    These benefits depend on data quality and operational discipline. Automation does not make an outdated cost model accurate; it applies the model more consistently.

    Limitations and risks

    Cost data may be stale

    Supplier prices, labor rates, exchange rates and overhead assumptions change. A CPQ system using last year’s standard cost may produce a mathematically correct but commercially weak quote.

    Allocated overhead can be misleading

    Overhead allocation is a management accounting decision, not merely a software setting. A single percentage may not represent the economics of different plants, product families or production volumes.

    Cost-plus may ignore market value

    A price based only on internal cost may be too high for a competitive product or too low for a specialized product with strong customer value. Manufacturers often combine cost-plus logic with market price limits, target prices, competitive guidance or value-based adjustments.

    ETO costs are uncertain

    In ETO work, the final design may not exist at quote time. Engineering hours, supplier selection, testing and production effort may be estimates. The quote should expose assumptions and identify which values are provisional.

    Estimated BOMs are not final production structures

    A CPQ BOM may omit fabrication details, consumables, phantom assemblies, routing steps or plant-specific manufacturing information. A controlled handoff to ERP, PLM or engineering is needed before production release.

    Complex rules can become difficult to govern

    Pricing exceptions added over time can create overlapping conditions and unpredictable outcomes. Rule ownership, version control, automated testing and documented precedence are essential.

    Implementation approach

    A practical implementation should begin with a limited product family and a clear cost-plus use case. The following sequence is useful:

    1. Define the commercial objective. Decide whether the model is intended for standard pricing, preliminary estimates, ETO proposals, dealer pricing or internal profitability analysis.
    2. Map the configuration scope. Identify options, dimensions, dependencies, exclusions and required technical calculations.
    3. Define the cost basis. Document which material, labor, machine, engineering, overhead, freight and risk components are included.
    4. Separate EBOM, MBOM and quote structures. Establish whether the CPQ BOM is for commercial estimation, engineering handoff or manufacturing execution.
    5. Set pricing policies. Define markup versus margin, minimum prices, surcharges, discounts, currencies and effective dates.
    6. Design approval thresholds. Include margin, total value, non-standard materials, long lead items, engineering uncertainty and contractual risk.
    7. Assign data ownership. Product management, engineering, finance, procurement, manufacturing and sales operations may own different parts of the model.
    8. Build test scenarios. Test valid and invalid configurations, cost changes, currency changes, revisions, discounts and approval paths.
    9. Validate downstream handoff. Confirm that the approved configuration and pricing can be used by CRM, ERP, PLM, CAD or production systems as intended.
    10. Monitor the model after launch. Review quoted versus actual cost, margin leakage, override frequency, approval volume and rule defects.

    Implementation planning should also address product data migration, release management, user permissions, audit history and model maintenance. The manufacturing CPQ implementation guide covers these topics in more detail.

    Cost-plus pricing in CTO, MTO and ETO workflows

    Workflow Cost-plus pricing characteristics
    Configure-to-order (CTO) Uses a defined product model and known component choices. Cost and lead time can often be calculated consistently.
    Make-to-order (MTO) Uses a customer order to trigger production. Cost may depend on batch size, capacity and scheduling assumptions.
    Assemble-to-order (ATO) Combines stocked modules or subassemblies. Cost can be based on known module values and assembly operations.
    Engineer-to-order (ETO) Requires new or modified engineering. Engineering hours, design risk and provisional BOM content must be estimated explicitly.

    CTO generally offers the strongest foundation for automated cost-plus pricing because the options and cost relationships are known. ETO requires more controlled assumptions and often a staged process in which an initial CPQ estimate becomes a refined engineering estimate after design review.

    These workflows are described further in the manufacturing workflows guide.

    How to evaluate CPQ software for cost-plus pricing

    When evaluating CPQ software for manufacturing, ask vendors to demonstrate a real product model rather than a generic discount table. A useful demonstration should include:

    • configuration rules for dimensions, materials and technical dependencies;
    • selection-driven BOM changes and component quantities;
    • separate standard cost, estimated cost and selling price values;
    • markup and margin calculations shown transparently;
    • multi-level approvals for margin and engineering exceptions;
    • effective dates, revisions and currency handling;
    • quote output containing assumptions and validity conditions;
    • integration with ERP cost and item data;
    • optional links to PLM, PDM, CAD or calculation tools;
    • audit history for configuration, cost and price changes;
    • testing and governance tools for large product models.

    Do not assume that a platform’s general CPQ label means it supports configurable BOMs, CAD automation, production costing or ETO. Verify each capability, its data requirements and whether it is native, configurable, custom-developed or dependent on another system. The manufacturing CPQ software section and CPQ comparison guides provide additional evaluation context.

    Semantic map

    The following relationships summarize how cost-plus pricing connects configuration, engineering, commercial rules and manufacturing systems:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • A configured product generates a configurable BOM.
    • A configurable BOM provides cost components.
    • ERP supplies item and cost data.
    • PLM governs released product revisions.
    • CAD automation generates product-specific drawings.
    • Engineering calculations determine technical attributes.
    • Cost-plus rules convert cost into selling price.
    • Approval rules control margin exceptions.
    • Approved quotes communicate scope and price.
    • CRM stores the opportunity and commercial context.
    • ERP receives approved order and item information.
    • ETO introduces uncertain engineering cost.
    • Actual manufacturing cost can improve future estimates.

    FAQ

    What is cost-plus pricing in manufacturing CPQ?

    It is a method that calculates the cost of a configured product and adds a defined markup or target margin to determine its selling price.

    How is cost calculated in manufacturing CPQ?

    Cost may be calculated from BOM components, purchased parts, labor, machine time, subcontracting, engineering, testing, freight and overhead, depending on the implementation.

    Is a 30% markup the same as a 30% margin?

    No. A 30% markup multiplies cost by 1.30, while a 30% margin calculates price by dividing cost by 0.70. The resulting prices are different.

    What is the difference between cost-plus pricing and value-based pricing?

    Cost-plus pricing starts with internal cost and adds a commercial adjustment. Value-based pricing considers the value delivered to the customer and may not track internal cost directly.

    Can cost-plus pricing use a configurable BOM?

    Yes, if the CPQ system supports configurable BOM logic. The selected options can determine components, quantities and cost inputs.

    Does every CPQ system generate BOMs?

    No. Some systems focus on sales configuration and quoting, while others support configurable BOM generation or integration with engineering and ERP systems.

    What is the difference between an EBOM and an MBOM?

    An EBOM describes the product from an engineering perspective. An MBOM describes how the product is assembled or manufactured. A CPQ quote BOM may be a separate commercial or estimated structure.

    Can CPQ calculate labor and machine cost?

    It can when the implementation includes operation times, work-center rates or connected manufacturing data. This capability should be verified for the selected platform.

    How does cost-plus pricing support engineer-to-order products?

    It can estimate engineering, material and production costs before the design is complete, but the quote must identify assumptions and uncertainty.

    How are discounts handled in a cost-plus model?

    Discounts can be applied after the calculated price, subject to minimum price or margin rules and approval thresholds.

    Should overhead be included in the cost base?

    That is a management accounting decision. The implementation should document which overhead categories are included and how rates are maintained.

    How does ERP integrate with cost-plus CPQ?

    ERP may provide item records, supplier costs, standard costs, currencies and order data. CPQ may return the approved configuration, price and order-related information.

    Can CPQ use supplier costs that change frequently?

    It can if supplier data is integrated or maintained with effective dates. Frequent changes require clear refresh procedures and fallback behavior when data is unavailable.

    What approvals are common for cost-plus quotes?

    Common approvals cover low margins, large discounts, high total value, non-standard materials, unusual payment terms, engineering uncertainty and commercial risk.

    Can cost-plus pricing be used for dealer quotes?

    Yes. Dealer pricing can apply channel-specific markups, discounts, currencies and approval rules while preserving the underlying configuration and cost logic.

    How should a manufacturer test cost-plus pricing?

    Test valid and invalid configurations, BOM changes, cost revisions, markup and margin formulas, currencies, discounts, approval paths and downstream order data.

    What are the main risks of cost-plus pricing?

    The main risks are stale cost data, inaccurate overhead allocation, incomplete BOMs, uncertain ETO estimates, excessive overrides and poorly governed pricing rules.

    Can CAD automation improve cost-plus accuracy?

    It can when geometry, dimensions or design outputs affect material, labor or manufacturing effort. CAD automation is not included in every CPQ platform.

    What KPIs should be monitored after implementation?

    Useful measures include quote cycle time, quoted versus actual cost, margin leakage, manual override frequency, approval duration, rule defects and rework after order entry.

  • CPQ Configurator vs Product Configurator: What Is the Difference?

    A product configurator determines how a product can be configured. A CPQ configurator uses product configuration as one part of a broader Configure, Price, Quote process. In manufacturing, that broader process may include engineering rules, calculations, costing, pricing, quote generation, bills of material (BOMs), CAD outputs and handoffs to enterprise systems.

    The terms overlap because many modern manufacturing CPQ platforms contain a product configuration engine. However, they are not automatically interchangeable. A standalone product configurator may validate options and display a configured machine without calculating a commercial price or creating a production-ready BOM. A CPQ configurator normally connects the valid configuration to commercial and, depending on the implementation, engineering and operational outputs.

    The practical distinction is therefore one of scope:

    • Product configurator: focuses primarily on selecting and validating the product.
    • CPQ configurator: configures the product and supports pricing, quoting and related downstream processes.

    For a manufacturer selling pumps, industrial machinery, HVAC systems, electrical equipment or specialty vehicles, the right choice depends on whether the business needs only configuration guidance or needs to turn a validated configuration into an accurate, manufacturable commercial transaction.

    What is a product configurator?

    A product configurator is software that helps a user select valid features, options, dimensions, materials and components for a product. It applies product rules to prevent incompatible combinations and may calculate technical values or display the result visually.

    For example, a pump product configurator might ask for:

    • flow rate and discharge pressure;
    • pump type and impeller diameter;
    • motor voltage and power rating;
    • casing material, such as cast iron or stainless steel;
    • seal and bearing options;
    • connection size and mounting arrangement.

    The configurator can use dependencies and constraints to determine whether a chosen combination is valid. A stainless-steel casing may require a particular seal. A selected flow rate may require a larger impeller or motor. A voltage option may be unavailable for a specific motor size. If the user selects an incompatible combination, the system can block it, remove the option or explain what must change.

    A product configurator can be deployed in several places, including a sales application, dealer portal, business-to-business ecommerce site, engineering application or internal product-selection tool. It may be a standalone application or a component within a larger CPQ, product lifecycle management (PLM), customer relationship management (CRM) or ecommerce architecture.

    What is a CPQ configurator?

    A CPQ configurator is the configuration component of CPQ software. CPQ stands for Configure, Price, Quote. It combines product configuration with commercial logic so that a valid product selection can become an accurate price and customer quote.

    In a manufacturing environment, a CPQ configurator may perform the following sequence:

    1. Collect customer and application requirements.
    2. Guide the user through valid product options.
    3. Apply configuration rules and engineering constraints.
    4. Calculate dimensions, capacity, performance or other technical values.
    5. Determine the configured product structure.
    6. Calculate material, component, labor, freight or other costs where supported.
    7. Apply list prices, discounts, surcharges, regional pricing and margin rules.
    8. Generate a quotation with technical specifications and commercial terms.
    9. Create a configurable or product-specific BOM and send relevant data to ERP, PLM, CRM, CAD or manufacturing systems where integrations exist.

    Not every CPQ product performs every step. Some systems focus on guided selling, pricing and proposals. Others extend into engineering automation, CAD generation and production data. Buyers should verify the actual scope of a platform rather than assuming that the word CPQ means it creates manufacturing-ready outputs.

    CPQ configurator vs product configurator: key differences

    Dimension Product configurator CPQ configurator
    Primary purpose Select and validate a product configuration Configure a product, calculate its commercial result and generate a quote
    Main users Customers, dealers, salespeople, engineers or product selectors Sales, sales engineering, application engineering, commercial operations and sometimes customers or dealers
    Core rules Options, dependencies, exclusions and technical constraints Configuration rules plus pricing, discount, approval and quoting rules
    Output Validated configuration, product summary or visual representation Price, quote, technical specification and potentially BOM, CAD or order data
    Pricing Optional; may show no price or a simple price Central capability, including prices, discounts, surcharges and margins
    Engineering data May use technical rules and calculations May connect configuration to calculations, CAD automation and engineering workflows
    Manufacturing integration Usually optional and dependent on the product Often designed to exchange data with ERP, PLM, CRM, CAD or manufacturing systems, although depth varies
    Commercial approvals Usually outside the main scope May include discount, margin, exception and approval workflows

    The boundary is not absolute. A sophisticated product configurator can include pricing, while a CPQ platform may provide only limited engineering or manufacturing functionality. The useful question is not what label a vendor uses, but which inputs, rules and outputs the implementation supports.

    Where the two concepts overlap

    Both systems normally contain a product model. A product model describes the features, options, components, parameters and relationships that define a product family.

    Both may support:

    • feature and option selection;
    • mandatory and optional components;
    • dependencies and exclusions;
    • compatibility rules;
    • dimension and capacity limits;
    • configuration validation;
    • guided questions for nontechnical users;
    • technical specifications or a configuration summary;
    • visualization of the selected product.

    The difference is what happens after a valid configuration is found. A product configurator may stop at the validated selection. A CPQ configurator generally passes that result into pricing and quoting services and may continue into order, engineering or production processes.

    How configuration rules differ from pricing rules

    Configuration rules answer: Can this product be built or sold in this combination? Pricing rules answer: What should this valid combination cost or sell for?

    Configuration rules

    Configuration rules describe product logic. Examples include:

    • A 15 kW motor requires a larger frame than a 7.5 kW motor.
    • A high-temperature seal is required when the operating temperature exceeds a defined threshold.
    • A particular valve body material is unavailable with a selected pressure class.
    • A truck body length requires a compatible chassis wheelbase.
    • An electrical enclosure must meet a specified ingress-protection rating for an outdoor application.

    These rules protect technical validity, safety, manufacturability and serviceability. They may be implemented as simple if-then rules, compatibility matrices, calculations or constraint-solving logic.

    Pricing rules

    Pricing rules convert the valid configuration into a commercial result. Examples include:

    • adding the price of a stainless-steel casing;
    • applying a regional price list;
    • calculating a surcharge for a special coating;
    • applying a dealer discount within an approved range;
    • requiring approval when a quote falls below a target margin;
    • calculating freight based on weight, dimensions or destination.

    A product configurator can contain the first group without containing the second. A CPQ configurator is expected to connect both groups, although the sophistication of the pricing engine varies by product and implementation.

    Manufacturing example: configuring an industrial pump

    Consider a manufacturer selling centrifugal pumps for water treatment and industrial process applications.

    A basic product configurator might guide a user through pump family, flow range, pressure, impeller size, motor, material and connection options. It would reject an invalid combination, such as a motor that cannot deliver the required duty point or a pressure class that is incompatible with the selected casing.

    A CPQ configurator would use the same product logic but add commercial and operational outputs:

    1. The user enters the required flow, pressure, fluid temperature and material requirements.
    2. An engineering calculation identifies a suitable pump family and motor range.
    3. The rules engine filters incompatible impellers, seals, materials and accessories.
    4. The system selects or derives components for the configured assembly.
    5. The pricing engine calculates the equipment price, options, services and freight assumptions.
    6. The quote includes a technical description, performance information, exclusions, delivery assumptions and commercial terms.
    7. A configurable BOM or engineering BOM (EBOM) may be generated for review.
    8. After order acceptance, the configuration may be transferred to an enterprise resource planning (ERP) system or product lifecycle management (PLM) system for order processing and engineering control.

    If the pump requires a new casing design, a nonstandard seal arrangement or a customer-specific mounting interface, the transaction may become engineer-to-order (ETO). In that case, the CPQ configurator can capture requirements and create a controlled engineering request, but it may not be able to complete the design automatically.

    How a CPQ configurator fits into the manufacturing architecture

    A CPQ configurator is usually an application layer between product and commercial data and the systems that manage customers, products and operations.

    Product and engineering data

    Product data may originate in PLM or product data management (PDM) systems, engineering databases, ERP item masters, CAD models or maintained CPQ product models. PLM manages product information and lifecycle processes; PDM generally focuses more narrowly on engineering files, revisions and relationships.

    The CPQ model must represent sellable options and rules at a level that sales and engineering can maintain. It may not be a direct copy of the engineering structure. A customer-facing option such as “corrosion-resistant package” may map to several engineering components, documents and operations.

    CRM and sales channels

    Customer relationship management (CRM) systems manage accounts, opportunities and customer interactions. A CPQ configurator may be launched from CRM or embedded in a sales process. The configuration should be associated with the opportunity, customer, salesperson, dealer or project.

    ERP and production systems

    Enterprise resource planning (ERP) systems manage transactions such as orders, inventory, purchasing, manufacturing and financial records. A CPQ configurator may send a quote or order with item identifiers, quantities, prices, configuration attributes and BOM data to ERP.

    A manufacturing BOM, or MBOM, represents how a product is assembled or produced. It may differ from an EBOM, which represents the engineering design structure. A CPQ implementation must define whether it creates an EBOM, an MBOM, a configurable BOM, or only a commercial list of selected components.

    CAD and automation

    Computer-aided design (CAD) automation can use configuration parameters to generate a product-specific model, drawing or document. This is more advanced than displaying a product image. It requires stable parametric models, controlled templates, mapping between configuration attributes and CAD parameters, and a process for handling exceptions.

    Some CPQ configurators have CAD automation capabilities; others integrate with separate engineering automation tools; many do not generate CAD at all. This distinction is important when evaluating a platform for machinery or ETO products.

    Types of product configuration inside CPQ

    Rules-based configuration

    Rules-based configuration uses explicit logic such as if-then statements, option dependencies, exclusions and formulas. It works well when product logic is known and can be maintained as business rules.

    Constraint-based configuration

    Constraint-based configuration represents permitted relationships and lets a solver find or validate combinations that satisfy multiple constraints. This can be useful for products with many interacting dimensions, capacities, materials and performance requirements.

    Guided selling

    Guided selling asks questions in business or application language and recommends suitable product options. It is useful when a dealer or salesperson understands the customer problem but not every technical attribute. Guided selling should not be confused with a complete engineering configurator: recommendations still need to be checked against authoritative product rules.

    A manufacturing CPQ implementation may use all three approaches. Guided questions capture requirements, a rules engine validates the selection and calculations determine technical values. The resulting configuration then drives price and downstream outputs.

    When a product configurator may be enough

    A standalone product configurator may be appropriate when the main requirement is product selection rather than transaction automation. Examples include:

    • helping customers select a standard motor or pump variant;
    • showing compatible accessories for an existing product;
    • providing a dealer-facing technical selection tool;
    • displaying a visual configuration for a modular vehicle;
    • validating options before a salesperson enters an order elsewhere;
    • supporting engineering or service teams with product selection.

    It may also be suitable when pricing is fixed and managed in another system, or when the company wants to separate configuration logic from commercial quoting.

    When a CPQ configurator is more appropriate

    A CPQ configurator is usually more suitable when configuration and commercial decisions are tightly connected. Typical indicators include:

    • salespeople currently calculate prices manually in spreadsheets;
    • different teams use different product and discount rules;
    • quotes contain invalid options or omit required components;
    • engineering reviews a large number of routine configurations;
    • configured options affect cost, margin, delivery or freight;
    • the company needs formal quote approvals;
    • dealers need controlled pricing and configuration access;
    • the quote must include technical specifications and a consistent BOM;
    • the configuration must be transferred to CRM, ERP, PLM, CAD or manufacturing systems.

    The business case is strongest when errors or delays occur at the boundary between sales, engineering and production. A CPQ configurator can encode repeatable product logic so that routine configurations do not require the same manual intervention as genuinely novel designs.

    Important limitations and risks

    Neither term guarantees a particular technical capability. A system called a CPQ configurator may provide only basic option selection and pricing. A product configurator may support complex engineering constraints but have no quote workflow.

    Manufacturers should examine the following limitations:

    • Product model complexity: large rule sets can become difficult to understand, test and change.
    • Data ownership: product, price, cost and engineering data may be maintained in different systems with conflicting revisions.
    • Rule maintenance: rules must change when components, suppliers, standards, designs and manufacturing methods change.
    • Exception handling: unusual customer requirements may require ETO processes rather than forced configuration.
    • BOM semantics: a commercial configuration does not automatically equal an engineering or manufacturing BOM.
    • Integration boundaries: sending data to ERP or PLM requires agreed identifiers, revisions, units, statuses and error handling.
    • CAD automation effort: automated drawings and models need controlled templates and engineering governance.
    • Pricing governance: discounts, cost updates, currencies and regional price lists require ownership and release control.
    • User experience: a technically correct configurator can still fail if questions are unclear or require engineering knowledge that salespeople do not have.

    Implementation considerations for manufacturers

    Define the required output first

    Start by documenting what the configuration must produce. Possible outputs include a validated product selection, technical specification, price, quote, EBOM, MBOM, CAD model, drawing, work request, sales order or production package. Do not treat these outputs as equivalent.

    Choose the right product scope

    Begin with a product family where rules are reasonably stable and quoting effort is measurable. A focused pump, valve, enclosure or machine module may be a better starting point than the entire portfolio.

    Separate configuration, pricing and engineering logic

    These forms of logic interact but have different owners. Product management may own commercial options, engineering may own technical constraints, finance may govern margin rules and manufacturing may own assembly structures. The implementation should make these responsibilities visible rather than placing all logic in unstructured code.

    Establish source-system responsibilities

    Decide which system is authoritative for each data type:

    • product revisions and engineering documents in PLM or PDM;
    • items, inventory and order transactions in ERP;
    • customer and opportunity data in CRM;
    • pricing and discount policies in CPQ or an approved commercial system;
    • CAD templates and parameters in the engineering environment.

    In some businesses, CPQ becomes the operational source for the sellable product model while PLM remains the source for engineering-controlled data. That arrangement can work, but the synchronization and approval process must be explicit.

    Test combinations and revisions

    Testing should include valid and invalid combinations, boundary dimensions, obsolete components, regional pricing, discounts, units of measure, revision changes and integration failures. Manufacturers should also test whether an old quote remains reproducible after product or price rules change.

    Plan for CTO, MTO and ETO

    Configure-to-order (CTO) uses predefined options and standard modules. Make-to-order (MTO) produces an item after the order but may use a relatively stable design. Assemble-to-order (ATO) combines stocked modules after the order. Engineer-to-order (ETO) requires new or substantially modified engineering work.

    A CPQ configurator is often most predictable for CTO and some MTO or ATO scenarios. It can support ETO by capturing requirements, estimating commercial impact and initiating engineering work, but it should not pretend that every ETO design can be reduced to a fixed option list.

    Questions to ask when evaluating a CPQ configurator

    • Can it represent dimensions, formulas, capacities and engineering constraints?
    • Can non-developers maintain product rules safely?
    • How are configuration rules tested and versioned?
    • Can the system distinguish a sellable option from its underlying components?
    • Does it calculate cost, price, margin, freight and lead-time effects?
    • What exactly does “BOM generation” mean in the product documentation?
    • Can it produce an EBOM, MBOM, configurable BOM or only a quote line list?
    • Does it integrate with the company’s ERP, CRM, PLM, PDM and CAD systems?
    • Can it create a controlled engineering request for exceptions?
    • How are product, price and engineering revisions handled?
    • Can dealers or distributors access a restricted product model and price list?
    • Are APIs available for ecommerce, portals or custom applications?
    • Can the implementation support multiple plants, regions, currencies and units?
    • How are approvals and overrides recorded?
    • What skills are required to maintain the model after go-live?

    Conclusion

    A product configurator is primarily concerned with selecting and validating a product. A CPQ configurator includes that capability but extends it into price calculation and quote creation. In manufacturing, the distinction becomes more significant because a configured product may also need technical calculations, a BOM, CAD outputs, engineering review and integration with ERP or PLM.

    There is no universal boundary between the two categories. Some product configurators include commercial features, and some CPQ systems provide only limited manufacturing automation. The correct evaluation method is to map the required product rules, pricing logic, engineering outputs and system handoffs, then verify which capabilities are native, integrated or absent.

    For a broader explanation of manufacturing CPQ architecture and use cases, see the manufacturing CPQ guide. Related topics include product configuration and rules engines, CAD and engineering automation, BOM generation, pricing and quoting and CPQ integrations.

    Frequently asked questions

    Is a CPQ configurator the same as a product configurator?

    No. A CPQ configurator includes product configuration but also connects the result to pricing and quoting. A product configurator may stop after validating the selected product.

    Can a product configurator calculate prices?

    Some can. Pricing is an optional capability in a product configurator, while it is a central part of the CPQ model. Buyers should verify whether pricing supports discounts, surcharges, currencies, costs and margin rules.

    Does every CPQ configurator generate a BOM?

    No. BOM generation varies considerably. Some systems create a configurable BOM or quote component list, while others can produce an engineering or manufacturing BOM through an integration.

    What is the main benefit of a CPQ configurator for manufacturers?

    It connects a valid product configuration with an accurate commercial result and, where supported, structured engineering or production data. This reduces manual translation between sales, engineering and operations.

    Can a product configurator support complex machinery?

    Yes, if it supports the required rules, calculations and data structures. A simple option selector may be insufficient for machinery with interacting dimensions, performance requirements and component constraints.

    What is guided selling?

    Guided selling asks business-oriented questions and recommends suitable products or options. It can make a technical product configurator easier for salespeople and customers, but recommendations still need authoritative validation rules.

    What is the difference between configuration rules and pricing rules?

    Configuration rules determine whether a combination is technically or commercially valid. Pricing rules determine what that valid combination costs or should be sold for.

    Can a CPQ configurator replace engineering?

    Usually not. It can automate repeatable engineering decisions and route exceptions, but novel designs, safety reviews and nonstandard requirements may still require engineers.

    Is CAD automation included in every CPQ configurator?

    No. CAD automation is an advanced capability that may be native, delivered through a separate tool or unavailable. It requires parametric CAD models, templates, mappings and engineering governance.

    Can a CPQ configurator support engineer-to-order products?

    It can support parts of an ETO process, such as requirements capture, preliminary pricing and engineering-work requests. It may not automatically design every custom product.

    What systems does a CPQ configurator connect to?

    Depending on the implementation, it may connect to CRM, ERP, PLM, PDM, CAD, product information management (PIM), manufacturing execution systems (MES) and ecommerce channels. The specific integration depth must be verified.

    Should product rules be stored in ERP or CPQ?

    There is no universal answer. ERP is normally authoritative for transactions and inventory, while CPQ often manages the sellable configuration model. Responsibilities and synchronization should be defined during architecture design.

    What is an EBOM?

    An EBOM, or engineering bill of material, describes the product from an engineering design perspective. It may differ from an MBOM, which describes how the product is assembled or manufactured.

    What is a configurable BOM?

    A configurable BOM is a structure containing possible components and selection logic. A particular configuration resolves that structure into the components required for the selected product.

    When is a standalone product configurator preferable?

    It may be preferable when the main need is technical selection, compatibility validation or visualization, and pricing and order processing remain in another system.

    When should a manufacturer choose CPQ instead?

    CPQ is more appropriate when configuration directly affects price, margin, quote approvals, technical documents, BOMs, order data or the handoff from sales to engineering and production.

    Semantic map

    Entity Relationship Related entity
    CPQ configurator configures and prices configurable product
    Product configurator validates product options and combinations
    Configuration rules prevent invalid product combinations
    Pricing rules calculate price, discount and margin
    Configured product can generate configuration summary or BOM
    EBOM represents engineering product structure
    MBOM represents manufacturing assembly structure
    CPQ exchanges commercial data with ERP and CRM
    CPQ may consume engineering data from PLM, PDM and CAD
    CAD automation generates configuration-specific models and drawings
    CTO uses predefined product options and modules
    ETO requires engineering work for nonstandard requirements
    Guided selling translates customer requirements into product recommendations