CPQ Guide

Category: Guide

  • Price Books and Product Configuration in Manufacturing CPQ

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

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

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

    What is a price book in manufacturing CPQ?

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

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

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

    How product configuration and price books work together

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

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

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

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

    Price book architecture for configurable products

    Base product prices

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

    Option and component prices

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

    Formula-based pricing

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

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

    Customer, channel and market price books

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

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

    Effective dates and version control

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

    Pricing, costing and margins

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

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

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

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

    How configuration affects BOM generation and quoting

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

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

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

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

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

    Read more about BOM generation, costing, pricing and quote automation.

    Rules that connect configuration to price

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

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

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

    Illustrative example: pricing a configurable industrial pump

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

    The configuration model may enforce the following:

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

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

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

    Quote documents and commercial transparency

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

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

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

    Integration with ERP, CRM, PLM, PDM and CAD

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

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

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

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

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

    Manufacturing workflows: CTO, ETO, MTO and ATO

    Price-book design depends partly on the manufacturing strategy.

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

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

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

    Benefits of integrating price books with configuration

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

    Limitations and implementation risks

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

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

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

    Implementation approach

    1. Define the commercial and engineering scope

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

    2. Map product and price data

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

    3. Separate rule categories

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

    4. Establish systems of record

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

    5. Model the BOM and quote views

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

    6. Test combinations and commercial scenarios

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

    7. Govern releases

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

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

    How to evaluate a CPQ configurator for price-book use

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

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

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

    Semantic map

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

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

    Frequently asked questions

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

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

    Can a price book contain configuration rules?

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

    Does every CPQ system generate a BOM?

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

    How does configuration affect product pricing?

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

    Can one product have multiple price books?

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

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

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

    How are dimensions used in a manufacturing price book?

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

    How are discounts applied to configured products?

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

    What happens when a configuration requires engineering work?

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

    Can CPQ price a configurable BOM?

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

    How do EBOM and MBOM affect CPQ pricing?

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

    Can price books include freight and installation?

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

    How should price-book revisions be controlled?

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

    What is a price override in manufacturing CPQ?

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

    Can a CRM own the manufacturing price book?

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

    How does CAD automation relate to price books?

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

    What should manufacturers test before launching a price book?

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

  • Lead-Time Calculation During Product Configuration

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

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

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

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

    Why lead time belongs in manufacturing CPQ

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

    During configuration, the system may identify:

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

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

    What data is required for lead-time calculation?

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

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

    How the calculation works

    1. Validate the configuration

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

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

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

    2. Generate or resolve the configured BOM

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

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

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

    3. Check inventory and procurement

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

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

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

    4. Add engineering and design effort

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

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

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

    5. Calculate manufacturing operations

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

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

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

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

    6. Apply dependencies and calendars

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

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

    7. Add inspection, approval and logistics time

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

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

    Example: configuring an industrial pump

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

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

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

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

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

    Lead time across CTO, MTO, ATO and ETO

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

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

    Integration architecture

    A practical architecture assigns ownership to the appropriate system:

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

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

    Lead-time limitations and risks

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

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

    Implementation recommendations

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

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

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

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

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

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

    Semantic map

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

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

    FAQ

    What is lead-time calculation in CPQ?

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

    Why is a fixed product lead time often inaccurate?

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

    Does every CPQ system calculate manufacturing lead time?

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

    What is the difference between quoted and committed lead time?

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

    Can CPQ calculate lead time without ERP integration?

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

    How does a BOM affect lead time?

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

    Is an EBOM the same as an MBOM?

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

    How do configuration rules affect delivery dates?

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

    What is the critical path in a configured product?

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

    Can lead time and price be calculated together?

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

    How is ETO lead time different from CTO lead time?

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

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

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

    How are supplier lead times used?

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

    Does CAD automation reduce lead time?

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

    How should customer approvals be included?

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

    What happens when inventory data is stale?

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

    Can CPQ calculate finite production capacity?

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

    Which teams own lead-time rules?

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

  • How Pricing Engines Work in Manufacturing CPQ

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

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

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

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

    What a manufacturing CPQ pricing engine does

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

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

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

    Where pricing fits in the manufacturing CPQ workflow

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

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

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

    Core data used by a pricing engine

    Product and option data

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

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

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

    Price lists and price components

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

    Price components may be additive, substitutive or conditional:

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

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

    Cost data

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

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

    Customer and commercial data

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

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

    Common pricing methods in manufacturing CPQ

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

    How rules and formulas affect price

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

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

    if material = stainless steel and pressure_class = high:

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

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

    Costing, margin and selling price

    Manufacturing CPQ should distinguish at least three concepts:

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

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

    A practical pricing calculation may be:

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

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

    Relationship between pricing and BOM generation

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

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

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

    Read more about configurable BOMs, EBOMs, MBOMs and quote generation.

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

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

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

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

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

    Approvals and pricing governance

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

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

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

    Integration architecture

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

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

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

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

    Pricing and CAD or engineering automation

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

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

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

    Benefits of a manufacturing pricing engine

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

    Limitations and common failure modes

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

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

    Other risks include:

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

    Implementation considerations

    Define calculation ownership

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

    Model the product before the price

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

    Establish a pricing hierarchy

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

    Test representative scenarios

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

    Govern changes and releases

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

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

    How to evaluate a manufacturing CPQ pricing engine

    When comparing CPQ software, ask vendors and implementation teams:

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

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

    Semantic map

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

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

    Frequently asked questions

    1. What is a pricing engine in manufacturing CPQ?

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

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

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

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

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

    4. How does a CPQ system price configurable options?

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

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

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

    6. Can manufacturing CPQ calculate margin?

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

    7. Does pricing depend on the BOM?

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

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

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

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

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

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

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

    11. How are discounts controlled in manufacturing CPQ?

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

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

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

    13. Can pricing engines support multiple currencies?

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

    14. How does formula pricing work for manufactured products?

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

    15. Does every manufacturing CPQ platform include costing?

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

    16. Can CPQ price ETO products?

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

    17. How does CAD automation affect pricing?

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

    18. How should pricing rules be maintained?

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

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

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

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

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

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

  • Cost Rollups for Configurable Products

    Cost rollups for configurable products calculate the estimated cost of producing a specific product configuration. In a manufacturing Configure, Price, Quote (CPQ) process, the rollup normally starts with a validated configuration, resolves the required components and operations, applies material, labor, subcontracting and overhead costs, and returns a cost basis for pricing, margin analysis and quote approval.

    This is different from simply adding a few option prices to a base product. A configured industrial pump, machine enclosure, conveyor or specialty vehicle may change its bill of materials (BOM), manufacturing route, engineering effort, purchased components, labor content and lead time. A reliable cost rollup must reflect those changes and preserve a traceable connection between the customer selections, the product model, the resulting BOM and the quoted price.

    Cost rollups are therefore one of the points where product configuration, engineering, costing, pricing and quoting meet. Some CPQ platforms calculate costs natively. Others obtain costs from an enterprise resource planning (ERP) system, product lifecycle management (PLM) system, costing service or custom integration. Buyers should verify the actual data flow rather than assume that every CPQ configurator provides manufacturing-grade costing.

    What is a cost rollup?

    A cost rollup is a calculation that aggregates the costs of all materials, components, labor activities, subcontracted operations and applicable overhead required to produce a product or configured assembly. The result may be called standard cost, estimated cost, rolled-up cost, manufacturing cost or configuration cost, depending on the organization.

    For a configurable product, the calculation is performed against the selected configuration rather than only against a generic product number. The rollup may include:

    • raw materials such as steel plate, aluminum, copper, plastics or rubber;
    • purchased components such as motors, pumps, valves, drives, sensors and fasteners;
    • subassemblies selected by configuration rules;
    • labor operations such as cutting, welding, machining, painting, assembly and testing;
    • machine time and work-center rates;
    • outside processing and subcontracting;
    • engineering or design effort for engineered-to-order work;
    • packaging, freight allowances or installation-related costs when included in the commercial model;
    • scrap, yield, waste and material utilization factors; and
    • manufacturing overhead or other cost allocations.

    A simple conceptual formula is:

    Total configured cost = material cost + purchased component cost + labor cost + machine cost + subcontracting cost + engineering cost + allocated overhead + other applicable costs

    The exact formula depends on the company’s costing policy. A quote may use a standard cost for financial consistency, a current purchase cost for procurement accuracy, an estimated job cost for engineer-to-order work, or several parallel cost views for different business purposes.

    Why configurable products require more than option pricing

    In generic sales CPQ, an option may add a fixed amount to a base price. Manufacturing CPQ often needs to determine what the option physically changes. Selecting a larger motor for a pump skid can change the motor cost, coupling, base frame, electrical protection, enclosure size, cable requirements and assembly time. Selecting a higher-pressure valve may change the valve body material, actuator, testing requirements and certification documentation.

    These effects can be represented through a configurable BOM, rule-driven component selection, formulas, engineering calculations or integrations with CAD and ERP systems. A cost rollup is reliable only when the product model captures the relevant dependencies.

    Commercial option Potential manufacturing effect Cost data required
    Higher pump flow rate Larger pump, motor, coupling, base and possibly piping Component costs, sizing rules, assembly labor and test cost
    Stainless steel wetted parts Different castings, seals, fasteners and fabrication processes Material-specific prices, supplier parts and routing changes
    Custom enclosure dimensions Changed sheet-metal blank, machining, coating and assembly effort Dimension formulas, material utilization and work-center rates
    Outdoor installation package Weather protection, heater, gland plates and additional testing Option components, labor standards and compliance costs

    How a manufacturing CPQ cost rollup works

    1. The customer or sales engineer creates a configuration

    The process begins with selections such as capacity, dimensions, material, voltage, motor type, operating environment, accessories and delivery requirements. A rules engine validates the selections. Depending on the product model, the system may use rules-based configuration, constraint-based configuration, guided selling or a combination of these methods.

    Rules-based configuration uses explicit conditions such as “if voltage is 480 V, select this starter family.” Constraint-based configuration evaluates relationships and limits, such as a maximum shaft load, pressure rating or dimensional envelope. Guided selling asks questions that lead a user toward suitable choices; it may simplify the experience but does not by itself guarantee engineering validity.

    The configuration must be valid before costs are rolled up. Otherwise the system may calculate a price for an impossible or incomplete product.

    2. The product model resolves components and operations

    The CPQ system translates the selected features into a product structure. This may be a configurable BOM, a modular BOM, a rules-based component list or a set of inputs for an external engineering system.

    A configurable BOM contains alternative or conditional components that become active when particular selections, dimensions or calculations apply. For example, a pump package may include:

    • one pump family selected by flow and pressure;
    • one motor selected by power, voltage and efficiency requirements;
    • a coupling selected by motor and shaft size;
    • a base frame selected by pump and motor dimensions;
    • different valves selected by material and pressure class;
    • instrumentation selected by the control package; and
    • installation hardware selected by mounting and environmental conditions.

    The product model may also resolve quantities. A cable tray quantity might depend on enclosure width, while the amount of sheet material may depend on surface area and an allowance for scrap.

    3. Engineering calculations determine variable values

    Some costs cannot be obtained from a static option table. They depend on calculations. Examples include sheet-metal weight, cable length, frame length, insulation area, structural steel mass, number of fasteners, paint quantity or the capacity of a selected heat exchanger.

    A CPQ platform may perform these calculations internally, call an engineering service or exchange parameters with computer-aided design (CAD) and product data systems. CAD automation may generate a product-specific model or drawing, while the cost model uses calculated dimensions and materials. More information about this relationship is available in the guide to CAD and engineering automation.

    4. Each item receives a cost

    The system then obtains or calculates a cost for each resolved BOM line and operation. Cost sources may include:

    • material master records;
    • supplier or purchase prices;
    • inventory or standard costs;
    • manufacturing work-center rates;
    • labor standards;
    • routing operations;
    • outside-processing rates;
    • engineering estimates; and
    • manually maintained cost assumptions.

    Costs may be held in the CPQ product model, retrieved from an ERP system, supplied by a costing database or calculated by a specialized service. Maintaining duplicate cost data in several systems creates a governance risk, particularly when supplier prices, currencies or manufacturing rates change.

    5. The system aggregates costs through the product structure

    Leaf-level component and operation costs are aggregated through subassemblies and parent assemblies. A subassembly may have its own material, labor and overhead cost before becoming a line in the finished product structure.

    For example, a conveyor may contain a drive package. The drive package cost includes the gearbox, motor, coupling, guard, mounting plate and assembly labor. The conveyor rollup then adds the drive package to the frame, belting, controls, guarding, supports and testing operations.

    The result should normally retain detail rather than return only one total. Cost detail supports margin analysis, approval decisions, variance investigation and later comparison with actual production results.

    6. Pricing and margins are applied separately

    Cost is not the same as price. Cost represents the organization’s estimated expenditure or resource consumption. Price is the amount offered to the customer after applying margin, markup, commercial adjustments, freight policy, discounts, currency rules, taxes and other pricing logic.

    A manufacturing CPQ system may calculate:

    • material and manufacturing cost;
    • engineering or non-recurring cost;
    • target margin;
    • list price and customer-specific price;
    • discount limits;
    • minimum margin thresholds; and
    • approval requirements.

    For example, an engineered enclosure may have a rolled-up manufacturing cost of 18,000 monetary units. The commercial price may be based on a target gross margin, a project discount and a separate engineering charge. Treating the entire amount as a simple percentage markup can hide important differences between recurring product cost and one-time engineering work.

    7. The quote and approval process use the result

    The cost rollup feeds the quote document, margin analysis and approval workflow. A quote may show only customer-facing prices, while internal users see detailed costs and margins. If a configured product falls below a margin threshold, the CPQ system may require sales management, finance or engineering approval.

    The approved configuration and commercial result can then be passed to order management and downstream systems. The exact handoff depends on whether the product is configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO) or engineer-to-order (ETO).

    Cost rollups and BOM types

    BOM terminology matters because different BOM structures serve different purposes.

    BOM type Purpose Role in cost rollups
    Configurable BOM Represents alternatives, conditions and variable quantities before a specific configuration is finalized Provides the rules and structure from which the configured cost is resolved
    Engineering BOM (EBOM) Represents the product from an engineering and design perspective May provide design components, materials and engineering attributes
    Manufacturing BOM (MBOM) Represents how the product is assembled and produced Supports labor, routing, work-center and manufacturing-cost calculations
    Configured or order BOM Represents the specific product selected for an order or quote Provides the concrete component list for costing, production and fulfillment

    EBOM and MBOM are not interchangeable. An engineering structure may contain design groupings that do not correspond to shop-floor operations. Conversely, an MBOM may include consumables, fixtures, packaging or intermediate assemblies that are not represented in the EBOM. A CPQ implementation must define which structure is authoritative for each cost element and how structures are transformed or synchronized.

    The guide to BOM generation, pricing and quote automation provides broader context on these relationships.

    Data required for a reliable cost rollup

    A cost rollup depends on more than a price list. Typical data requirements include:

    Product and configuration data

    • features, options and allowed values;
    • compatibility rules and constraints;
    • component selection logic;
    • quantity formulas;
    • dimension and performance calculations;
    • revision and effectivity dates; and
    • configuration status and validation results.

    Cost and sourcing data

    • material grades, weights and units of measure;
    • supplier, purchase and subcontracting costs;
    • currency and conversion rules;
    • minimum order quantities and lot-size effects;
    • scrap, yield and waste factors;
    • labor rates and machine rates;
    • routing operations and setup times; and
    • overhead allocation policies.

    Commercial data

    • price lists and customer agreements;
    • discount and surcharge rules;
    • freight and installation policies;
    • target margins;
    • approval thresholds; and
    • tax and currency requirements.

    Data ownership should be explicit. ERP may own item, supplier and standard-cost records. PLM may own engineering revisions and product structures. A product data management (PDM) system may control CAD files and design metadata. A CPQ system may own the selling model and configuration rules. A product information management (PIM) system may manage descriptions and channel content. These systems should not be treated as interchangeable.

    Integration architecture

    There are several common architecture patterns for cost rollups.

    CPQ-owned costing

    The CPQ platform stores the relevant component costs, formulas and rates. This can provide fast response during configuration, but it requires disciplined synchronization and governance. It may be suitable for a focused product line or when the CPQ platform has sufficiently deep costing capabilities.

    ERP-sourced costing

    The CPQ system resolves the configuration and sends item identifiers, quantities, dimensions or a temporary structure to the ERP. The ERP returns standard, average, planned or estimated costs. This reduces duplicate cost ownership but may require real-time interfaces, temporary items or a method for representing configurable structures.

    External costing service

    A dedicated costing service calculates material utilization, process costs or engineered estimates. CPQ supplies configuration parameters and receives cost lines or totals. This approach can support complex formulas but adds another system, interface and testing responsibility.

    PLM, PDM and CAD participation

    PLM manages product lifecycle information and revisions. PDM manages design files and related product data. CAD creates or modifies geometry. These systems may contribute dimensions, materials, revisions or manufacturing attributes, but they do not automatically provide a complete commercial cost rollup. The integration must define which system owns each value and when the data becomes effective.

    Enterprise integration should also account for customer relationship management (CRM), manufacturing execution systems (MES) and ecommerce or dealer channels. CRM may provide the opportunity and customer context. MES may consume production instructions or report actuals. Ecommerce may expose a simplified configuration experience. Details on these connections are covered in CPQ integration architecture.

    Worked example: configurable industrial pump package

    Consider a centrifugal pump package configured with the following selections:

    • capacity and pressure duty;
    • carbon-steel base frame;
    • stainless-steel wetted components;
    • 75 kilowatt motor;
    • 460-volt electrical package;
    • variable-frequency drive;
    • outdoor enclosure;
    • pressure and temperature instrumentation; and
    • factory performance testing.

    The configuration rules first validate that the selected pump, motor, drive and base are compatible. Engineering calculations determine the required motor rating, coupling size, base dimensions and approximate cable length. The configured BOM then includes the selected pump, motor, drive, enclosure, valves, instruments, fasteners and fabricated frame.

    The cost rollup may contain:

    Cost group Example contents
    Purchased components Pump, motor, drive, valves, sensors and enclosure hardware
    Fabricated materials Steel plate, profiles, stainless fittings and cable supports
    Labor Fabrication, welding, painting, electrical assembly and mechanical assembly
    Testing Performance test, electrical checks and documentation
    Engineering Configuration review, drawing updates and application engineering
    Overhead Applicable work-center or factory overhead allocation

    If the customer changes the motor to a higher rating, the system should not merely add the motor price. It may need to select a larger coupling and base, update the drive, increase cable size, change the enclosure and add assembly labor. The quote should show the commercial impact of the change, while internal users should be able to trace it to the affected cost lines.

    Cost rollups across CTO, ETO, MTO and ATO

    Manufacturing strategy affects the appropriate cost model.

    • Configure-to-order (CTO): the product is selected from a controlled model, and standard components and routings can usually be rolled up automatically.
    • Assemble-to-order (ATO): standard modules are assembled after the order. The rollup must account for module costs and final assembly labor.
    • Make-to-order (MTO): production begins after the order, often using a standard product with order-specific planning. Material availability, batch size and production labor may affect the estimate.
    • Engineer-to-order (ETO): the configuration requires new engineering, custom geometry or project-specific validation. The rollup may need engineering hours, design risk allowances, prototype work and provisional costs.

    ETO costing is particularly difficult because the final design may not yet exist. A CPQ system can estimate based on parametric rules, historical templates or engineering estimates, but the result should be labeled as an estimate and governed through approval and revision processes.

    These distinctions are important in the broader configure-to-order and engineer-to-order workflow.

    Benefits of cost rollups in manufacturing CPQ

    • More accurate margin analysis: the commercial team can evaluate margin against the actual configured product rather than a generic base item.
    • Faster quote decisions: sales engineers can evaluate alternatives without requesting a manual costing exercise for every variation.
    • Better engineering handoff: the configuration, cost assumptions and selected components remain connected.
    • Improved approval control: exception workflows can identify low-margin configurations, unusual materials or excessive discounts.
    • More consistent pricing: repeatable formulas reduce spreadsheet variation between sales regions or estimators.
    • Better production planning: a resolved structure can support downstream ordering, planning and manufacturing preparation.
    • Traceability: users can identify which option, rule or cost source caused a change in the quote.

    Limitations and common failure modes

    Stale or duplicated cost data

    If CPQ stores copied supplier or ERP costs without effective dates and synchronization controls, the rollup may become inaccurate. A process is needed for updates, exceptions and failed integrations.

    Incomplete product rules

    A configuration can be syntactically valid but commercially or technically incomplete. For example, a selected motor may be compatible with the pump but require a different mounting kit that the model does not include.

    Confusing standard cost with actual cost

    Standard cost is a planning or accounting value. It may not reflect current supplier prices, expedited freight, project-specific labor or actual production variance. The quote should state which cost basis it uses.

    Uncontrolled manual overrides

    Manual cost overrides can be necessary for unusual projects, but unrestricted overrides undermine trust. The system should record who changed the value, why it changed, which approval was required and how long the override remains valid.

    Missing indirect costs

    Some rollups include only material and direct labor. Others include setup, testing, quality inspection, packaging, freight, engineering and overhead. A comparison is meaningful only when the cost definitions are consistent.

    False precision

    A cost displayed to the nearest currency unit may appear exact even when dimensions, labor content or supplier assumptions are provisional. Estimated values should include an appropriate confidence category or explanatory note.

    Weak revision control

    A quote created under one product revision should not silently recalculate under a later revision unless the business process explicitly allows it. Configuration rules, costs, CAD outputs and BOM revisions need effective-date and version controls.

    Implementation guidance

    Define the cost model before selecting technology

    Document what the organization means by material cost, conversion cost, standard cost, estimated cost, engineering cost, overhead and margin. Decide whether the quote needs one cost view or multiple views for sales, finance and manufacturing.

    Map the end-to-end data flow

    For each field, identify the source, owner, update frequency, unit, currency, revision and fallback behavior. A useful data map covers configuration inputs, resolved items, quantities, routings, rates, costs, prices, approvals and outputs.

    Start with a bounded product family

    Pilot the model on a product line with meaningful configuration complexity but manageable scope. Industrial pumps, modular electrical panels or standard machine enclosures can provide useful test cases if their rules and costing data are sufficiently understood.

    Test combinations, not just individual options

    Testing should cover valid and invalid combinations, boundary dimensions, unit conversions, currency changes, missing costs, expired prices, revision changes, alternative suppliers and manual overrides. Compare CPQ results with independently reviewed spreadsheets or ERP calculations.

    Govern rule and cost ownership

    Assign responsibility for product rules, engineering formulas, item data, rates, supplier costs, pricing policies and approval thresholds. A governance board or controlled release process may be needed when multiple departments maintain the model.

    Measure actual-versus-estimated performance

    After orders are produced, compare estimated costs with actual material usage, labor, subcontracting and other relevant costs. Variance analysis can reveal missing operations, outdated rates, incorrect quantities or overly optimistic engineering assumptions.

    Additional guidance on requirements, migration, testing, deployment and maintenance is available in the CPQ implementation guide.

    How to evaluate CPQ cost-rollup capabilities

    When comparing CPQ configurators, ask vendors to demonstrate a real manufacturing scenario rather than a simple product option list. The demonstration should show a configuration changing the BOM, a calculated dimension changing material quantity, a purchased component receiving a current cost, a routing or labor operation being added, and the resulting margin approval.

    Evaluation area Questions to ask
    Product model Can the model represent conditional components, variable quantities, revisions and effectivity dates?
    Rules and calculations Can the system express compatibility constraints, engineering formulas and dimensional limits?
    Cost sources Are costs maintained internally, retrieved from ERP or supplied by another service?
    BOM output Can the system generate a configured BOM, and can it distinguish EBOM and MBOM requirements?
    Labor and operations Can setup, run time, work-center rates, testing and subcontracting be included?
    Traceability Can users see which selection or rule produced each cost line?
    Overrides Are manual changes controlled, logged and included in approvals?
    Integration Can the platform exchange data with ERP, PLM, PDM, CAD, CRM and MES where required?
    Performance Can the system calculate complex configurations quickly enough for interactive quoting?
    Governance Are model changes tested, versioned and released without disrupting open quotes?

    Do not evaluate a platform solely by the presence of a “costing” feature. Verify whether the documented capability supports the required manufacturing data, costing method, integration pattern and level of engineering complexity. A useful starting point is the broader guide to manufacturing CPQ software.

    Semantic map

    The following relationships summarize how cost rollups connect product configuration with manufacturing and commercial processes:

    • Configuration rules resolve customer selections into valid product structures.
    • Valid product structures resolve conditional components and operations.
    • Configured BOMs provide the component and quantity basis for costing.
    • Engineering calculations provide dimensions, weights and quantities for variable-cost items.
    • ERP systems provide item, supplier, inventory or standard-cost data.
    • Manufacturing routings provide labor, machine and operation costs.
    • Cost rollups provide the cost basis for margin and pricing calculations.
    • Pricing rules convert cost and commercial policies into customer prices.
    • Approval rules govern discounts, margins and unusual cost assumptions.
    • Approved configurations support quote documents, orders and production handoffs.
    • CAD automation can generate product-specific geometry and drawings.
    • Actual production costs provide feedback for improving estimates and product models.

    Frequently asked questions

    What is a cost rollup in manufacturing CPQ?

    A cost rollup aggregates the material, component, labor, machine, subcontracting, engineering and overhead costs required to produce a specific configured product. It uses the resolved configuration and BOM rather than only a generic base-product price.

    Is a cost rollup the same as a selling price?

    No. The cost rollup estimates what the manufacturer expects to spend or consume. The selling price applies margin, markup, discounts, freight, taxes and other commercial rules.

    Can every CPQ configurator perform manufacturing cost rollups?

    No. Some CPQ systems focus on guided selling, pricing and quote generation. Others support BOMs, routings, engineering calculations and cost integrations. Capability must be verified for the specific product and data model.

    What is needed to calculate a configurable product cost?

    The main requirements are a validated product model, configuration rules, a configurable or resolved BOM, component costs, material and labor data, operation rates, formulas and defined costing policies.

    How does a configurable BOM affect cost?

    A configurable BOM contains conditional components, alternatives and variable quantities. When selections are made, the applicable lines are resolved and their costs are aggregated into the configured product cost.

    Should cost data come from CPQ or ERP?

    There is no universal answer. CPQ-owned costing can be fast and flexible, while ERP-sourced costing can reduce duplicate master data. The correct choice depends on cost ownership, response-time requirements, data complexity and integration maturity.

    Can cost rollups include labor?

    Yes, if the product model or integrated manufacturing data includes operations, labor standards, setup time, run time and work-center rates. Simple option-price tables often do not include these costs.

    How are engineering-to-order products costed?

    ETO products may use parametric estimates, historical templates, engineering-hour allowances, provisional BOMs or external costing services. Because the final design may not exist, the estimate should be identified, approved and revised as engineering progresses.

    What is the difference between EBOM and MBOM costing?

    An EBOM represents the design view of a product, while an MBOM represents how it is assembled and manufactured. MBOM costing may include routings, consumables, packaging and shop-floor operations that are absent from the EBOM.

    Can CAD automation improve cost rollup accuracy?

    It can improve accuracy when geometry, dimensions, materials or calculated quantities affect cost. However, CAD automation does not automatically provide supplier prices, labor rates or complete manufacturing costing.

    How should material waste be handled?

    Waste can be modeled through scrap rates, yield factors, nesting assumptions, cut-length rules or material-utilization formulas. The method should match the manufacturing process and be clearly distinguished from the nominal material quantity.

    How do cost rollups support quote approvals?

    The rolled-up cost provides the basis for margin and discount checks. If the configured price falls below a threshold or includes an unusual manual override, the CPQ workflow can require management, finance or engineering approval.

    What happens when a supplier price changes?

    The responsible system should update the relevant cost record according to its effective date and synchronization process. Open quotes may either retain the original snapshot or be recalculated under controlled rules.

    Should a quote store the cost used at the time of creation?

    Usually, yes. Storing a cost snapshot preserves the basis for the quoted margin and supports auditability. The system may also retain a link to the source record and revision used for the calculation.

    How can manufacturers test a cost-rollup model?

    Test valid and invalid configurations, boundary values, alternative components, missing costs, unit conversions, currency changes, revision changes, manual overrides and actual-versus-estimated outcomes.

    What is the difference between standard cost and actual cost?

    Standard cost is a planned or accounting value used consistently for analysis. Actual cost reflects what was really purchased, consumed or spent. A CPQ quote may use standard or estimated cost, but the basis should be stated.

    Can a cost rollup include freight and installation?

    It can if the commercial model requires them. Manufacturers should distinguish product manufacturing cost from logistics, installation and service charges so that margin analysis remains understandable.

    What should a vendor demonstration include?

    Ask the vendor to configure a product where selections change components, quantities, materials, labor or engineering effort. The demonstration should show the source of each cost, BOM output, margin calculation, approval workflow and integration behavior.

    How often should cost-rollup rules be reviewed?

    Review frequency depends on supplier volatility, product-change frequency and manufacturing practice. In addition to scheduled reviews, changes to items, rates, routings, revisions and pricing policies should trigger controlled updates.

  • CPQ Quote Templates for Technical Products

    CPQ quote templates for technical products are controlled document layouts that assemble configuration, pricing, costing, product details, delivery information, terms and technical outputs into a customer quotation. In manufacturing, the template is not simply a branded PDF. It is the presentation layer of a larger process connecting product configuration, rules, engineering calculations, bill of materials (BOM) data, approvals and enterprise systems.

    A manufacturing Configure, Price, Quote (CPQ) system may use a quote template to convert a valid configuration of an industrial pump, machine, electrical panel, vehicle or engineered assembly into a consistent commercial document. Depending on the platform and implementation, the same transaction may also generate a configurable BOM, an engineering review request, a computer-aided design (CAD) output, an internal costing view or an order-ready data package.

    The important distinction is that a quote template does not configure the product or calculate the price by itself. The product model, rules engine, pricing logic and integrations produce the data. The template formats approved data for a customer, dealer, sales engineer, production planner or internal approver.

    What is a CPQ quote template?

    A CPQ quote template is a reusable document definition that controls how a configured product quotation is structured, populated, calculated and delivered. It typically contains fixed content, dynamic fields, conditional sections, line-item tables, totals, technical specifications, commercial terms and approval information.

    For a technical manufacturer, a template can draw from several sources:

    • Customer and opportunity data from a customer relationship management (CRM) system.
    • Selected options, dimensions, materials and accessories from the product configuration.
    • Validated prices, discounts, surcharges, taxes and currencies from the CPQ pricing model.
    • Cost and margin data for internal review.
    • Configured BOM or item references for technical schedules.
    • Lead times, shipping information and plant data from enterprise resource planning (ERP) or other systems.
    • Engineering notes, performance calculations, drawings or models where the implementation supports engineering automation.
    • Approval history, revision number, expiration date and commercial terms.

    The result may be a web-based quote, PDF, word-processing document, email attachment, customer portal view or structured document generated through an application programming interface (API). The format should reflect the audience. A customer may need a concise commercial proposal, while an internal engineering team may need a detailed configuration summary and a manufacturing BOM.

    Why technical product quotes need more than a standard sales template

    Generic sales CPQ often focuses on selecting products, applying discounts and producing a proposal. That can be adequate for relatively standardized goods. Technical manufacturing quotes normally require additional evidence that the selected product can be built, supplied and supported at the stated price and performance.

    For example, a pump quotation may need to show flow rate, head, motor power, voltage, materials of construction, seal type, connection size, certification requirements and expected delivery. Those values should come from a validated configuration rather than being manually retyped into a document.

    An industrial machine quote may need to distinguish standard equipment from options, identify customer-specific interfaces, state assumptions about utilities and site conditions, show installation exclusions and reference a preliminary layout. An electrical enclosure quote may need to include enclosure dimensions, ingress protection, component ratings and a list of selected devices.

    These requirements create a chain of dependencies:

    1. The customer or sales engineer selects requirements and product options.
    2. The configuration model evaluates dependencies, constraints and calculations.
    3. The system validates that the result is technically permissible.
    4. Pricing and costing logic determine the commercial values.
    5. A BOM, technical summary or engineering output may be produced.
    6. Approval rules evaluate margin, risk, discounting or non-standard content.
    7. The quote template presents the approved information in a controlled format.

    This is why a quote document should be treated as an output of the manufacturing CPQ architecture, not as an isolated design exercise.

    Core sections of a manufacturing CPQ quote template

    1. Customer, project and quote identification

    The first section normally identifies the customer, site, project, contact, salesperson, quote number, revision, issue date and validity period. For industrial sales, it may also include the customer purchase reference, application, installed location and required delivery date.

    Revision control is especially important when technical requirements change. A revised quote should make it possible to determine which configuration, prices, terms and engineering assumptions were used at each point in the negotiation.

    2. Executive commercial summary

    The summary should state what is being offered without requiring the reader to interpret an internal product code. It may include the equipment name, quantity, main performance values, total price, currency, delivery estimate and major exclusions.

    A good summary is concise but traceable. A line such as “custom process pump package” is less useful than “three-stage stainless-steel centrifugal pump package, 45 m³/h at 60 m head, 30 kW motor, 400 V, including baseplate and coupling guard.” The exact values should be generated from the configuration data.

    3. Configured product and option details

    This section shows the selected features, options, dimensions and materials. It can be presented as a specification table, grouped by assembly or divided into standard equipment, selected options and customer-specific requirements.

    Not every internal rule needs to appear in the customer document. The template should distinguish customer-relevant specifications from internal implementation details. For example, a customer may need to see that a pump uses a cartridge mechanical seal, but not the internal rule identifier that made the seal compatible with a particular shaft arrangement.

    4. Pricing, costing and commercial adjustments

    The pricing section can include quantity, list price, option prices, engineering charges, tooling, freight, discounts, taxes and total price. Internal versions may also show estimated cost, contribution margin and approval thresholds, while external versions normally exclude confidential cost data.

    Manufacturers should define whether prices are calculated from a price list, cost-plus logic, configuration-specific formulas, contract pricing or a combination. The quote template should display the result of that logic, not recreate it with independent spreadsheet formulas.

    5. Delivery, scope and terms

    Technical quotes commonly require delivery assumptions, manufacturing lead time, shipping basis, installation responsibilities, commissioning scope, warranty, payment terms and quote expiration. These values may depend on plant, product family, territory, customer status or selected options.

    Conditional text is useful here. A quote for a standard configure-to-order machine may use one delivery statement, while an engineer-to-order project may require language stating that final delivery depends on engineering approval and drawing sign-off.

    6. Technical documents and engineering outputs

    Where supported, the quote can include or reference a preliminary drawing, rendered image, performance curve, datasheet, calculation summary or product-specific CAD output. A link to an attachment is often safer than embedding every technical file directly in the proposal.

    CAD automation and engineering automation are separate capabilities from document generation. A CPQ platform may generate a quote but not create drawings or models. Buyers should verify whether these outputs come from the CPQ system, a CAD integration, a product lifecycle management (PLM) or product data management (PDM) system, or a separate engineering application. See the guide to CAD and engineering automation in CPQ for the relationship between these capabilities.

    7. Assumptions, exclusions and customer responsibilities

    Technical projects often fail commercially when assumptions are hidden. Templates should provide a controlled place for items such as available electrical supply, foundation requirements, ambient conditions, site access, customer-supplied utilities, certifications and installation boundaries.

    Some assumptions may be generated from configuration answers. Others may be entered by an engineer or selected from approved clauses. Free-text fields should be governed because uncontrolled wording can create contractual or technical risk.

    How CPQ data flows into a quote template

    A typical data flow begins with a product model. The model defines products, features, options, attributes, dependencies and constraints. A rules engine evaluates whether combinations are valid. Some systems use straightforward rules such as “if 480 V is selected, exclude the 230 V motor.” More advanced models may calculate shaft size, heat load, capacity, frame dimensions or required components.

    After validation, the pricing engine applies prices and commercial logic. It may use formulas for dimensions, quantities, material grades, regional price lists, currency conversion, volume breaks, discounts or engineering charges. Costing may use estimated labor, material, outside processing and overhead values, although costing depth varies significantly between platforms.

    The system can then produce one or more representations of the configured product:

    Representation Purpose Typical quote use
    Configuration summary Explains selected features and parameters Customer specification and sales review
    Configurable BOM Represents components selected by product rules Technical schedule, costing or order preparation
    Engineering BOM (EBOM) Describes the product from an engineering design perspective Engineering review or design reference
    Manufacturing BOM (MBOM) Describes components and assemblies used to manufacture the product Production planning or ERP handoff
    CAD output Represents geometry or drawings for a specific configuration Preliminary approval, installation or technical attachment
    Commercial values Shows prices, costs, discounts and totals Customer quotation and internal approval

    These representations are related but not interchangeable. A quote template may show a simplified component list without being the authoritative EBOM or MBOM. The system architecture should identify which application owns each record.

    Quote templates and BOM generation

    A bill of materials is a structured list of components, quantities and relationships needed to define a product or assembly. In CPQ, a configurable BOM can be generated from the selected options and rules. For example, choosing a stainless-steel pump casing, a specific motor, a baseplate and a seal arrangement may add different items to the resulting structure.

    The quote document can use BOM data in several ways:

    • Show a customer-facing equipment schedule with major assemblies and selected components.
    • Include an internal detailed component list for engineering review.
    • Display component descriptions and quantities used to explain price differences.
    • Pass item identifiers and quantities to an ERP system for order creation.
    • Provide a reference for purchasing or production after quote acceptance.

    However, a quote BOM should not automatically be treated as a production-ready MBOM. Manufacturing may require routing information, work centers, phantom assemblies, substitute rules, revision control and plant-specific data that are not maintained in CPQ. The BOM, pricing and quoting guide explains these distinctions in more detail.

    Pricing and costing fields in technical quote templates

    Pricing is the amount offered to the customer. Costing estimates the resources consumed to produce or deliver the product. A manufacturing CPQ implementation may use both, but they serve different purposes.

    Common pricing fields include:

    • Base product price.
    • Option and accessory prices.
    • Quantity and volume adjustments.
    • Customer, dealer or project discounts.
    • Engineering, tooling and setup charges.
    • Freight, packaging and installation charges.
    • Taxes, duties and surcharges.
    • Currency, payment terms and price validity.

    Common internal costing fields include material cost, purchased component cost, labor estimate, subcontracting, engineering effort and manufacturing overhead. These values may come from ERP, an enterprise costing system or CPQ calculations. The source and refresh frequency should be documented because stale cost data can produce misleading margin results.

    Quote templates should also define rounding rules. Unit prices, extended line amounts, tax calculations and total values must use consistent currency precision. The template should not introduce a second calculation method that can disagree with the pricing engine.

    Approval workflows and controlled document generation

    Technical quotes often need approvals for low margin, unusual payment terms, large discounts, non-standard materials, export restrictions, safety requirements or engineering risk. A CPQ workflow can route the quote to sales management, finance, engineering or operations before allowing external release.

    Approval status should be visible internally and should be tied to a specific quote revision. If a salesperson changes the motor, material or delivery commitment after approval, the system should determine whether the quote must be reapproved.

    Document generation should normally happen from approved data. Useful controls include:

    1. Locking or versioning the configuration used for the quote.
    2. Recording the price list and exchange rate used.
    3. Identifying the template version.
    4. Preventing external release when mandatory fields are missing.
    5. Storing the generated document with the opportunity or quote record.
    6. Maintaining a clear relationship between quote revision and downstream order.

    Template types for different manufacturing workflows

    Workflow Template emphasis Typical limitations
    Configure-to-order (CTO) Validated options, standard specifications, price and delivery May not describe project-specific engineering assumptions
    Make-to-order (MTO) Selected product parameters, manufacturing scope and delivery May require additional production planning data
    Assemble-to-order (ATO) Configured modules, available components and delivery promise Availability and allocation may belong to ERP
    Engineer-to-order (ETO) Scope, assumptions, engineering services, milestones and exclusions Final design and price may remain provisional
    Dealer or distributor sales Customer-facing price, channel discount, branding and simplified specifications Dealer document may hide internal cost and engineering data

    CTO means configure-to-order: the product is assembled or manufactured from predefined options. ETO means engineer-to-order: significant design work is required for the customer. MTO means make-to-order, while ATO means assemble-to-order. A single company may need different templates for each workflow.

    For a deeper view of these process differences, see the guide to manufacturing CPQ workflows.

    Integration requirements

    Quote templates are only as reliable as the data supplied to them. Integration architecture should identify the system of record for every important field.

    System Potential contribution to the quote process
    CRM Account, contact, opportunity, salesperson and sales activity
    ERP Items, price lists, inventory or availability, customers, currencies and order creation
    PLM Product definitions, approved revisions, engineering metadata and lifecycle status
    PDM CAD files, drawings, documents and revision-controlled product data
    CAD Parametric geometry, drawings, models and configuration-specific technical outputs
    Product information management (PIM) Descriptions, images, specifications and channel content
    Manufacturing execution system (MES) Production status or manufacturing execution information where integrated

    CRM, ERP, PLM, PDM, PIM and MES are not interchangeable. A CPQ system may connect to several of them, but the integration depth varies. Some implementations exchange only customer and item data. Others synchronize product models, revisions, BOMs, pricing, drawings and order status. The CPQ integration guide provides a framework for evaluating these data flows.

    Designing customer-facing and internal templates

    One template rarely serves every audience well. A practical architecture commonly separates documents into at least three views:

    • Customer quote: commercial price, product summary, major specifications, delivery, terms, assumptions and attachments.
    • Internal approval view: cost, margin, discount rationale, risk flags, engineering effort and exception details.
    • Order or handoff package: validated configuration, item identifiers, BOM references, drawings, notes and required downstream fields.

    Conditional sections allow a common template family to support different products. For example, a valve quote may show pressure class and seat material, while a machine quote shows throughput, cycle time and footprint. The underlying layout can remain governed while product-specific sections appear only when relevant.

    Templates should also support localization, units of measure, currency, legal entity, language, tax treatment and regional terms. These concerns should be driven by controlled data rather than manual editing wherever possible.

    Implementation process

    1. Define the quote audiences and decisions

    Start by documenting who reads the quote and what decision each person must make. A customer needs confidence in scope and price. An engineer needs sufficient configuration detail. Finance needs margin and payment information. Operations may need a clear handoff into order processing.

    2. Inventory the source data

    List every field required in the quote and identify its owner. Mark whether it is entered by a user, selected by a rule, calculated, retrieved from another system or generated as an attachment. This exposes duplicated data and fields that cannot currently be trusted.

    3. Separate configuration, pricing and presentation logic

    Configuration rules should determine what is valid. Pricing logic should determine what the valid configuration costs. The template should present those results. Combining all three in document formulas makes testing, maintenance and auditability more difficult.

    4. Define product and document variants

    Group products by shared structure and identify where technical content differs. Avoid creating a separate template for every minor variation if conditional sections and reusable components can handle the difference. At the same time, do not force unrelated product families into one document that is difficult to read or maintain.

    5. Build test scenarios

    Test standard configurations, boundary values, incompatible options, engineering exceptions, discounts, currencies, tax conditions, revisions and failed integrations. Include cases where a CAD file, BOM, price or lead time is unavailable. The quote should fail safely rather than produce an apparently complete but inaccurate document.

    6. Govern changes

    Assign ownership for product rules, prices, legal clauses, technical text, document layouts and integrations. A template change can alter the commercial meaning of a quote even when the product model is unchanged. Version control and release approval are therefore important parts of CPQ governance. The CPQ implementation and governance guide covers data ownership, testing and ongoing maintenance.

    Common limitations and risks

    • Incomplete product models: A polished document cannot compensate for missing rules, options or engineering constraints.
    • Stale pricing: If material or supplier costs are not synchronized, margin calculations may be unreliable.
    • Unclear system ownership: Conflicting customer, item or revision data can create inconsistent quotes.
    • Overloaded templates: Including every internal attribute can make customer documents difficult to understand.
    • Uncontrolled free text: Manual technical promises may bypass approved rules and approval workflows.
    • False BOM confidence: A quote component list may not be sufficient for manufacturing release.
    • Unverified engineering automation: A CPQ platform may generate a quote without generating a valid CAD model or drawing.
    • Complex exception handling: ETO work may require engineering review before specifications, price or delivery can be finalized.
    • Integration failure: Missing ERP or PLM data can block generation or create documents with incomplete information.

    How to evaluate CPQ quote template capabilities

    When evaluating software, ask vendors to demonstrate a complete manufacturing scenario rather than a generic proposal editor. The demonstration should begin with a configured product and end with a customer document, approval record and downstream data package.

    • Can the template display configuration attributes selected during the session?
    • Can it distinguish customer-visible values from internal values?
    • Can it show option prices, surcharges, discounts, taxes and totals without duplicate calculations?
    • Can it include a configurable BOM, and what level of BOM detail is supported?
    • Can it conditionally include product-family-specific specifications?
    • Can it handle revisions, multiple quote versions and approval status?
    • Can it generate different customer, dealer, internal and order-handoff documents?
    • Can it attach or link configuration-specific drawings, models and datasheets?
    • How are currency, units, language, regional terms and legal entities handled?
    • What happens when an ERP, PLM, CAD or pricing service is unavailable?
    • Can template changes be tested without changing product rules?
    • Are APIs available for document generation and storage?

    Manufacturing CPQ software should be assessed on product modeling, rules, BOM behavior, engineering support, integrations, governance and maintainability, not only on the visual quality of its proposal editor. The manufacturing CPQ software guide and CPQ comparison resources can help structure this evaluation.

    Key performance measures

    Useful measures should assess document accuracy and the surrounding process, not just the number of quotes produced. Possible measures include quote turnaround time, percentage of quotes requiring rework, configuration-related order errors, approval cycle time, margin variance between quote and order, percentage of quotes generated without manual document editing, and time required to update a template or product rule.

    For technical products, also consider whether the quote-to-order handoff preserves configuration integrity, whether engineering receives complete information and whether customers receive consistent specifications across revisions.

    Conclusion

    CPQ quote templates for technical products are the document layer that makes complex configuration and commercial decisions understandable to customers and usable by internal teams. Their reliability depends on the quality of the product model, configuration rules, pricing and costing logic, BOM structures, approval controls and enterprise integrations behind them.

    The strongest implementations separate configuration, calculation, data ownership and presentation. They provide different views for customers, approvers and manufacturing handoff, while preserving a traceable relationship between the quote revision, configured product, pricing inputs and downstream order data. A template can improve clarity and speed, but it cannot replace accurate product engineering, disciplined data governance or validated manufacturing workflows.

    Frequently asked questions

    What is a CPQ quote template?

    It is a reusable document layout that presents configured product data, pricing, terms, technical details and approvals in a controlled quotation.

    How is a manufacturing CPQ quote template different from a generic sales template?

    It can include engineering specifications, configuration attributes, BOM references, calculations, delivery assumptions and technical exclusions in addition to price and commercial terms.

    Does a quote template configure the product?

    No. The product model and configuration rules determine whether a product is valid. The template presents the resulting data.

    Can a CPQ quote template generate a BOM?

    The template itself does not generate a BOM. Some CPQ systems can generate a configurable BOM, which the template may display or reference.

    Should a customer quote include the complete BOM?

    Usually not. Customers often need a major equipment schedule or selected component summary, while detailed BOM data may remain internal or move to ERP and manufacturing systems.

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

    A configurable BOM represents components selected by product rules. A manufacturing BOM, or MBOM, represents the structure and manufacturing information needed to produce the item and may require additional plant and routing data.

    Can quote templates show engineering calculations?

    They can display calculation results when the CPQ or connected engineering system produces them. Document generation alone does not provide engineering calculation capability.

    Can a CPQ system include CAD drawings in a quote?

    Some implementations attach or link configuration-specific CAD drawings, but this requires CAD or engineering integration and is not available in every CPQ platform.

    How should pricing be connected to a quote template?

    The pricing engine should calculate prices, discounts, surcharges and totals. The template should display those results rather than recreate pricing formulas independently.

    Should internal cost and margin appear in the customer document?

    No. Cost and margin are normally restricted to internal approval views unless a specific commercial process requires otherwise.

    How do quote templates support ETO products?

    They can show engineering scope, assumptions, milestones, exclusions and provisional delivery or price. Final values may depend on engineering review and design approval.

    Can one template support multiple product families?

    Yes, if conditional sections and reusable components are well designed. Unrelated product families may be better served by separate governed templates.

    What systems commonly provide data to a CPQ quote?

    CRM may provide customer and opportunity data, ERP may provide items and prices, PLM or PDM may provide product and document data, and CAD systems may provide drawings or models.

    How should quote revisions be managed?

    Each revision should preserve the configuration, pricing inputs, template version, approval status and generated document associated with that revision.

    What happens if ERP or engineering data is unavailable?

    The system should either prevent release, clearly mark the quote as provisional or route it for review. It should not silently generate a complete-looking document with missing data.

    Can dealer quotes use different templates?

    Yes. Dealer templates may apply channel pricing, dealer branding and simplified technical information while keeping internal costs and approval details hidden.

    What should manufacturers test before deploying quote templates?

    Test valid and invalid configurations, prices, discounts, currencies, taxes, revisions, approvals, missing integrations, attachments, units of measure and downstream order handoff.

    Semantic map

    The following relationships summarize how CPQ quote templates connect configuration, engineering, commercial data and manufacturing systems.

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration validates technical dependencies.
    • Guided selling collects customer requirements.
    • Configured products generate configurable BOMs.
    • Configurable BOMs support costing and order preparation.
    • Pricing engines calculate quote prices.
    • Costing provides internal margin inputs.
    • Quote templates present approved configuration data.
    • Approval workflows control commercial exceptions.
    • CAD automation generates product-specific drawings.
    • Engineering calculations validate product performance.
    • EBOMs describe engineering product structures.
    • MBOMs describe manufacturing product structures.
    • CPQ exchanges customer and order data with CRM and ERP.
    • PLM manages approved product and engineering revisions.
    • PDM manages CAD files and technical documents.
    • ETO quotes include engineering scope and assumptions.
    • CTO quotes use predefined product options.
    • Quote revisions preserve configuration and pricing history.

  • Automated Proposal Generation for Configured Products

    Automated proposal generation for configured products is the process of turning a validated product configuration into a customer-ready commercial proposal with accurate descriptions, prices, delivery assumptions, options, exclusions and supporting technical information. In manufacturing, this process is usually performed by a Configure, Price, Quote (CPQ) system connected to product rules, costing data, bills of material (BOMs), customer records and, where required, engineering or enterprise systems.

    A manufacturing CPQ configurator does more than place line items on a sales document. It can check whether a pump, machine, vehicle or electrical assembly is technically valid; calculate dimensions, capacity or performance; select compatible components; create a configurable BOM; apply costing and pricing logic; route exceptions for approval; and generate a proposal that reflects the actual product being sold. The exact scope varies by platform. Some CPQ products focus mainly on configuration and quoting, while others also support BOM generation, CAD automation, engineering calculations or engineer-to-order workflows.

    This article explains how the process works, what information it requires, how it connects to manufacturing systems and what buyers should verify before selecting a solution. For broader context, see the guide to manufacturing CPQ.

    What automated proposal generation means in manufacturing

    Automated proposal generation is the controlled creation of a proposal from structured product, customer and commercial data rather than from manually edited documents or spreadsheets. The proposal is generated after the system has processed the customer requirements and confirmed that the selected product combination is allowed.

    For a manufacturer, a proposal may include:

    • the configured product name, model and technical description;
    • selected options, accessories, materials, finishes and performance values;
    • quantity, unit price, discounts, surcharges, freight assumptions, taxes or payment terms;
    • estimated lead time or delivery conditions;
    • commercial terms, warranty information, validity period and exclusions;
    • configuration-specific images, diagrams, data sheets or drawings;
    • a summary of the resulting BOM or scope of supply;
    • approval notes for unusual margins, non-standard components or engineering work.

    In generic sales CPQ, proposal automation may primarily assemble products, prices and terms. Manufacturing CPQ adds another layer: the proposal may be based on engineering constraints, calculated values and production-relevant data. A quote for a standard office subscription is not equivalent to a quote for a centrifugal pump selected for a specified flow, pressure, temperature, material and motor arrangement.

    How the proposal-generation workflow works

    1. Capture customer requirements

    The workflow begins with information about the application and customer. Inputs may include required capacity, operating environment, dimensions, voltage, material, regulatory requirements, quantity, installation conditions and target delivery date. A guided selling interface may ask business-oriented questions, while a technical configurator may expose engineering parameters directly.

    Guided selling and product configuration are related but different. Guided selling helps a user identify a suitable product or configuration through questions and recommendations. Product configuration applies options, dependencies, constraints and calculations to create a valid product definition. A system may support one capability without fully supporting the other.

    2. Select and validate the configuration

    The configurator applies rules to the selected options. Rules may prevent incompatible combinations, require dependent components, set valid ranges or calculate derived values. For example, selecting a stainless-steel pump body may restrict available impellers, seals or temperature ranges. Choosing a high-voltage motor may require a compatible starter, enclosure and cable specification.

    Manufacturing CPQ implementations commonly combine several types of logic:

    Logic type Purpose Manufacturing example
    Rules-based configuration Allows, prevents or requires options A roof-mounted accessory requires a reinforced frame
    Constraint-based configuration Checks relationships, limits and technical conditions Motor power must match pump duty and available voltage
    Parameter calculations Derives values from customer inputs Calculate tank volume, belt length or heat exchanger area
    Guided selling Helps users reach a suitable choice Recommend a valve series based on pressure and fluid type

    More detail on product models, features, dependencies and constraints is available in the product configuration guide.

    3. Generate engineering and product data

    Once the configuration is valid, the CPQ system may generate or retrieve technical outputs. These can include a product description, calculated performance values, an option summary, a configurable BOM, a customer-facing image or a request for engineering review.

    The scope depends on the product and platform. A configure-to-order machine may use predefined modules and generate a production-ready structure. An engineer-to-order product may require a design task before the final BOM, drawing or delivery date can be confirmed. Some implementations connect CPQ with computer-aided design (CAD) systems to create product-specific models or drawings; others attach existing documents or provide only a textual summary.

    CAD automation should therefore be evaluated separately from proposal generation. A system that creates a PDF quote is not necessarily capable of generating parametric CAD geometry, manufacturing drawings or design calculations. The CAD and engineering automation guide explains these distinctions.

    4. Calculate cost and price

    The pricing stage converts the validated configuration into commercial values. Costing may use component costs, labor assumptions, outside processing, freight, tooling, engineering hours and overhead allocations. Pricing may then apply list prices, customer-specific agreements, markups, discounts, volume breaks, currency conversion, surcharges and margin rules.

    Cost and price are not interchangeable. Cost represents the manufacturer’s expected resource consumption or procurement expense. Price is the amount offered to the customer. A CPQ system may calculate both, but the quality of the result depends on the source data and pricing governance.

    For example, a configured industrial enclosure may include sheet metal, coating, hardware, wiring, assembly labor and testing. The proposal price could depend on material grade, enclosure dimensions, ingress protection, production location, order quantity and customer discount policy. If one of those drivers is missing or outdated, automated document generation can make an inaccurate quote look authoritative.

    5. Apply approvals and commercial controls

    Many manufacturers require approval before a proposal is sent. Approval conditions may include margin below a threshold, unusual discounts, non-standard terms, custom engineering, obsolete components, export restrictions or a delivery promise outside normal capacity.

    Approval workflows should preserve the relationship between the approved configuration and the issued proposal. If a sales representative changes the motor, quantity or discount after approval, the system should either recalculate the proposal or require a new approval. This is a key difference between controlled CPQ output and manually editing a document in a word processor.

    6. Assemble and deliver the proposal

    The final document is normally generated from templates containing structured fields. A template can insert the configuration summary, price tables, technical specifications, images, terms and attachments. It may produce a PDF, a web proposal or another controlled format. The document should have a revision, validity period and reference to the underlying quote and configuration.

    Document generation is the final presentation step, not the source of truth. Product rules, prices, customer data and engineering outputs should remain in governed systems rather than being maintained only inside proposal templates.

    Data architecture behind automated proposals

    Reliable automation depends on the relationship between several data domains. A typical architecture includes the following:

    Data domain Typical contents Role in the proposal
    Product model Features, options, modules, attributes and rules Defines what can be configured
    Technical data Dimensions, ratings, materials, calculations and specifications Describes the configured product accurately
    Configurable BOM Conditional components, quantities and relationships Represents the selected scope and supports costing
    Cost data Material, labor, supplier, freight and engineering costs Supports margin and profitability analysis
    Pricing data Base prices, adjustments, discounts and currencies Calculates the customer offer
    Customer and commercial data Accounts, contracts, terms, tax and delivery information Personalizes the proposal and applies policy
    Document templates Layouts, clauses, images and attachments Produces the customer-facing output

    A BOM, or bill of material, is the structured list of components and quantities required for a product. A configurable BOM contains alternatives or conditional items that are resolved by the selected configuration. An engineering BOM (EBOM) describes a product from a design perspective. A manufacturing BOM (MBOM) describes how it is assembled or produced. The proposal may use a sales-facing summary or a resolved technical structure without exposing the complete MBOM to the customer.

    Manufacturers should define which BOM is generated at quote time and which structure is released later for production. The BOM, pricing and quoting guide covers this relationship in more detail.

    Relationships with ERP, CRM, PLM, PDM, CAD, PIM and MES

    Automated proposal generation usually sits between customer-facing sales activity and engineering or enterprise systems. These systems are complementary, not interchangeable:

    • CRM (Customer Relationship Management): stores accounts, opportunities, contacts and sales activity.
    • ERP (Enterprise Resource Planning): manages items, inventory, purchasing, production, orders, finance and often standard pricing.
    • PLM (Product Lifecycle Management): governs product definitions, revisions, change processes and lifecycle data.
    • PDM (Product Data Management): manages design files, CAD documents, versions and access controls.
    • CAD (Computer-Aided Design): creates product geometry, assemblies and drawings.
    • PIM (Product Information Management): manages reusable commercial and technical product content across channels.
    • MES (Manufacturing Execution System): supports execution and tracking of production operations on the shop floor.

    A CPQ system may read released product and price data from ERP or PLM, receive an opportunity from CRM, call CAD automation services, and return a quote or order-ready structure to ERP. The exact integration pattern depends on system ownership and product complexity. Further guidance is available in the CPQ integration guide.

    Manufacturing examples

    Configured pump package

    A customer specifies flow, head, fluid temperature, material, seal type, motor voltage and installation arrangement. The CPQ system validates the duty point, restricts incompatible materials, selects a pump and motor combination, adds baseplate and coupling components, calculates cost and applies customer pricing. The proposal includes the selected performance, scope of supply, estimated delivery and commercial terms. If the duty point falls outside standard product rules, the quote is routed to an application engineer.

    Industrial HVAC unit

    The configuration may include airflow, static pressure, casing material, coil arrangement, filters, controls, heating or cooling capacity and electrical options. Rules determine compatible modules and calculate dimensions or performance. The generated proposal can present a readable schedule of equipment, while the underlying configurable BOM supports procurement and production planning.

    Specialty vehicle

    A vehicle proposal may combine chassis, body dimensions, payload, storage modules, electrical systems, safety equipment and customer-specific accessories. Selecting one body layout may remove incompatible storage modules or change wiring and mounting requirements. The proposal should show the exact option set and exclusions, because visually similar vehicles may have materially different costs and lead times.

    Benefits and limitations

    Potential benefits

    • Faster quote preparation: Reusable rules and templates reduce manual document assembly.
    • Fewer configuration errors: Invalid combinations can be blocked before a proposal reaches the customer.
    • More consistent pricing: Approved pricing logic can be applied across sales channels and regions.
    • Better engineering focus: Engineers can review genuine exceptions instead of checking every standard quote.
    • Clearer handoff: The configuration, price basis and technical scope can travel with the opportunity or order.
    • Traceability: Revisions, approvals and proposal outputs can be linked to a specific configuration.

    Important limitations

    • Automation cannot compensate for incomplete product data, obsolete costs or undocumented engineering knowledge.
    • A rules engine may validate combinations without proving that the design is manufacturable in every plant or process.
    • Proposal generation does not automatically create an accurate EBOM, MBOM, CAD model or production routing.
    • Complex engineer-to-order work may still require engineering review, design iterations and formal change control.
    • Templates can become difficult to maintain if commercial, technical and legal content is not governed.
    • ERP, PLM and CAD integrations introduce ownership, revision, synchronization and failure-handling issues.
    • Automated pricing can expose margin or contractual risks if approval thresholds and source data are poorly controlled.

    Implementation considerations

    Start with the product and quote scope

    Define which product families, sales channels and quote types will be automated first. A modular configure-to-order (CTO) product with stable options is usually a different implementation from an engineer-to-order (ETO) product requiring new design work. Make-to-order (MTO) products are produced for a specific order but may use standard designs, while assemble-to-order (ATO) products are assembled from stocked modules after demand is received. These distinctions affect rules, BOM timing, lead-time calculation and engineering involvement.

    Assign data ownership

    Decide who owns product options, technical attributes, costs, prices, terms, drawings and proposal content. Product engineering may own technical rules, finance may own margin policy, sales operations may own discounts and legal may own terms. Without explicit ownership, the CPQ model becomes a duplicate database that drifts from source systems.

    Model rules as testable logic

    Document each rule with its purpose, inputs, expected outcome and owner. Test positive cases, invalid cases, boundary values, combinations of options and changes to released products. Include regression tests so that adding a new motor or material does not silently invalidate existing configurations.

    Separate configuration, pricing and document logic

    These layers interact but should not be indistinguishable. Configuration determines what product is valid. Costing estimates the resources required. Pricing determines the commercial offer. Document templates present the result. Separating them makes it easier to change a discount policy without rewriting engineering rules or changing a product model without breaking the proposal layout.

    Plan revision and integration behavior

    Define what happens when a price, component, drawing or rule changes after a proposal is issued. The system should preserve the quoted revision and identify whether a new configuration or price calculation is required. Integration designs should also specify error handling, synchronization frequency, identifiers, unit conversions, currency behavior and ownership of master data.

    Implementation planning, migration, testing, governance and maintenance are covered in the CPQ implementation guide. For workflow design, see the guide to manufacturing CPQ workflows.

    How to evaluate proposal-generation capabilities

    When comparing CPQ configurators, ask vendors to demonstrate a complete manufacturing scenario rather than a generic quote screen. The demonstration should begin with customer requirements and end with an approved proposal and downstream handoff.

    • Can the product model represent options, dependencies, numeric ranges and calculated values?
    • Can the system distinguish invalid combinations from configurations requiring engineering review?
    • Does it generate a resolved BOM, a sales summary, an EBOM, an MBOM or only quote lines?
    • How are component costs, labor, freight, tooling and engineering effort calculated?
    • Can pricing rules vary by customer, channel, currency, region, quantity and validity date?
    • How are discounts, low margins, non-standard terms and exceptions approved?
    • Can the proposal include configuration-specific technical data, images, drawings or CAD outputs?
    • How are quote revisions, expired prices and changes to released products handled?
    • What integrations are documented for CRM, ERP, PLM, PDM, CAD, PIM and MES?
    • Can administrators test and maintain rules without relying on unrestricted custom code?
    • How does the system support CTO, ATO, MTO and ETO processes?
    • What APIs, audit records, permissions and deployment controls are available?

    The most suitable platform is not necessarily the one with the longest feature list. It is the one that can represent the manufacturer’s product logic, preserve data ownership, produce the required commercial and technical outputs, and remain maintainable as products change. Vendor profiles and selection material are available in the manufacturing CPQ software section and CPQ comparison guides.

    Semantic map

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

    • Customer requirements lead to a product configuration.
    • Product configuration is validated by rules and constraints.
    • A valid configuration determines technical attributes and selected components.
    • A configurable BOM represents the selected product structure.
    • Cost data supports cost and margin calculations.
    • Pricing rules convert cost and commercial policy into a customer price.
    • Approval workflows control discounts and exceptions.
    • Proposal templates present configuration, price and terms.
    • ERP supplies or receives enterprise product and order data.
    • PLM and PDM govern released product and design information.
    • CAD automation can generate product-specific models or drawings.
    • CPQ connects sales requirements with engineering and manufacturing processes.

    Frequently asked questions

    1. What is automated proposal generation for configured products?

    It is the automated creation of a customer proposal from a validated product configuration, calculated price, technical scope, terms and supporting documents.

    2. Is automated proposal generation the same as CPQ?

    No. Proposal generation is one CPQ output. Manufacturing CPQ may also manage configuration rules, engineering calculations, BOMs, costing, approvals and downstream integrations.

    3. Can a CPQ system generate a BOM?

    Some CPQ systems generate resolved or configurable BOMs, while others generate only quote lines or product summaries. This capability must be verified for each platform and product family.

    4. Does a generated proposal contain the complete manufacturing BOM?

    Not necessarily. A proposal may contain a customer-facing scope of supply, while the detailed EBOM or MBOM remains in PLM or ERP.

    5. How does configuration affect proposal pricing?

    Selected options, dimensions, materials, quantities, performance requirements and services can change component costs, labor, freight, surcharges, discounts and final price.

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

    Cost estimates what the manufacturer must spend or consume. Price is the amount offered to the customer after applying commercial policy and margin requirements.

    7. Can automated proposals include engineering calculations?

    Some manufacturing CPQ platforms support calculations or connect to external engineering services. Others require engineering software or manual review.

    8. Can CPQ automatically create CAD drawings?

    Only platforms with suitable CAD or design-automation capabilities can do this. A document generator alone cannot be assumed to create parametric geometry or manufacturing drawings.

    9. How does CPQ handle engineer-to-order products?

    It can capture requirements, create an initial scope, estimate engineering work and route the opportunity for review. Final design and delivery commitments may still depend on engineering completion.

    10. What happens when a configuration is invalid?

    The system may block the combination, explain the conflict, suggest an alternative or route the case to an engineer, depending on the configured workflow.

    11. Can proposals be generated from CRM opportunities?

    Yes, when the CPQ system integrates with the CRM. The opportunity can provide customer and sales context while CPQ manages the technical configuration and commercial calculation.

    12. Does ERP replace CPQ proposal generation?

    ERP may store items, prices, orders and production data, but it does not necessarily provide the product rules, guided configuration or proposal logic required for complex engineered products.

    13. How are quote approvals automated?

    Approval rules can trigger review based on margin, discount, non-standard terms, custom engineering, delivery risk or other defined conditions.

    14. Can the proposal show a 3D product image?

    It can if the CPQ implementation includes visualization or receives a configuration-specific image from a visualization or CAD service. This is not universal.

    15. How should manufacturers test automated proposals?

    Test standard, boundary and invalid configurations, pricing changes, revisions, approval paths, document output, integration failures and handoff to engineering or ERP.

    16. Who should own CPQ product rules?

    Ownership commonly involves product engineering, product management and sales operations, with defined responsibilities for technical rules, prices, content and approvals.

    17. Can automated proposals support dealers and distributors?

    Yes, some systems provide dealer portals, channel pricing and controlled self-service configuration. The specific workflow and permissions must be confirmed during evaluation.

    18. What is the main risk of automated proposal generation?

    The main risk is automating incorrect or outdated data. Rules, costs, prices, revisions and templates require governance and ongoing testing.

  • Visual CPQ: How Visual Product Configuration Works

    Visual CPQ combines interactive product visualization with configure, price, quote (CPQ) logic. A user selects dimensions, materials, components or accessories and sees the configured product change in a 2D or 3D view. Behind the interface, a product model validates the choices, calculates technical and commercial results, and may generate a bill of materials (BOM), CAD output, quotation or manufacturing handoff.

    In manufacturing, visual CPQ is more than a sales image or product selector. A useful implementation connects the visual representation to the same configuration data and rules used for engineering, pricing and production. For example, configuring an industrial pump may change the pump casing, impeller, motor, coupling, baseplate and dimensions in the visualization. The system may also check flow and pressure requirements, calculate price, create a configurable BOM and pass approved data to enterprise systems.

    This guide explains how visual product configuration works, what systems it requires, where it fits in the sales-to-engineering process, and what manufacturers should verify before implementation.

    What is visual CPQ?

    Visual CPQ is a manufacturing CPQ capability that lets users configure a product through an interactive 2D, 3D or augmented visual representation while the system applies product rules, engineering logic, pricing and quoting processes.

    Traditional CPQ may present a sequence of forms, dropdowns and checkboxes. Visual CPQ adds a visual layer that represents the selected product configuration. Depending on the platform and implementation, the visual layer may show:

    • Product options, such as motors, valves, seats, handles or control panels.
    • Dimensional changes, including length, width, height, capacity or mounting positions.
    • Material and finish selections.
    • Optional assemblies and accessories.
    • Product exclusions or unavailable combinations.
    • Configuration status, warnings and missing information.
    • Product-specific images, drawings or three-dimensional models.

    The visual component does not replace the configuration engine. It provides an interactive representation of the product model. The configuration engine remains responsible for determining whether choices are valid and what technical, commercial and manufacturing data should result.

    Manufacturers should therefore distinguish between a visual product configurator and a complete visual CPQ solution. A visual configurator may change images or display selected options without generating a valid BOM, calculating engineering values or supporting downstream production. Visual CPQ connects visualization to those broader processes, although the exact capabilities vary by product and implementation.

    How visual product configuration works

    A visual CPQ workflow normally contains several connected layers: the user interface, product model, rules engine, visualization data, engineering calculations, commercial logic and enterprise integrations.

    1. The user selects product requirements

    The process begins with a guided configuration experience. A salesperson, dealer, engineer or customer may specify requirements such as load, flow rate, operating temperature, voltage, dimensions, capacity, environment or intended application.

    In an industrial machinery example, the user might choose:

    • Machine type and operating capacity.
    • Working width and overall length.
    • Drive motor and gearbox.
    • Material grade and surface treatment.
    • Safety enclosure and access doors.
    • Control system and electrical supply.
    • Installation location and required accessories.

    The interface can expose direct options or ask requirement-based questions. The latter is often called guided selling. Guided selling recommends or narrows products based on user needs; it is not the same as a rules engine. The system still needs configuration rules to validate the final engineered combination.

    2. The configuration engine evaluates rules

    Each selection is evaluated against the product model. Rules may determine which options are available, which components are required, which combinations are prohibited and which values must be calculated.

    Common rule types include:

    Rule type Manufacturing example Purpose
    Compatibility rule A high-temperature seal is required for a specified process temperature. Prevents incompatible selections.
    Dependency rule A variable-frequency drive requires a compatible motor and control cabinet. Adds required components.
    Exclusion rule A particular mounting arrangement is unavailable with a large motor. Blocks invalid combinations.
    Calculation rule Frame dimensions change when conveyor length exceeds a threshold. Derives technical values.
    Selection rule A pressure class is selected based on operating pressure and temperature. Automates engineering choices.
    Commercial rule Dealer discount or freight treatment depends on market and configuration. Controls price and terms.

    Rules may be implemented as decision tables, constraints, formulas, scripts, object relationships or a combination of these methods. A constraint-based configuration approach describes valid and invalid states across many variables. A rules-based approach often expresses explicit conditions and consequences. In practice, manufacturing systems frequently use both.

    For a deeper explanation of product models, dependencies and validation, see the manufacturing product configuration guide.

    3. The visual model responds to configuration changes

    After a valid selection or an in-progress selection, the visual layer updates the representation. A component may appear, disappear, move, change colour or change geometry. Dimensional labels may update when a parameter changes.

    There are several common approaches:

    • Image-based configuration: The system switches product images or assembles layered images. This can be practical for products with a limited number of visual variants.
    • Parametric 3D configuration: A three-dimensional model changes dimensions, components or geometry based on configuration variables.
    • Component assembly: The viewer combines reusable 3D parts into an assembly. This is useful when options correspond to modular components.
    • CAD-driven visualization: Configuration data is passed to a CAD or engineering automation process that produces a product-specific model or drawing.
    • Web-based 3D visualization: A browser-based viewer displays models using web-compatible formats and communicates with the CPQ application through APIs.

    The visual output may be immediate, while a detailed CAD regeneration happens later. This distinction matters. A lightweight viewer can provide fast interaction, but it may not represent every manufacturing detail. A CAD-generated output can be more authoritative, but it may require more processing time and engineering data.

    4. Engineering calculations and validation are applied

    Visual changes should not be treated as proof that a configuration is manufacturable. The system may need to perform engineering calculations such as:

    • Motor sizing and power requirements.
    • Pump duty-point or pressure calculations.
    • Structural load and deflection checks.
    • Thermal or airflow calculations.
    • Electrical load, voltage and enclosure calculations.
    • Clearance, reach and interference checks.
    • Material quantity and dimensional calculations.
    • Weight, centre-of-gravity or transport calculations.

    Some CPQ platforms provide calculation features; others call external engineering services, CAD systems or custom applications. Manufacturers should verify whether a claimed calculation is a formal engineering validation, a simple sizing formula or only a recommendation.

    5. The configured product produces commercial and manufacturing outputs

    Once the configuration is valid, the CPQ application can calculate price and generate quote content. In manufacturing, the output may also include structured product data.

    A typical result can contain:

    • Configured product identifier and revision.
    • Selected options and parameter values.
    • Technical specifications.
    • Pricing, discounts, surcharges, taxes or freight assumptions.
    • Configurable BOM or order-specific BOM.
    • Engineering notes and approval status.
    • Product images, rendered views or drawings.
    • CAD files or references to generated CAD outputs.
    • Data for enterprise resource planning (ERP), customer relationship management (CRM), product lifecycle management (PLM) or manufacturing execution systems (MES).

    A BOM is not automatically the same as a CAD assembly. An engineering BOM (EBOM) describes the product from an engineering perspective. A manufacturing BOM (MBOM) structures components and operations for production. A configurable BOM may contain rules or options that resolve into an order-specific structure. The required output depends on whether the next step is quotation, engineering review, purchasing or manufacturing release.

    The relationship between BOMs, pricing and quote generation is covered in the BOM, pricing and quoting guide.

    Visual CPQ architecture

    A practical visual CPQ architecture commonly includes the following components:

    Layer Responsibility Typical data
    Experience layer Provides the configuration interface and visual interaction. Questions, options, dimensions, views and user permissions.
    Product model Defines products, variants, components and attributes. Features, materials, components, revisions and option relationships.
    Rules and constraints Validates combinations and derives values. Dependencies, exclusions, formulas, constraints and approvals.
    Visualization engine Displays the configured product. Images, 3D meshes, assembly metadata, camera views and annotations.
    Engineering services Performs calculations or generates technical outputs. Parameters, sizing inputs, CAD templates, drawings and calculations.
    Commercial engine Calculates costs, prices and quote terms. Price lists, cost models, discounts, currencies and approval thresholds.
    Integration layer Moves approved data between systems. Product IDs, BOMs, configurations, orders, documents and status.

    These layers may be delivered by one platform or distributed across CPQ, CAD, PLM, ERP and custom services. A manufacturer should evaluate the complete data flow rather than assuming that a single visual interface owns every product record.

    How visual CPQ connects CAD and engineering automation

    CAD means computer-aided design. In a visual CPQ workflow, CAD can be used in three different ways.

    CAD as a visualization source

    Existing CAD models can be simplified, converted or published for browser-based visualization. This approach provides a visual representation without regenerating the full engineering model for every interaction.

    CAD as a parametric output engine

    Configuration parameters can be passed to a parametric CAD template. The CAD process then changes dimensions, suppresses features, selects components or creates a product-specific assembly. The resulting model may be used to generate drawings, neutral files or manufacturing documentation.

    CAD as a downstream engineering system

    CPQ may send a validated configuration to CAD or product data systems after quotation or order approval. Engineering automation can then create or complete the detailed design. This is common where the product has significant engineered-to-order content.

    These approaches have different governance requirements. A visual model may be suitable for communication but not for manufacturing release. A CAD output may be geometrically accurate but still require engineering approval, tolerance definition, material verification and production planning. More information is available in the CAD and engineering automation guide.

    Manufacturing example: configuring an industrial pump skid

    Consider a pump manufacturer selling configurable skid-mounted systems. The buyer or sales engineer selects flow rate, pressure, fluid type, temperature, motor voltage, pump material, valve arrangement, instrumentation and skid dimensions.

    The visual CPQ process might work as follows:

    1. The user enters duty requirements and installation constraints.
    2. The system recommends compatible pump families and motor ranges.
    3. Rules exclude materials that are unsuitable for the selected fluid or temperature.
    4. The visualization adds the chosen pump, motor, valves, instruments and access features.
    5. A calculation service checks pump selection and motor requirements.
    6. Skid length and baseplate dimensions are recalculated.
    7. The configured BOM includes the pump, motor, coupling, base, valves, fittings, instruments and fasteners.
    8. Pricing applies component prices, engineering charges, options, freight assumptions and commercial approvals.
    9. A quote displays the configured visual, technical specifications and commercial terms.
    10. After approval, configuration data is sent to ERP and engineering systems for order processing and detailed documentation.

    If the pump skid is standard enough for configure-to-order (CTO), the rules may resolve most of the design automatically. If each skid requires substantial new design work, the process may be engineer-to-order (ETO), with the visual configuration acting as a controlled starting point for engineering rather than a complete design release.

    Visual CPQ in the sales-to-engineering handoff

    The main operational value of visual CPQ is not only that customers can see a product. It can create a shared, structured definition of what was sold.

    A strong handoff includes:

    • A unique configuration identifier.
    • Revision and model version.
    • All selected options and parameter values.
    • Resolved components and quantities.
    • Calculation results and assumptions.
    • Exceptions, warnings and engineering review requirements.
    • Approved drawings, images or CAD references.
    • Commercial status and approval history.

    This is different from sending engineering a PDF or salesperson’s notes. Documents may be useful, but structured configuration data is easier to validate, reuse and map to ERP, PLM, PDM or MES processes. PDM means product data management, while MES means manufacturing execution system. Neither is interchangeable with CPQ: CPQ manages configuration and commercial decisions, whereas PDM manages product files and revisions and MES manages shop-floor execution data.

    See the guide to configure-to-order, engineer-to-order and sales-to-engineering workflows for a broader process view.

    Benefits of visual CPQ for manufacturers

    • Better product understanding: Sales teams, dealers and buyers can see the effect of options that are difficult to explain in text.
    • Earlier detection of misunderstandings: A visual representation can reveal incorrect orientation, access assumptions or missing accessories before order release.
    • Reduced manual re-entry: A structured configuration can be reused for pricing, quote documents, BOMs and engineering tasks.
    • More consistent sales engineering: Guided interaction and validation reduce dependence on individual spreadsheet knowledge.
    • Improved quote communication: The quote can show the actual proposed equipment rather than a generic catalogue image.
    • Faster variant definition: Standard components and rules can reduce repetitive design work for repeatable products.
    • Support for dealer and self-service channels: Visual configuration can make complex products easier to sell through authorized channels, provided the rules are governed centrally.

    Limitations and risks

    Visual CPQ does not remove the underlying complexity of engineered products. It can expose or manage that complexity, but it cannot compensate for poor product data or incomplete rules.

    • Visual accuracy may not equal engineering accuracy: A model can look correct while omitting tolerances, internal parts, materials or manufacturing constraints.
    • Large option spaces are difficult: Many product variants can create complex model maintenance and slow visualization performance.
    • CAD data may be unsuitable for direct web use: Detailed models often require simplification, conversion, security controls and performance testing.
    • Rules can become difficult to govern: Duplicated formulas and undocumented exceptions make changes risky.
    • Engineering calculations may remain external: Integration with specialist tools can require custom services, data mapping and validation.
    • Configuration and manufacturing structures may differ: The product selected by the customer may need transformation into an EBOM, MBOM or production order structure.
    • ETO work still needs engineering review: A visual configuration should not be presented as automatic design release when substantial engineering remains.
    • Data ownership can be unclear: Product, CAD, price and manufacturing data may be maintained by different departments and systems.

    Implementation considerations

    Define the authoritative product model

    Decide which system owns product definitions, component identifiers, revisions, materials, CAD references and lifecycle status. CPQ may consume data from PLM or PDM rather than becoming the master for every engineering object.

    Separate visual, configuration and engineering data

    Map each visual object to a controlled product option or component. Do not rely on image names or informal labels as the only connection between what the user sees and what the ERP or engineering system receives.

    Prioritize high-value configuration paths

    Start with products where visual errors, engineering rework or quote delays create measurable operational problems. A focused model is easier to test than an attempt to represent every product family at once.

    Test rules and outputs together

    Test not only whether the interface allows or blocks a choice, but also whether the resulting price, BOM, CAD output, technical specification and integration message are correct. Use valid, invalid, boundary and change-impact test cases.

    Plan model governance

    Assign ownership for rules, visual assets, CAD templates, prices, BOM mappings and integrations. Establish review processes for product revisions, obsolete components, engineering changes and market-specific pricing.

    Measure operational outcomes

    Useful measures may include configuration error rate, engineering clarification workload, quote cycle time, percentage of quotes requiring manual re-entry, BOM correction rate, CAD automation success rate and time from order approval to engineering release. Measures should distinguish improvements caused by better rules from improvements caused only by a redesigned user interface.

    Implementation planning, migration, testing and governance are discussed in the manufacturing CPQ implementation guide. System boundaries and integration patterns are covered in the CPQ integration guide.

    How to evaluate visual CPQ software

    Evaluation question Why it matters
    Can the platform represent dimensions, dependencies, constraints and calculated values? Visual interaction is useful only when it reflects valid product logic.
    Does the 3D viewer use configurable components, parametric geometry or static assets? This determines how accurately variants and dimensions can be represented.
    Can the system generate or exchange BOM data? Manufacturing handoff requires structured product output, not only images.
    How does it connect to CAD, PLM, PDM and ERP? Integration determines whether configuration data can be reused downstream.
    Are engineering calculations native or external? The answer affects architecture, validation and implementation effort.
    Can users distinguish warnings, invalid states and engineering review requirements? Not every non-standard configuration should be silently accepted.
    How are visual assets and product rules versioned? Visual output must remain aligned with released product definitions.
    Can the platform support CTO and ETO workflows? Manufacturers need to know whether the result is an order-ready configuration or an engineering starting point.
    Are APIs available for headless, dealer or ecommerce channels? Multiple channels may need to use the same product model and rules.

    Do not evaluate visual CPQ by screenshots alone. Request a demonstration using representative products, including dimensional changes, incompatible options, calculated selections, BOM output, CAD handoff and an ERP or PLM integration scenario where relevant.

    Visual CPQ versus related technologies

    Technology Primary role Relationship to visual CPQ
    Product configurator Defines and validates product options. Visual CPQ adds an interactive representation and may connect configuration to quoting and engineering.
    CAD automation Creates or modifies technical geometry and drawings. Visual CPQ may supply parameters or consume CAD outputs.
    Product visualization Displays products in 2D or 3D. Visualization may exist without rules, pricing or manufacturing outputs.
    Guided selling Recommends products or options based on requirements. It can be part of the interface but does not replace configuration validation.
    CRM Manages customer, opportunity and sales activity data. CRM may launch CPQ and store quote status but is not normally the product rules authority.
    ERP Manages enterprise, order, inventory, purchasing and financial processes. ERP may receive configured items, BOMs, prices or orders from CPQ.
    PLM or PDM Manages product definitions, files, revisions and lifecycle data. These systems may provide controlled engineering data to CPQ.

    Frequently asked questions

    What is visual CPQ?

    Visual CPQ is CPQ software that combines product configuration and quoting with an interactive 2D or 3D representation of the configured product. In manufacturing, it may also connect to engineering, BOM, CAD and enterprise workflows.

    How is visual CPQ different from a product configurator?

    A product configurator validates options and parameters. Visual CPQ adds a visual representation and commonly connects the validated configuration to pricing, quoting and downstream outputs. The exact scope depends on the software.

    Does visual CPQ always include 3D?

    No. Some implementations use 2D images, layered graphics, drawings or simplified product views. Three-dimensional visualization is an option, not a requirement for every visual CPQ project.

    Can visual CPQ generate CAD models?

    Some platforms integrate with CAD automation or parametric templates, while others only display prepared visual assets. CAD generation should be verified for the specific CAD system, product family and required output.

    Can visual CPQ generate a BOM?

    Some manufacturing CPQ systems can resolve a configurable BOM or produce an order-specific BOM. Others pass configuration selections to ERP, PLM or a separate BOM service. This capability should not be assumed.

    Is a visual model the same as a manufacturing model?

    No. A visual model may omit internal components, tolerances, materials or production information. It can communicate the proposed product without being suitable for manufacturing release.

    What product data does visual CPQ require?

    It commonly requires product families, options, components, attributes, dimensions, rules, visual assets, prices and identifiers. Engineering use cases may also require CAD templates, calculation inputs, BOM mappings and revision data.

    What rules are used in visual product configuration?

    Typical rules define compatibility, dependencies, exclusions, required components, dimensional calculations, engineering limits and commercial conditions. Rules may be represented as constraints, formulas, decision tables or scripts.

    Can visual CPQ support engineer-to-order products?

    It can support ETO by capturing requirements, creating a controlled starting configuration and passing structured data to engineering. It does not automatically eliminate engineering design work or approval.

    What is the role of CAD in visual CPQ?

    CAD can provide visualization assets, respond to configuration parameters, generate product-specific geometry or produce drawings. The role depends on whether the manufacturer needs communication-quality visuals or engineering-grade outputs.

    How does visual CPQ support configure-to-order?

    For CTO products, the system can validate selections within a predefined product model, resolve components and pass the result to order and production processes. The degree of automation depends on data quality and integration.

    Can customers use visual CPQ directly?

    Yes, some manufacturers expose visual configuration to customers, dealers or ecommerce users. The interface should limit access to appropriate options and protect pricing, engineering and product data.

    Does visual CPQ replace sales engineers?

    No. It can automate repeatable selections and reduce manual work, but sales engineers remain important for unusual applications, requirements analysis, engineering review and non-standard configurations.

    How does visual CPQ connect to ERP?

    It may send configured product identifiers, option values, prices, BOMs, documents or order data through APIs, middleware or integration services. The exact mapping depends on the ERP and the manufacturer’s process.

    How does visual CPQ connect to PLM or PDM?

    It may consume released product, CAD and revision data from PLM or PDM, or send approved configuration information back for engineering processing. System ownership and revision control must be defined explicitly.

    What is the biggest implementation risk?

    A common risk is building an attractive visual interface without a governed product model, rules, identifiers and downstream data structure. The result may look correct but still require manual engineering correction.

    How should manufacturers test visual CPQ?

    Test valid and invalid combinations, dimension boundaries, rule changes, visual accuracy, prices, BOMs, CAD outputs, approval paths and integration messages. Test complete product scenarios rather than isolated interface controls.

    Semantic map

    The relationships below summarize how visual CPQ connects configuration, visualization, engineering and manufacturing systems.

    • Visual CPQ uses product models to represent configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraints validate dimensions, capacities and engineering limits.
    • Configured options update visual product representations.
    • Parametric CAD uses configuration parameters to generate product-specific geometry.
    • Configured products generate configurable BOMs or order-specific BOMs.
    • Engineering calculations validate technical requirements.
    • CPQ calculates prices from configured components and commercial rules.
    • CPQ generates quotes containing technical and commercial information.
    • CPQ exchanges configuration data with ERP.
    • CPQ may consume controlled product data from PLM or PDM.
    • CAD automation generates product-specific drawings and technical files.
    • Visual CPQ supports sales-to-engineering handoff.
    • Configure-to-order uses validated product configurations for repeatable manufacturing.
    • Engineer-to-order uses configured requirements as a starting point for engineering work.

    Conclusion

    Visual CPQ works by connecting an interactive representation of a product to a governed product model, configuration rules, engineering calculations, pricing logic and downstream systems. Its value in manufacturing comes from making the configured result understandable while preserving the structured data required for quoting, engineering and production.

    The strongest implementations do not treat visualization as a decorative front end. They map every meaningful visual choice to controlled product data, validate the configuration, distinguish visual output from engineering release, and define how the result becomes a BOM, CAD output, quote, order or engineering task. Manufacturers should therefore evaluate visual CPQ as part of the complete configuration and engineering architecture rather than as an isolated 3D viewer.

  • CPQ CAD Automation: From Sales Inputs to Production Drawings

    CPQ CAD automation connects a manufacturing Configure, Price, Quote (CPQ) system to computer-aided design (CAD) models so that approved sales inputs can produce product-specific engineering outputs. Depending on the implementation, those outputs may include a 3D model, 2D production drawing, engineering calculations, a configured bill of materials (BOM) or a handoff package for a product lifecycle management (PLM) or enterprise resource planning (ERP) system.

    The purpose is not simply to draw a product faster. A well-designed process turns a valid product configuration into consistent engineering data. For example, a salesperson configuring a pump may select capacity, fluid, temperature, materials, motor type, seal arrangement, connection size and mounting orientation. The CPQ system validates those choices, calculates required dimensions, determines price and cost, and passes controlled parameters to CAD automation. CAD then generates the appropriate geometry and drawings for engineering review or production.

    This is a manufacturing capability rather than a generic sales quoting feature. Not every CPQ platform supports CAD automation, engineering calculations, BOM generation or production drawings. Buyers must verify which functions are native, which require an external configurator or CAD automation service, and which remain under engineering control.

    For a broader explanation of the product model and rules layer, see the guide to product configuration. For related engineering concepts, see CAD and engineering automation in CPQ.

    What is CPQ CAD automation?

    CPQ CAD automation is the controlled generation or modification of CAD data from validated product configuration data. The configuration normally begins with commercial or technical inputs, while the CAD output is governed by engineering parameters, templates, constraints and revision-controlled design assets.

    A typical flow is:

    1. A user selects a product family and enters required technical and commercial inputs.
    2. The configuration engine applies rules and constraints to reject incompatible combinations.
    3. Engineering calculations derive values such as shaft diameter, frame size, heat-transfer area, cable length or structural dimensions.
    4. The CPQ system resolves a product structure and configurable BOM.
    5. CAD automation maps approved parameters and component selections to CAD templates or parametric models.
    6. The CAD process creates a model, drawing, PDF, neutral file or engineering package.
    7. The resulting data is reviewed, versioned and transferred to downstream systems.

    The output may be fully production-ready, suitable for engineering review, or only a sales visualization. These are different levels of automation and should not be treated as equivalent.

    How manufacturing CPQ differs from generic sales CPQ

    Generic sales CPQ often focuses on selecting options, calculating price and producing a proposal. Manufacturing CPQ may include those functions, but it also represents product structure, engineering constraints, component relationships, calculations, manufacturing data and downstream system identifiers.

    Capability Generic sales CPQ Manufacturing CPQ with CAD automation
    Configuration Guided selection of sellable options Technical configuration with dependencies, constraints and engineering parameters
    Pricing Prices, discounts and approvals Pricing linked to materials, labor, operations, calculated dimensions and sourcing rules
    Product output Quote or proposal Configuration, BOM, calculations, CAD files and production documentation where supported
    Engineering handoff Often a manual request or summary Structured, validated data with model references, revisions and exception status
    Workflow Sales approval Sales, engineering, manufacturing, ERP, PLM, PDM and sometimes MES coordination

    CAD automation does not eliminate engineering responsibility. It moves repeatable design decisions into a controlled system and reserves expert review for exceptions, new designs, unusual loads, regulatory questions or configurations outside the approved model.

    Reference architecture for CPQ CAD automation

    A practical architecture normally contains several cooperating layers. They may be delivered by one platform or by multiple systems connected through application programming interfaces (APIs), files, queues or middleware.

    1. Sales and user interface layer

    This is where a salesperson, dealer, distributor, engineer or customer enters requirements. Inputs may include product family, dimensions, performance targets, materials, environment, compliance requirements, accessories and delivery preferences.

    The interface should expose meaningful engineering inputs without requiring users to understand every internal part number. For example, a buyer may specify a required airflow and available installation space rather than selecting a fan motor and housing part number directly.

    2. Product model and rules engine

    The product model defines products, features, options, components, parameters and relationships. A rules engine evaluates dependencies and constraints. Rules may state that a stainless-steel wetted path is required for a specified chemical, that a motor must meet a voltage requirement, or that a frame cannot support a selected impeller diameter.

    Rules-based configuration uses explicit conditions such as if-then logic. Constraint-based configuration describes allowable relationships and lets the engine find valid combinations. Guided selling recommends suitable products based on user requirements but may not provide complete engineering validation. These approaches can coexist, but they solve different problems.

    More detail on options, dependencies and validation is available in the product configuration guide.

    3. Calculation and engineering logic layer

    Calculations convert requirements into design values. Examples include pressure-drop calculations for piping assemblies, thermal calculations for heat exchangers, load calculations for lifting equipment, enclosure sizing for electrical systems and power or torque calculations for machinery.

    Calculation results may control both commercial and technical outputs. A calculated motor size can affect price, energy classification, BOM selection, mounting geometry and the drawing title block. Calculations should have defined inputs, units, valid ranges, formulas, tolerances and test cases.

    4. CAD automation layer

    The CAD layer applies configuration data to parametric parts, assemblies, templates or design rules. Automation may change dimensions, suppress or activate features, select components, create configurations, place standard parts, generate views and populate drawing metadata.

    Some implementations use native CAD automation through an API. Others use a separate engineering configurator, a rules-based design automation application, a CAD server or a file-generation service. The integration method affects licensing, performance, security, concurrency and the level of control available to engineering.

    5. BOM and manufacturing data layer

    The system may generate a configurable BOM, an engineering bill of materials (EBOM) or a manufacturing bill of materials (MBOM). An EBOM describes the product from an engineering perspective. An MBOM describes how the product is assembled or manufactured, including operations, work centers, consumables or manufacturing-specific structure. A configurable BOM represents the possible or selected structure before it is resolved for a specific order.

    CAD structure and manufacturing structure are related but are not always identical. A CAD assembly may contain reference geometry, fasteners or design groupings that should not appear in the MBOM. Conversely, manufacturing may require packaging, routing or consumable items that are not represented as modeled CAD components.

    The BOM, pricing and quoting guide explains these relationships in more detail.

    6. Document and enterprise integration layer

    Approved results may be sent to ERP for order processing, inventory, purchasing and production control; to PLM for product definitions and revisions; to product data management (PDM) for CAD files and document control; to customer relationship management (CRM) for opportunity and account context; or to manufacturing execution systems (MES) for shop-floor execution.

    These systems are not interchangeable. CRM manages customer and opportunity information. ERP manages business transactions and resource planning. PLM governs product lifecycle information. PDM commonly manages CAD files and revisions. MES manages manufacturing execution. CAD creates or modifies design data. A robust architecture defines which system owns each data object.

    End-to-end data flow: from sales inputs to drawings

    The most reliable implementations treat the process as a sequence of controlled transformations rather than a single button that produces a drawing.

    Step 1: Capture requirements

    The user enters requirements using business terminology. For a configured conveyor, this could include belt width, conveyor length, incline angle, product weight, throughput, environmental conditions, guarding and discharge direction.

    Step 2: Normalize and validate inputs

    The system converts units, checks ranges and identifies missing information. A length may be entered in millimeters while a legacy engineering formula expects meters. Unit conversion and precision rules must be explicit because small errors can affect both design and price.

    Step 3: Resolve configuration rules

    The engine selects valid options and rejects invalid combinations. For example, a high-temperature seal may require a specific material, exclude a standard elastomer and change the allowable operating speed.

    Step 4: Run engineering calculations

    Calculation services derive design parameters. The system should retain the calculation inputs, outputs, formula version and result status. This creates traceability when engineering reviews the design or a customer changes a requirement.

    Step 5: Resolve the product structure

    The configured product is mapped to component identifiers, quantities, descriptions, revisions and attributes. The result may include purchased parts, manufactured parts, optional accessories, raw materials and labor or operation references.

    Step 6: Generate CAD and documents

    CAD automation applies parameters to approved templates and assemblies. It may generate a 3D assembly, detail drawings, an arrangement drawing, a dimensional outline, a neutral exchange file or a PDF. Drawing metadata should be populated from governed product data rather than manually retyped.

    Step 7: Apply review and release controls

    Not every generated file should immediately become a released production document. The workflow may route results to an engineer for review, check model validity, compare against tolerances and assign a revision. A standard product may follow automatic release rules, while an ETO configuration may require detailed engineering approval.

    Step 8: Transfer the approved package

    The approved configuration, BOM, drawings and identifiers are sent to the relevant enterprise systems. The order should retain a reference to the exact configuration and design revision used to create the quote and production data.

    Industrial example: configuring a centrifugal pump

    Consider a pump manufacturer selling a configurable centrifugal pump. A sales engineer enters flow rate, differential pressure, fluid type, temperature, suction and discharge connection, materials, motor voltage, seal type, base arrangement and accessories.

    The CPQ model may use those inputs to select a pump family and impeller range. A calculation determines an appropriate impeller diameter and motor rating. Rules prevent a material from being selected when it is incompatible with the fluid or temperature. The product structure then resolves the casing, impeller, shaft, seal, motor, coupling, base and fasteners.

    CAD automation can update the pump assembly, place the selected motor, adjust the base dimensions, set connection orientation and generate an outline drawing. The resulting BOM may support ERP costing and purchasing, while the drawing may be sent to PLM or PDM for review and release.

    There are important boundaries. If the selected duty point falls outside the validated pump family, the system should not create a falsely precise drawing. It should flag the configuration for engineering review or route it into an engineer-to-order (ETO) process.

    CAD output levels and their limitations

    Output level Typical use Important limitation
    Sales visualization Help a customer understand appearance, orientation or major options May not contain manufacturing detail or verified dimensions
    Configured 3D model Support design review, layout and selected-product representation May require engineering validation before release
    Outline or arrangement drawing Provide installation dimensions and interface information May omit detail drawings, tolerances and manufacturing instructions
    Production drawing package Support manufacturing or procurement Requires controlled templates, revision management, validation and release governance
    Neutral CAD export Exchange geometry with customers or downstream tools Can lose parametric history, metadata or design intent

    A generated drawing is not automatically a manufacturing-ready drawing. Production documentation may require tolerances, weld symbols, surface finishes, inspection requirements, material specifications, revision history and approval signatures. The automation scope must state which of these are generated and which are added during engineering release.

    Benefits of connecting CPQ and CAD

    • Shorter sales-to-engineering handoff: structured parameters reduce re-entry from emails, spreadsheets and handwritten notes.
    • Fewer configuration errors: rules can prevent incompatible options before an order reaches engineering.
    • More consistent designs: approved templates and calculations reduce variation between engineers.
    • Faster quotation of engineered products: dimensions, components and calculations can contribute to cost and price.
    • Better customer communication: a configured model or drawing can clarify interfaces, orientation and space requirements.
    • Improved traceability: the organization can relate requirements, configuration, BOM, CAD revision and quote.
    • Reduced repetitive engineering work: engineers spend less time rebuilding standard or repeatable variants.

    Key implementation challenges

    Product model complexity

    Product options are often documented inconsistently across CAD files, spreadsheets, ERP records and engineering knowledge. Before automation, the manufacturer must define product families, parameters, valid ranges, dependencies and ownership.

    Rule ownership and change control

    Rules affect design, cost, lead time and customer commitments. Engineering, product management, manufacturing and commercial teams should agree who can create, approve, test and retire rules.

    CAD template quality

    Automation magnifies weaknesses in templates. Unstable references, unmanaged file names, hard-coded dimensions and inconsistent metadata can cause failures at scale. CAD models intended for automation need predictable interfaces and documented parameters.

    Revision and configuration identity

    A quote may be revised after a drawing is generated. The implementation must identify the configuration version, calculation version, CAD template revision and released document revision. Otherwise, the organization may manufacture from a different design than the one priced.

    Performance and exception handling

    CAD generation can be computationally expensive, particularly for large assemblies or multiple quote alternatives. The architecture should define queues, timeouts, retries, error messages and manual fallback procedures.

    ETO boundaries

    Configure-to-order (CTO) selects from predefined and validated choices. Engineer-to-order creates or substantially modifies a design for a specific order. Make-to-order (MTO) triggers production after an order but may use a relatively standard product. Assemble-to-order (ATO) combines stocked modules after an order. CAD automation is usually most predictable for CTO and repeatable MTO products, while ETO requires stronger exception management and engineering review.

    See the manufacturing workflows guide for a comparison of CTO, ETO, MTO and ATO processes.

    Implementation approach

    1. Select a narrow product family: begin with a product that has repeatable variants, meaningful configuration volume and reasonably stable CAD templates.
    2. Document the current process: map sales inputs, engineering calculations, CAD steps, BOM creation, approvals and system handoffs.
    3. Define system ownership: decide where product attributes, prices, CAD files, revisions, customers and manufacturing structures are maintained.
    4. Separate rules from presentation: keep validation and engineering logic distinct from screen layout where possible.
    5. Build a parameter contract: define names, units, data types, ranges, defaults, allowed values and ownership for every value passed to CAD.
    6. Automate the BOM deliberately: document how CAD structure, EBOM, MBOM and ERP item records relate.
    7. Test abnormal cases: include minimum and maximum dimensions, incompatible materials, missing data, obsolete components and failed CAD generation.
    8. Introduce engineering gates: define when output is automatically accepted, when it requires review and when it must become an ETO request.
    9. Measure operational results: monitor configuration error rates, engineering touch time, drawing cycle time, exception volume and revision-related rework.

    The CPQ implementation guide covers governance, migration, testing, deployment and maintenance. Integration decisions are discussed in the CPQ integration guide.

    How to evaluate a CPQ CAD automation capability

    When assessing software, do not rely on a feature label such as CAD integration. Ask for a demonstration using representative product data and verify the complete path from input to released output.

    • Can the system represent dimensions, formulas, constraints and engineering dependencies?
    • Does it generate only visual output, or can it create controlled CAD and drawing files?
    • Which CAD systems, file types and automation interfaces are supported?
    • Can the system work with assemblies, configurations, family tables, templates and metadata?
    • How are CAD errors reported and resolved?
    • Can it generate a configurable BOM, EBOM or MBOM, and how are those structures reconciled?
    • How are revisions, approvals and configuration snapshots managed?
    • Can engineers override or review generated results without losing traceability?
    • How does the platform handle ETO exceptions?
    • What is native functionality and what requires custom development, middleware or a separate engineering tool?

    Use the manufacturing CPQ comparison resources and CPQ software profiles to structure vendor research, but verify every capability against current product documentation and a product-specific proof of concept.

    Semantic map

    The following relationships summarize the entities and data flow discussed in this guide:

    • Sales requirements lead to a product configuration.
    • Configuration rules prevent invalid product combinations.
    • Engineering calculations derive design parameters.
    • A valid configuration resolves a configurable BOM.
    • CAD automation applies parameters to templates and assemblies.
    • CAD automation generates product-specific models and drawings.
    • An EBOM describes the engineered product structure.
    • An MBOM describes the manufacturing structure and operations.
    • PLM governs product lifecycle information and revisions.
    • PDM manages CAD files and document versions.
    • ERP uses approved product and order data for planning and transactions.
    • ETO exceptions require engineering review beyond the standard configuration model.

    FAQ

    1. What is CPQ CAD automation?

    It is the automated use of validated CPQ configuration data to create or modify CAD models, assemblies, drawings or related engineering outputs for a configured manufactured product.

    2. Does every CPQ system generate production drawings?

    No. Some CPQ systems only manage options, pricing and quotes. CAD generation may require a dedicated integration, engineering configurator, CAD automation tool or custom development.

    3. What inputs are needed for CAD automation?

    Typical inputs include product family, dimensions, materials, performance values, component selections, interface requirements, calculated parameters and document metadata. Each input needs a defined unit, type and valid range.

    4. Can CPQ create a 3D model?

    Some manufacturing CPQ solutions can create or drive 3D models, while others only display prebuilt visualizations or pass data to an external CAD system. The distinction must be verified for the target CAD platform.

    5. Is a 3D sales configurator the same as CAD automation?

    No. A 3D configurator may change visual options for customer communication. CAD automation changes engineering geometry, parameters or documents and may require much stricter validation.

    6. Can CPQ generate a BOM?

    Some systems generate a configurable BOM or resolved product BOM. Whether that output is an EBOM, MBOM or ERP-ready structure depends on the data model and integration design.

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

    An EBOM represents the product as designed. An MBOM represents how the product is assembled or manufactured, including manufacturing-specific structure, operations or consumables.

    8. How does CAD automation reduce engineering work?

    It automates repeatable tasks such as selecting standard components, changing dimensions, positioning assemblies, creating views and populating drawing metadata. It does not replace engineering judgment for novel or exceptional designs.

    9. Can CAD automation support engineer-to-order products?

    It can support repeatable portions of an ETO process, but fully bespoke designs generally require engineering review, additional modeling and controlled exception management.

    10. How are engineering calculations connected to CAD?

    Calculation results are stored as controlled parameters and passed to CAD automation. For example, a calculated shaft diameter or frame length may drive model dimensions, component selection and drawing annotations.

    11. What happens if the configuration is technically invalid?

    The rules engine should block the combination, explain the conflict and request a valid alternative. If the requirement is outside the modeled range, it should route the case to engineering rather than generate an unsupported design.

    12. Which system should own the CAD file?

    Usually a PDM or PLM system owns controlled CAD documents and revisions, although the exact architecture varies. CPQ should normally reference the approved design rather than become the uncontrolled master repository.

    13. How does CPQ CAD automation connect to ERP?

    CPQ may send the configured item, BOM, quantities, prices, costs, lead-time attributes and document references to ERP. The interface must define identifiers, revisions, status and ownership for each data object.

    14. Can CAD automation calculate product price?

    It can provide dimensions, materials, components or operations that support costing. Price calculation normally belongs to the CPQ pricing layer, while CAD supplies selected engineering facts.

    15. What CAD files can be generated?

    Depending on the tools involved, outputs may include native part or assembly files, 2D drawings, PDFs, STEP or other neutral formats. Supported file types and metadata behavior must be verified for each implementation.

    16. How should generated drawings be approved?

    Use defined review and release gates. Standard validated configurations may follow automated checks, while new, high-risk or out-of-range designs should receive engineering approval before production release.

    17. What is the biggest implementation risk?

    A common risk is automating inconsistent product data and unstable CAD templates. The project should first establish a governed product model, clear rules, reliable templates and testable interfaces.

    18. How should manufacturers start a CPQ CAD project?

    Choose a repeatable product family, map the current sales-to-engineering process, define input and output ownership, build a limited proof of concept and test normal, boundary and exception configurations before expanding scope.

    Related guides