CPQ Guide

Tag: CAD automation

  • Common CPQ Integration Patterns

    CPQ integration connects Configure, Price, Quote software with the systems that hold customer, product, engineering, commercial and manufacturing data. In manufacturing, CPQ may exchange configuration rules, product options, dimensions, prices, costs, bills of material, drawings, customer records, inventory data and sales orders with other enterprise applications.

    The most common pattern is a CPQ application positioned between customer-facing sales channels and operational systems. A CRM system may initiate an opportunity, CPQ validates the configurable product and calculates the quote, PLM or PDM supplies released engineering data, CAD automation creates product-specific outputs, and ERP receives the approved order, pricing and manufacturing data. The exact design depends on which capabilities the CPQ platform provides and which system owns each data domain.

    CPQ should not be treated as a replacement for enterprise resource planning (ERP), product lifecycle management (PLM), customer relationship management (CRM), computer-aided design (CAD) or manufacturing execution systems (MES). It is an orchestration and decision point in the manufacturing technology stack, but it should not automatically become the master for every type of data.

    What is a CPQ integration pattern?

    A CPQ integration pattern is a repeatable architectural approach for exchanging data and coordinating actions between CPQ and another system. The pattern describes the direction of data flow, the trigger, the interface technology, the system responsible for each record and the response when an integration fails.

    For example, a CRM-to-CPQ pattern may create a quote from an opportunity. A PLM-to-CPQ pattern may publish released product options and engineering rules. A CPQ-to-ERP pattern may send an approved configuration, price, customer information and order lines for order entry. These are different integrations even when they use the same API platform.

    Manufacturing CPQ integrations commonly support four related activities:

    • Configuration: validating options, dimensions, materials, capacities, motors, accessories and dependencies.
    • Engineering: performing calculations, selecting components, generating a configurable bill of material (BOM), or requesting CAD outputs.
    • Commercial processing: calculating cost, price, discounts, margins, currencies, taxes and approvals.
    • Order and production handoff: transferring an approved configuration and its identifiers to ERP, MES, PLM, PDM or production systems.

    The main systems connected to manufacturing CPQ

    System Typical responsibility Typical CPQ integration
    CRM Accounts, contacts, opportunities and sales activities Creates configuration sessions, quotes and commercial status updates
    ERP Items, customers, inventory, orders, purchasing, finance and fulfillment Provides item and commercial data; receives approved quotes or sales orders
    PLM Product lifecycle, revisions, releases and engineering change processes Publishes approved product structures, options and revisions
    PDM Engineering files, CAD documents, metadata and design relationships Provides or receives CAD documents and product-specific files
    CAD Geometry, assemblies, models and drawings Receives parameters and returns models, drawings or calculated properties
    MES Shop-floor execution, work instructions and production tracking Receives production-relevant configuration or routing information where supported
    PIM Product information and channel content Provides descriptions, images and publishable option information
    API and integration platform Transport, transformation, orchestration, monitoring and security Connects CPQ to multiple systems through APIs, events or files

    These responsibilities often overlap in practice. For example, an ERP may contain sellable item masters while PLM owns engineering revisions, and a CPQ product model may contain the commercial rules needed to present those items to a user. The integration must define how these records relate rather than assuming that one system contains the complete product definition.

    Common CPQ integration patterns

    1. CRM-embedded CPQ

    In a CRM-embedded pattern, users open CPQ from an opportunity, account or quote record in the CRM. The CPQ session receives customer, currency, territory, sales channel and opportunity information. The resulting quote, status, value and approval state are written back to the CRM.

    This pattern is useful when sales teams manage the commercial process in CRM but need a more capable manufacturing configuration model. A sales engineer might select a pump package, enter flow and pressure requirements, choose motor voltage and materials, and return a validated quote to the opportunity.

    The main design question is whether the CRM quote is the commercial system of record or whether CPQ owns the detailed quote and CRM stores only a reference and summary. Duplicating every configuration line in both systems increases synchronization risk.

    2. ERP-centered CPQ integration

    In an ERP-centered pattern, CPQ exchanges item, customer, pricing, availability and order data with the enterprise resource planning system. CPQ may use ERP item numbers and price lists while adding configuration logic that ERP does not support.

    After approval, CPQ can send an order-ready payload containing the configured item, component lines, quantities, selected options, prices, delivery details and references to documents. ERP then handles order management, purchasing, inventory, financial processing and fulfillment.

    This pattern works well for configure-to-order (CTO) products with stable item masters and repeatable manufacturing structures. It becomes more complex when the configuration creates new engineered items, requires a nonstandard BOM, or needs a CAD-derived drawing before the order can be accepted.

    3. PLM or PDM product-data synchronization

    In a PLM-to-CPQ pattern, product lifecycle management supplies released product definitions, revisions, options, attributes and engineering relationships. Product data management (PDM) may provide CAD files and document metadata.

    CPQ normally should not expose unreleased engineering alternatives or obsolete revisions. A controlled publication process can extract only approved options, valid dates, compatible components and customer-facing descriptions. CPQ then adds the rules needed for selling and configuring those choices.

    For example, PLM may define that a particular impeller revision is released for a pump family. CPQ may apply the commercial and application rule that the impeller is available only for certain flow ranges, materials and shaft arrangements.

    4. CAD automation and engineering-service integration

    Some manufacturing CPQ environments connect to CAD or an engineering calculation service. CPQ sends parameters such as length, width, capacity, nozzle location, motor size or mounting arrangement. The CAD service may return a 3D model, 2D drawing, mass properties, calculated dimensions or a document identifier.

    This is particularly relevant to engineer-to-order (ETO) and complex configure-to-order products. It is not a standard capability of every CPQ system. Where CAD automation is available, the integration must define parameter mapping, units, tolerances, file formats, revision control, processing time and failure handling.

    A useful implementation separates the commercial configuration from the CAD generation job. The user can receive an immediate configuration result while a background engineering service generates documents. The quote should clearly indicate whether a drawing is preliminary, automatically generated, or subject to engineering approval.

    See the CAD and engineering automation guide for related design automation patterns.

    5. Configurable BOM and manufacturing handoff

    CPQ may generate a configurable BOM from the selected options. A BOM is a bill of material: the components, subassemblies and quantities required for a product. The output may be a sales BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), or a reference used to create one of these structures elsewhere.

    An EBOM represents an engineering view of the product. An MBOM represents how the product is assembled or manufactured. They are related but not interchangeable. CPQ may generate neither directly, may generate a sales or configurable BOM, or may trigger ERP or PLM to create a controlled downstream structure.

    For example, selecting a stainless-steel pump, a 15 kW motor and a particular seal arrangement could generate component requirements and an engineering reference. ERP or PLM may then apply manufacturing-specific operations, phantom assemblies, packaging items and plant-specific substitutions.

    The integration should identify whether CPQ sends component item numbers, quantities, effectivity dates, option codes, configuration identifiers or a complete structure. It should also define how revisions and substitutions are handled.

    6. Event-driven integration

    In an event-driven pattern, systems publish events such as ConfigurationCompleted, QuoteApproved, ProductRevisionReleased or OrderCreated. Other systems subscribe and perform related actions.

    For example, approval of a quote could publish an event that triggers document generation, updates the CRM opportunity, reserves a configuration identifier and starts an ERP order process. Event-driven integration reduces direct dependencies between applications, but it requires reliable event delivery, idempotency, monitoring and a way to reconcile missed or duplicated events.

    Events are usually best for business state changes rather than large product-data transfers. A QuoteApproved event may contain an identifier and status, while the receiving system retrieves the detailed quote through an API.

    7. API-led and integration-platform patterns

    API-led integration exposes reusable interfaces for customers, products, configuration sessions, prices, quotes, documents and orders. An integration platform may transform data, route messages, manage authentication, retry failed calls and record audit information.

    A common architecture uses separate APIs for system access, business capabilities and user channels. For instance, a dealer portal, an ecommerce configurator and an internal sales application may all call the same CPQ configuration service while using different interfaces.

    This approach supports headless CPQ, where the configuration and pricing services are separated from the presentation layer. It can also reduce point-to-point connections, although it introduces governance requirements for API versions, schemas, access rights and service ownership.

    8. Batch and file-based integration

    Not every integration needs real-time APIs. Scheduled files may be appropriate for price lists, item catalogs, product attributes, inventory snapshots, dealer updates or legacy ERP interfaces.

    Batch integration is easier to introduce in some environments, but it creates latency. A price change may not reach CPQ until the next scheduled load. A product revision may remain available after it has been withdrawn from engineering. File-based processes therefore need effective dates, validation reports, rejected-record handling and reconciliation.

    9. Dealer, distributor and ecommerce integration

    Manufacturers often expose CPQ to dealers, distributors or self-service customers. A dealer portal may authenticate users, apply channel pricing, limit visible options and submit configurations for internal review. Ecommerce may use CPQ services to configure a product before creating a cart or order.

    These channels require more than a product catalog. They may need customer-specific price lists, regional availability, channel permissions, lead-time logic, document generation and a controlled handoff to internal sales or engineering teams.

    Data ownership is the central integration decision

    Many CPQ integration failures result from unclear ownership rather than unsuitable technology. Before building interfaces, assign a system of record for each data domain.

    Data domain Possible system of record Questions to resolve
    Customer and account CRM or ERP Which system owns identity, credit status and account hierarchy?
    Released engineering product PLM or PDM Which revisions and effectivity dates may CPQ publish?
    Configuration rules CPQ, PLM or a governed rules repository Who owns compatibility, dependency and validation logic?
    Sellable item and inventory ERP How are item numbers, availability and substitutions exposed?
    Cost ERP, costing system or CPQ Which costs are estimated, standard, plant-specific or contractual?
    Customer price ERP, CPQ or commercial pricing system How are discounts, currencies, approvals and validity dates controlled?
    CAD files and drawings PDM, PLM or CAD system How are generated documents versioned and approved?
    Manufacturing structure ERP, PLM or MES Does CPQ create an MBOM or only provide configuration inputs?

    CPQ may calculate a result without owning the underlying master data. For example, it can use an ERP price list to calculate a quote while retaining a snapshot of the price used at the time of quoting. That snapshot is important for auditability when the ERP price changes later.

    Choosing synchronous, asynchronous or batch communication

    Synchronous integration waits for an immediate response. It is suitable for checking customer status, validating an option, retrieving a current price or confirming whether an item exists. The user experience depends on the response time and availability of the connected system.

    Asynchronous integration submits a request and processes the result later. It is better for CAD generation, complex engineering calculations, large BOM creation or document rendering. The interface should show job status and provide a clear error or retry path.

    Batch integration processes records on a schedule. It is often suitable for large catalogs and legacy systems, but not for decisions that require current availability or real-time approval.

    Requirement Often suitable pattern Primary risk
    Validate a motor and voltage combination Synchronous API Slow or unavailable dependency blocks configuration
    Generate a product-specific drawing Asynchronous job Unclear status or failed document generation
    Load thousands of item descriptions Batch file or bulk API Stale or partially rejected data
    Notify systems that a quote was approved Business event Duplicate or missed event processing

    Integration design considerations for manufacturing

    Product model and rule synchronization

    Configuration rules include required options, exclusions, dependencies, ranges and calculations. A rule such as a pump motor needing to meet a calculated power requirement may not be represented by a simple item catalog. Decide whether the rule is maintained in CPQ, derived from engineering data, or shared through a governed rule service.

    Rules should be versioned with the product model. Testing must cover valid combinations, invalid combinations, boundary values, units and product revisions.

    Identifiers, revisions and effectivity

    Use stable identifiers for products, options, components, configurations and documents. Separate internal identifiers from display names. Every integration should define revision behavior and effective dates. A quote created under revision A should not silently become revision B because a later synchronization replaced the product model.

    Units, currencies and precision

    Industrial products use dimensions, flow rates, pressures, temperatures, loads and electrical ratings. Interfaces must define units and conversion rules. The same discipline applies to currencies, tax treatment, rounding, decimal precision and currency conversion dates.

    Errors, retries and reconciliation

    Integration errors should be visible to the responsible team. A failed ERP order, unavailable CAD service or rejected item should not leave CPQ showing a completed handoff. Use correlation IDs, structured error messages, retry rules and reconciliation reports. Idempotency is important: retrying the same approved quote should not create duplicate orders.

    Security and auditability

    Restrict access by user, channel, plant, product family and action where necessary. Record who changed a configuration, which product revision was used, which price was applied and when the quote was approved. Dealer and customer-facing interfaces require especially careful protection of cost, margin, engineering documents and internal options.

    Benefits and limitations of CPQ integration

    Well-designed integration can reduce rekeying, preserve configuration context, shorten sales-to-engineering handoff, improve price consistency and provide production teams with more reliable order information. It can also make product changes easier to govern because released data and selling rules move through defined publication processes.

    Integration does not automatically fix poor product data or inconsistent processes. Common limitations include duplicate product models, unclear ownership, legacy systems without suitable interfaces, slow engineering services, incomplete BOM mappings and conflicting revision schemes. A highly connected architecture can also become difficult to test if every change requires coordinated releases across several applications.

    A practical implementation sequence

    1. Map the workflow: document how a product moves from lead or opportunity through configuration, quote, approval, order and production.
    2. Inventory data: identify product options, rules, item numbers, prices, costs, BOMs, drawings, customers and revisions.
    3. Assign ownership: decide which system creates, approves, changes and publishes each data domain.
    4. Define the minimum payload: include only the identifiers and values required by the receiving system, plus configuration and revision references.
    5. Select the interaction style: choose synchronous APIs, asynchronous jobs, events or batch transfers based on timing and volume.
    6. Build a vertical slice: test one representative product family from configuration through an approved order or engineering handoff.
    7. Test exceptions: include invalid combinations, unavailable items, price changes, revision changes, duplicate messages, timeouts and partial failures.
    8. Establish governance: manage API versions, product releases, rule ownership, monitoring, support procedures and regression testing.

    The manufacturing CPQ integrations guide provides broader coverage of ERP, CRM, PLM, PDM, CAD, MES, PIM and API connectivity. Product model and rule design are covered in the product configuration guide, while BOM, costing and quote data are discussed in the BOM, pricing and quoting guide.

    Semantic map

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

    • CPQ connects customer-facing channels with manufacturing systems.
    • CRM provides opportunities and customer context to CPQ.
    • PLM publishes released product definitions to CPQ.
    • PDM manages engineering documents and CAD metadata.
    • Configuration rules prevent invalid product combinations.
    • CPQ calculates prices from products, costs, rules and commercial policies.
    • Configured products can generate configurable BOM data.
    • CAD automation generates product-specific drawings and models.
    • ERP receives approved order and commercial information.
    • MES may receive production-relevant configuration data.
    • Events communicate business state changes between systems.
    • Data ownership governs which system creates and changes each record.

    Frequently asked questions

    1. What is CPQ integration in manufacturing?

    It is the exchange of product, configuration, engineering, pricing, customer, quote and order data between CPQ and systems such as ERP, CRM, PLM, PDM, CAD and MES.

    2. Does CPQ replace ERP?

    No. CPQ may calculate a configuration and quote, while ERP usually manages items, inventory, orders, purchasing, finance and fulfillment. Some CPQ platforms can perform functions that overlap with ERP, but the systems have different primary responsibilities.

    3. How does CPQ integrate with CRM?

    CRM typically provides the opportunity, customer, territory and sales context. CPQ creates or manages the detailed configuration and quote, then returns status, value, documents and references to CRM.

    4. How does CPQ integrate with ERP?

    CPQ may retrieve items, prices, availability and customer data from ERP and send an approved configuration, quote or sales order back to ERP.

    5. Should ERP or CPQ own pricing?

    There is no universal answer. ERP may own standard prices and financial data, while CPQ may apply configuration-dependent pricing, discounts and approvals. The ownership, validity dates and price snapshot must be explicit.

    6. Can CPQ integrate with PLM?

    Yes, where both systems provide suitable interfaces. PLM can publish released products, revisions and engineering relationships, while CPQ applies selling and configuration logic to those products.

    7. Is PDM the same as PLM?

    No. PDM primarily manages engineering files, CAD documents and related metadata. PLM generally covers a broader product lifecycle, including revisions, releases, changes and product structures.

    8. Can CPQ generate a BOM?

    Some manufacturing CPQ platforms can generate a configurable or sales BOM, but this is not universal. Buyers should verify whether the output is an EBOM, MBOM, sales BOM or input for another system.

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

    An EBOM is an engineering view of product components. An MBOM is a manufacturing view organized for assembly or production. CPQ output may need transformation before it becomes an MBOM.

    10. When should CAD integration be asynchronous?

    Use asynchronous processing when CAD generation, engineering calculations or document creation may take significant time or depend on an external service.

    11. What is an event-driven CPQ integration?

    It uses business events such as QuoteApproved or ProductRevisionReleased to notify other systems that a state change has occurred. Subscribers then retrieve data or perform related actions.

    12. Are batch files suitable for CPQ integration?

    They can be suitable for large catalog, price or item updates and for legacy systems. They are less suitable when CPQ requires real-time availability, current pricing or immediate validation.

    13. What should a CPQ order payload contain?

    It may contain customer and delivery references, configuration ID, product and revision IDs, option values, quantities, prices, discounts, BOM references, documents and approval status.

    14. How should product revisions be handled?

    Store the revision used by each configuration and quote. Do not silently replace it with a newer revision. Define effectivity dates and rules for reconfiguration or engineering review.

    15. What causes CPQ integration failures?

    Common causes include unclear data ownership, inconsistent identifiers, duplicate product models, missing units, unsupported legacy interfaces, incomplete BOM mappings, unhandled timeouts and poor revision control.

    16. Is an integration platform required?

    No. Direct APIs may be sufficient for a small number of stable connections. An integration platform becomes more useful when transformation, routing, monitoring, retries and many connected systems are required.

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

    CPQ can capture requirements, apply known rules, estimate price and trigger engineering calculations or CAD generation. It should not be assumed to replace engineering approval for genuinely new designs.

    18. What should manufacturers test before go-live?

    Test valid and invalid configurations, boundary values, prices, revisions, BOMs, CAD jobs, order creation, duplicate messages, system outages, security permissions and rollback or recovery procedures.

  • REST APIs for Product Configuration in Manufacturing CPQ

    REST APIs for product configuration connect a manufacturing CPQ system with the applications that manage product data, customers, engineering, production and commercial transactions. A configurator can receive product options from a web application or CRM, validate the selections against engineering rules, calculate price and cost, and return a configured product, bill of materials (BOM), quote or engineering request through an API.

    In manufacturing, a REST API is not simply a way to submit a list of sales options. The API may need to represent dimensions, materials, motors, electrical ratings, performance calculations, revision-controlled components, manufacturing structures and the distinction between a standard configured product and an engineer-to-order design. The quality of the product model and ownership of data are therefore as important as the API technology itself.

    This article explains where REST APIs fit in a manufacturing CPQ architecture, which resources and operations are commonly required, how CPQ exchanges data with enterprise systems, and what implementation risks buyers and project teams should evaluate. For a broader introduction, see the guide to CPQ integrations and the manufacturing CPQ guide.

    What is a REST API for product configuration?

    A REST API for product configuration is a web-based application programming interface that lets software systems create, read, validate, update and complete configurations of configurable products using standard HTTP requests and structured data, commonly JSON.

    REST, or Representational State Transfer, is an architectural style in which clients interact with resources through operations such as GET, POST, PUT, PATCH and DELETE. In a manufacturing CPQ environment, resources may include product models, options, rules, configuration sessions, configured products, prices, quotes, BOMs, documents and engineering requests.

    The API separates the user interface from the configuration engine. A dealer portal, CRM screen, ecommerce application, mobile application or custom engineering tool can call the same configuration services instead of reproducing product rules in each application. The CPQ system remains responsible for the rules and calculations that it owns, while ERP, PLM, CAD and other systems remain authoritative for the data they own.

    How REST APIs fit into a manufacturing CPQ architecture

    A manufacturing CPQ architecture commonly contains several distinct layers:

    • Experience layer: sales portals, dealer applications, ecommerce, CRM screens and internal engineering tools.
    • Configuration layer: the product model, options, constraints, dependencies, calculations and validation logic.
    • Commercial layer: pricing, discounting, costing, currencies, approvals, taxes and quote generation.
    • Engineering layer: CAD automation, drawings, technical calculations, engineering review and design outputs where supported.
    • Manufacturing data layer: configurable BOMs, engineering BOMs (EBOMs), manufacturing BOMs (MBOMs), routings and production attributes.
    • Enterprise systems: customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) and product information management (PIM).

    A REST API can operate between any of these layers, but the integration should have a defined purpose. For example, a CRM may create a configuration session and receive a price, while an ERP may receive an order-ready configuration and manufacturing BOM. A PLM system may provide approved component revisions, while a CAD service may generate a product-specific drawing.

    These systems are not interchangeable. CRM generally manages accounts, opportunities and customer interactions. ERP manages orders, inventory, purchasing, production and financial transactions. PLM manages product structures, revisions and lifecycle processes. PDM focuses primarily on engineering files and product data. CAD creates geometry and drawings. MES controls or records shop-floor execution. A CPQ API integration must identify which system is authoritative for each data element.

    Typical REST API product configuration workflow

    A configuration transaction usually follows a sequence rather than a single request.

    1. Identify the product model: the client requests an available model, market version or product family and specifies a model revision or effective date.
    2. Create a configuration session: the CPQ system returns a session identifier and an initial state containing required choices, defaults and selectable options.
    3. Submit choices incrementally: the client sends values such as pump flow, pressure, material, motor voltage, enclosure rating or mounting arrangement.
    4. Validate the state: the rules engine identifies valid, invalid, required and conditionally available selections.
    5. Run engineering calculations: the system may calculate performance, capacity, dimensions, power, heat load or other values. Some implementations call an external calculation service.
    6. Calculate price and cost: the CPQ system applies price lists, regional adjustments, labor, material cost, freight assumptions, discounts and approval rules as appropriate.
    7. Generate outputs: the result may include a configured product identifier, configurable BOM, EBOM, MBOM, technical summary, CAD request, quote or order payload.
    8. Persist and transfer the result: the configuration is saved with a revision or status and transferred to CRM, ERP, PLM, MES or another downstream process.

    Not every CPQ platform performs every step. A product configuration API may only validate options and return a product code. BOM generation, CAD automation, engineering calculations and production integration must be verified as separate capabilities.

    Core API resources for a configurator

    Resource names differ between products, but a manufacturing-oriented API commonly needs concepts similar to the following.

    Resource Purpose Manufacturing example
    Product model Defines a configurable product family and its revision Horizontal centrifugal pump, model revision 2025.1
    Option or feature Represents a selectable characteristic 316 stainless steel wetted parts
    Configuration session Stores choices, state, validation messages and calculated values A pump selection for a specific customer duty point
    Rule Controls compatibility, dependency, exclusion or requirement High-temperature seal required above a defined fluid temperature
    Configured product Represents a completed or partially completed result Pump with motor, seal, baseplate and controls
    Price or cost result Returns commercial calculations and assumptions Material cost, list price, discount and margin
    BOM Returns selected components and quantities Impeller, casing, motor, coupling and fasteners
    Document or output Provides generated files or references Datasheet, quotation PDF, drawing or CAD file

    Versioning is particularly important. A request that identifies only a product family may produce different results after rules, prices or component revisions change. APIs should support explicit model versions, effective dates or configuration snapshots where repeatability matters.

    Configuration data and rules exchanged through REST

    Configuration data should distinguish between the customer’s selections, values derived by the system and messages generated by validation. For example, a customer may select a flow rate and liquid temperature. The system may derive impeller diameter and motor size, then return a warning that the selected motor requires a different electrical enclosure.

    Common rule categories include:

    • Compatibility rules: prevent combinations that cannot be assembled, such as a motor frame incompatible with a selected pump adapter.
    • Dependency rules: make one option required when another is selected, such as requiring a temperature sensor when a monitoring package is chosen.
    • Exclusion rules: remove incompatible options, such as excluding a material that is unsuitable for a specified chemical.
    • Calculation rules: derive dimensions, capacity, power, weight or component quantities from inputs.
    • Manufacturing rules: enforce minimum dimensions, available processes, standard stock sizes or plant-specific constraints.
    • Commercial rules: apply price lists, customer agreements, regional currencies or approval thresholds.

    These rules should be executed by the configuration authority rather than duplicated in a CRM, website and dealer portal. Duplicated logic creates divergent results and makes product changes difficult to govern. A client may use API responses to improve the user experience, but it should not assume that client-side filtering is sufficient validation.

    It is also useful to distinguish rules-based configuration, which evaluates explicit product logic, from constraint-based configuration, which resolves a network of allowable relationships and constraints. Guided selling is a user experience that asks business-oriented questions and recommends suitable products. Guided selling may call a rules or constraint engine, but it is not a substitute for the underlying product model.

    Example API interaction

    The following simplified sequence illustrates the separation between a configuration session and a final result. The endpoint names are illustrative; actual paths and payloads depend on the CPQ platform.

    POST /api/configuration-sessions

{
  "productModel": "industrial-pump",
  "modelRevision": "2025.1",
  "context": {
    "currency": "EUR",
    "customerId": "CUST-1042"
  }
}

PATCH /api/configuration-sessions/SESSION-782/options

{
  "flowRate": 120,
  "flowUnit": "m3/h",
  "pressure": 8,
  "wettedMaterial": "316L",
  "motorVoltage": "400V"
}

POST /api/configuration-sessions/SESSION-782/validate

GET /api/configuration-sessions/SESSION-782/outputs

    A useful validation response should identify the state, not merely return a generic error. It may include valid selections, blocking errors, warnings, derived values, rule identifiers and the affected fields. This allows a client to explain why a 400 millimetre impeller is unavailable or why a particular motor must be upgraded.

    REST APIs and BOM, CAD and engineering outputs

    Product configuration and BOM generation are related but distinct functions. A configuration may be valid without producing a complete manufacturing BOM. Some systems return a sales BOM or configurable BOM, while others create an EBOM or MBOM.

    • Configurable BOM: a structure containing alternatives, conditions or placeholders that are resolved by configuration.
    • EBOM: an engineering bill of materials representing the product from a design perspective.
    • MBOM: a manufacturing bill of materials organized for production, assembly and process execution.

    A REST API may return BOM lines directly, return an asynchronous job identifier, or return a reference to an ERP or PLM object. The response should make clear whether quantities are final, whether phantom items are included, which revisions apply and whether the structure is intended for sales, engineering or production.

    CAD integration is similarly variable. A CPQ system may pass parameters to a CAD automation service, request a drawing, retrieve a 3D model or simply store a reference to a pre-existing file. CAD automation can generate product-specific geometry and drawings, but it normally requires controlled templates, parameter mappings, naming conventions, revision handling and engineering validation. More information is available in the CAD and engineering automation guide.

    For products that require engineering review, the API should support an explicit ETO, or engineer-to-order, state. A completed configuration may create an engineering request rather than an immediately orderable product. This is different from CTO, or configure-to-order, where approved modules and rules are intended to produce a repeatable product without new design work.

    Integration patterns with ERP, PLM, CRM and other systems

    System Common API interaction Important ownership question
    CRM Starts configuration from an opportunity and receives price, summary and quote status Does CRM own the configuration or only the customer and opportunity?
    ERP Receives order-ready product data, item numbers, prices, BOMs or manufacturing attributes Which system creates the material, sales order and production structure?
    PLM Provides approved product structures, revisions and lifecycle status Which revision is valid for a quote or order date?
    PDM Provides engineering files and document metadata How are file versions linked to a configured product?
    CAD Receives parameters and returns geometry, drawings or technical documents Who validates generated design output?
    PIM Provides descriptions, images and channel-oriented product information Are marketing attributes confused with engineering attributes?
    MES Receives production-relevant configuration, instructions or identifiers Is the API sending a released manufacturing structure or only a sales result?

    Some integrations use synchronous REST calls for short operations such as retrieving options or validating a field. Long-running activities such as CAD generation, complex pricing, BOM release or ERP order creation are better handled asynchronously. The API can return a job identifier and provide a status endpoint or callback mechanism. This prevents a browser or CRM transaction from waiting indefinitely for an engineering process.

    API design considerations for manufacturing

    Use stable identifiers and external references

    Option labels can change, and translations may differ by market. Integrations should use stable identifiers for product models, options, values, revisions, units and business objects. External references can map a CPQ configuration to a CRM opportunity, ERP order, PLM change or CAD document.

    Handle units, precision and validation

    Industrial products use dimensions, pressures, temperatures, flow rates, weights and electrical values. Every numeric value should have a defined unit, precision and rounding policy. Converting 120 litres per minute to another unit is not equivalent to interpreting the number without its unit. API contracts should define accepted ranges and whether rounding occurs before or after engineering calculations.

    Make operations idempotent where appropriate

    An idempotent operation can be safely retried without creating duplicate business objects. This is important when a network failure occurs after an ERP order or quote request was submitted. Idempotency keys, correlation identifiers and clear transaction states help prevent duplicate orders, duplicate configurations and inconsistent handoffs.

    Return meaningful errors

    HTTP status codes are useful, but manufacturing users need business-level detail. A response should distinguish authentication failure, malformed data, unavailable product revision, invalid combination, missing approval and downstream ERP failure. Error messages should identify the affected field or rule without exposing sensitive implementation details.

    Separate configuration state from quote state

    A configuration can be edited many times before a quote is issued. A quote may then become versioned, approved or expired. APIs should avoid treating every configuration update as a new commercial quote and should provide clear transitions between draft, validated, priced, submitted, approved and ordered states.

    Security and governance

    REST APIs expose valuable product, customer and commercial data. Security design should include authenticated clients, authorization by role and business context, encrypted transport, rate limits, audit logs and monitoring. A dealer may be permitted to configure only products for a specific market, while an internal engineer may access more technical options.

    API governance should define who can publish product model revisions, change rules, approve price logic and retire endpoints. Product configuration changes should be tested against representative configurations, boundary values and known invalid combinations. Where rules affect safety, compliance or manufacturing feasibility, the organization should retain an audit trail showing which model revision and rule set produced a result.

    API versioning is necessary when payloads, identifiers or business behavior change. Backward compatibility is especially important for dealer portals, ecommerce applications and plant integrations that may not be upgraded at the same time as the CPQ system.

    Benefits and limitations

    Potential benefit What it requires
    One configuration service for multiple channels A maintained product model and consistent authorization
    Faster transfer from sales to engineering Structured configuration data and clear handoff states
    Fewer manual entry errors Stable identifiers, validation and controlled mappings
    More accurate pricing and costing Reliable price, cost, currency and approval data
    Automation of BOM and CAD outputs Supported downstream capabilities, templates and revision control
    Channel flexibility Well-designed APIs and clients that do not duplicate core rules

    REST APIs do not repair poor product data. If options are inconsistently named, rules are undocumented, revisions are missing or BOM ownership is unclear, an API will transfer the inconsistency faster. APIs also introduce operational dependencies: a product configuration may be blocked by an unavailable pricing service, ERP outage, expired token or incompatible model revision.

    Implementation approach

    1. Map the configuration journey: document where product selection starts, which decisions are made, and when price, engineering and production data are required.
    2. Assign data ownership: identify the authoritative source for product options, revisions, prices, customers, materials, BOMs, drawings and orders.
    3. Define the canonical configuration model: agree on identifiers, units, statuses, option values, derived values and validation messages.
    4. Design the API contract: document resources, operations, payloads, authentication, errors, versioning and synchronous versus asynchronous behavior.
    5. Build representative product slices: begin with a product family that includes real dependencies, dimensions, materials and downstream requirements.
    6. Test across systems: verify valid and invalid configurations, revision changes, prices, BOM structures, CAD outputs and ERP handoffs.
    7. Monitor and maintain: measure failures, response times, abandoned sessions, rule errors and downstream reconciliation issues.

    Implementation planning should include product data migration, governance, testing and adoption, not only endpoint development. The CPQ implementation guide covers these broader project concerns.

    REST APIs compared with other integration approaches

    REST is common because it works well with web applications and distributed systems, but it is not the only option. SOAP services may still exist in enterprise applications. GraphQL can allow clients to request specific data shapes. Messaging and event-driven integration can notify systems that a configuration was completed or an engineering job finished. Batch file exchange may remain practical for controlled ERP or manufacturing transfers.

    The correct approach depends on transaction volume, latency, reliability, existing systems and the need for immediate validation. A hybrid architecture is common: REST for interactive configuration, asynchronous messaging for long-running outputs, and scheduled reconciliation for master data.

    Semantic map

    The relationships below show how REST APIs connect product configuration with the wider manufacturing technology stack.

    • CPQ connects sales channels with product configuration and manufacturing data.
    • Product models define options, attributes, dependencies and configuration states.
    • Configuration rules prevent invalid combinations and enforce engineering constraints.
    • Configuration sessions store selections, derived values, validation messages and context.
    • Engineering calculations transform customer requirements into technical selections.
    • Configured products can generate prices, quotes, BOMs and engineering requests.
    • CAD automation can generate product-specific drawings and models when supported.
    • PLM provides approved product structures and revision-controlled engineering data.
    • ERP receives order, item, price, BOM and production-relevant information.
    • CRM provides customer, opportunity and commercial context for configuration.
    • MES consumes released manufacturing information for production execution.
    • API governance controls security, versioning, ownership, testing and auditability.

    Frequently asked questions

    1. What does a REST API do in a CPQ configurator?

    A REST API lets another application create configuration sessions, submit product choices, validate combinations, retrieve prices and request outputs such as quotes, BOMs or engineering documents.

    2. Is a REST API the same as a CPQ configurator?

    No. The configurator contains the product model, rules and calculations. The REST API is an interface that allows other applications to use those capabilities.

    3. Can a REST API generate a manufacturing BOM?

    It can if the CPQ platform supports BOM generation and exposes that function. The response should identify whether the result is a sales BOM, configurable BOM, EBOM or MBOM.

    4. Can REST APIs automate CAD drawings?

    Yes, where the CPQ and CAD architecture supports automation. The API may submit parameters, start a generation job and return a drawing or CAD-file reference, but templates and engineering validation are still required.

    5. Should product rules be stored in the CRM?

    Usually not. Core configuration rules should generally be maintained in the configuration authority so CRM, dealer and ecommerce clients receive consistent validation.

    6. How does a CPQ API connect with ERP?

    It can exchange product identifiers, customer data, prices, order lines, BOMs, configuration attributes and status information. The integration must define which system creates and owns each business object.

    7. What is the difference between a configuration session and a quote?

    A configuration session records product choices and validation state. A quote is a commercial document or transaction that may contain approved prices, terms, validity dates and customer information.

    8. Are REST APIs suitable for engineer-to-order products?

    Yes, but the API may need to create an engineering request rather than an immediately orderable product. ETO workflows require engineering status, document references, approvals and revision control.

    9. What is the difference between CTO and ETO in an API workflow?

    Configure-to-order uses approved modules and rules to produce a repeatable product. Engineer-to-order creates or modifies engineering content for a specific requirement, often through an additional review process.

    10. Should validation happen in the browser or on the server?

    Basic browser validation can improve usability, but authoritative validation should occur in the server-side configuration engine because clients can be outdated or bypassed.

    11. How should an API represent invalid product combinations?

    It should return a structured response identifying the affected fields, blocking rules, explanatory messages and any suggested valid alternatives where the platform supports them.

    12. Why are units important in product configuration APIs?

    Industrial configurations use dimensions, pressure, flow, temperature, power and weight. The API must define units and conversion rules so that identical numbers do not produce different engineering results.

    13. Should a product configuration API be synchronous?

    Short operations such as retrieving options and validating choices can be synchronous. CAD generation, complex pricing, BOM release and ERP order creation are often better handled as asynchronous jobs.

    14. How do APIs handle product revisions?

    They can use model revision identifiers, effective dates or immutable configuration snapshots. This allows an old quote or order to be traced to the rules and component revisions that produced it.

    15. What security controls are important for CPQ APIs?

    Important controls include authenticated clients, authorization, encrypted transport, rate limiting, audit logging, secret management and restrictions based on role, market, dealer or product family.

    16. Can one CPQ API serve sales, dealers and ecommerce?

    It can, if the API supports the different permissions, product visibility, pricing contexts and user experiences. The underlying product rules should remain consistent while channel-specific policies are applied separately.

    17. What is the biggest implementation risk?

    A common risk is unclear data ownership. If CPQ, ERP, PLM and CRM each contain conflicting product, price or revision data, the API may create technically successful but operationally incorrect transactions.

    18. How should REST API integrations be tested?

    Test valid and invalid configurations, boundary values, rule changes, units, revisions, price calculations, BOM results, permissions, retries, outages and reconciliation with downstream ERP, PLM or CAD records.

  • Product Master Data for Configurable Products

    Product master data for configurable products is the structured information required to define, sell, engineer, price, manufacture and support product variants. It includes product families, features, options, attributes, dimensions, materials, components, part numbers, revisions, costs, prices, configuration rules, bills of material and related engineering information.

    In manufacturing, product master data is more than a list of items and prices. A configure, price, quote (CPQ) system may need to understand whether a pump can use a particular impeller, whether a motor is suitable for a selected voltage, how a frame size changes the bill of material (BOM), and whether a configured assembly requires a new drawing or engineering review.

    The practical objective is to give each system the product information it needs without creating conflicting versions of the product model. Product lifecycle management (PLM) may own engineering definitions, enterprise resource planning (ERP) may own manufacturing and commercial item records, computer-aided design (CAD) systems may own geometry, and CPQ may use a governed subset of this information to configure and quote valid products.

    This article explains the data domains, ownership model, system relationships, implementation issues and operational controls required for reliable product master data in a manufacturing CPQ architecture.

    What is product master data?

    Product master data is the controlled, reusable information that identifies a product and describes its commercial, technical, engineering and manufacturing characteristics. It is generally more stable and structured than transactional data such as a particular quote, sales order or production order.

    For a configurable industrial product, master data commonly includes:

    • Product families, models and configuration hierarchies
    • Features, options, variants and selectable values
    • Technical attributes such as capacity, pressure, voltage, dimensions and material
    • Part numbers, descriptions, units of measure and lifecycle status
    • Option compatibility, dependency and exclusion rules
    • Engineering relationships, revisions and effectivity dates
    • Configurable BOM structures and component quantities
    • Manufacturing operations, work centers or routing references where applicable
    • Standard costs, list prices, discounts and pricing conditions
    • CAD templates, drawings, documents and design parameters
    • Supplier, sourcing, service and regulatory information

    Master data should be distinguished from product content. Product content may include sales descriptions, images, brochures and web copy. Product master data is typically more structured and operational: it determines which configurations are valid and what downstream systems must receive when a customer selects them.

    Why master data matters in manufacturing CPQ

    Generic sales CPQ can often work with a relatively simple catalog, discount table and proposal template. Manufacturing CPQ usually needs a deeper product model. The system may have to validate technical constraints, calculate performance, select components, generate a BOM and pass an order-ready definition to ERP or engineering.

    For example, consider a configurable centrifugal pump. A salesperson may select flow rate, head, fluid type, temperature, seal material, motor power, voltage, connection standard and mounting arrangement. These choices can affect one another:

    • The required impeller diameter may depend on flow and head.
    • The fluid and temperature may restrict seal and material choices.
    • Motor power may depend on calculated shaft power and efficiency.
    • Voltage and frequency may determine an eligible motor variant.
    • The selected frame and coupling may determine the baseplate and guard.
    • The final configuration may select different components in the configurable BOM.

    If the CPQ configurator contains outdated or incomplete master data, it can produce a technically invalid quote even when the interface appears to work correctly. The result may be engineering rework, an incorrect price, a delayed order or a production exception.

    Reliable master data therefore supports the full path from customer requirements to product definition, quote, order, engineering output and manufacturing execution. It is one of the foundations of manufacturing CPQ.

    Core data domains for configurable products

    Product and variant hierarchy

    The hierarchy describes how a company organizes product families, models, platforms, modules, assemblies and sellable variants. A material handling manufacturer might define a product family for conveyors, a platform for belt conveyors, models by width and length range, and optional modules for drives, guards, sensors and controls.

    The hierarchy should not be confused with every possible finished-product part number. Some organizations create a unique item number for every combination. Others use a configurable material, a sales configuration identifier or a generated engineering number. The appropriate approach depends on ERP, manufacturing, inventory, costing and traceability requirements.

    Features, options and attributes

    Features represent meaningful decisions in the configuration process, such as drive type, enclosure rating or pressure class. Options are selectable values within those features. Attributes describe characteristics of the configured product or selected component, such as length, weight, capacity or operating temperature.

    Dimensions require particular care. A dimension may be a discrete option, a numeric input within a range, a calculated value or a parameter passed to CAD. The data model should define units, precision, valid ranges, rounding rules and dependencies. A vessel diameter, for example, may be entered by an engineer but constrained by material thickness, transport limits and available forming equipment.

    Part and item master records

    An item master record identifies a component, assembly, finished product or service. It commonly includes an item number, description, unit of measure, lifecycle status, revision, planning attributes and accounting classifications.

    CPQ should not automatically become the authoritative source for every item attribute. In many architectures, ERP owns inventory, purchasing and manufacturing item data, while PLM owns engineering part definitions and revisions. CPQ may store references, synchronized attributes and configuration-specific logic rather than replace those systems.

    Rules and constraints

    Rules determine how product choices relate to one another. Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required.” Constraint-based configuration represents permitted combinations and restrictions, potentially across numeric values, capacities and engineering relationships. Guided selling asks questions and recommends choices, but a recommendation is not necessarily a technical validation.

    Typical rules include:

    • Requires: a selected option requires another option or component.
    • Excludes: two options cannot be selected together.
    • Compatibility: a component is valid only for certain models, materials or operating conditions.
    • Range: a value must remain within an allowed minimum and maximum.
    • Calculation: a value such as motor size or material thickness is derived from inputs.
    • Effectivity: a rule applies only from a specific date, revision or market.
    • Approval: a valid but unusual configuration requires engineering review.

    Rules should be treated as governed product knowledge, not merely interface behavior. They require named owners, test cases, version control and a process for handling exceptions. More detail is available in the guide to product configuration and configuration rules.

    Engineering and CAD data

    Some configurations can be assembled from standard components, while others require engineering calculations, parameterized geometry or a new drawing. CAD data may include templates, models, drawing rules, material parameters and references to standard hardware.

    CPQ may send selected parameters to a CAD automation service, which generates product-specific geometry or drawings. Alternatively, CPQ may only identify the configuration and create an engineering request. These are different capabilities and should not be assumed to exist in every CPQ platform.

    CAD and engineering data should have clear ownership and revision relationships. A CPQ option should not silently point to an obsolete drawing or an unapproved model. See CAD and engineering automation in CPQ for the relationship between configuration data and design outputs.

    BOM and manufacturing data

    A bill of material (BOM) describes the components and quantities required for a product or assembly. An engineering BOM (EBOM) represents the product from an engineering perspective. A manufacturing BOM (MBOM) organizes material and assemblies for production. A configurable BOM is a structure containing rules, alternatives or selections that resolve into a product-specific BOM after configuration.

    For a configured electrical enclosure, the selected enclosure size, circuit protection, terminals, wiring accessories and mounting plate may determine the resolved BOM. The EBOM may describe functional engineering relationships, while the MBOM may add packaging, work instructions, consumables or production-specific subassemblies.

    CPQ may generate a quote-level BOM, an order BOM, an EBOM request or an MBOM-ready structure. The exact output must be defined rather than assumed. More information is available in BOM generation, costing, pricing and quoting.

    Pricing, costing and commercial data

    Pricing data includes list prices, regional prices, customer-specific agreements, discounts, surcharges, currencies and validity periods. Costing data may include material cost, purchased component cost, labor, setup, subcontracting and overhead assumptions.

    Configuration data and pricing data are related but not identical. A selected stainless-steel material may change both the technical validity of a product and its cost. However, the price calculation may also depend on customer segment, quantity, freight, margin policy or commercial approval rules.

    Separating these concerns makes the model easier to govern. A product engineer may own material compatibility, while commercial operations owns price conditions. Both may be required before a quote can be released.

    System ownership in the manufacturing technology stack

    Product master data is usually distributed across several enterprise systems. The goal is not to force every attribute into one database, but to define authoritative ownership and reliable synchronization.

    System Typical responsibility Relationship with CPQ
    PLM Engineering product definitions, revisions, lifecycle and change control Provides approved product structures, options, revisions or engineering references
    PDM Product data management for CAD files, drawings and documents Provides controlled design files or document references where supported
    ERP Items, inventory, purchasing, manufacturing, orders, accounting and often pricing Receives order and item data; may provide commercial and operational master data
    CRM Accounts, opportunities, activities and customer-facing sales processes Uses CPQ configuration and quote results within the opportunity workflow
    CAD Parametric geometry, models, drawings and design calculations Receives configuration parameters or returns engineering outputs
    PIM Product information for channels, catalogs and digital commerce May receive approved descriptions, attributes and media for publication
    MES Manufacturing execution, work instructions, production tracking and shop-floor data May receive resolved BOMs, routings, instructions or configuration identifiers
    CPQ Configuration interaction, validation, commercial calculation and quote assembly Uses governed data and rules to create a valid commercial configuration

    The boundaries vary by organization and software architecture. For example, a CPQ platform may own the executable configuration model while PLM owns the source engineering structure. In another implementation, a product model may be authored in PLM and transformed into a CPQ-specific representation. Both approaches require explicit synchronization and change management.

    How product master data flows through a CPQ process

    1. Product definition: Engineering and product management define families, options, parameters, components and constraints.
    2. Approval and release: PLM, ERP or another governance process releases the relevant revisions and item records.
    3. Model preparation: The CPQ product model is created or synchronized, including rules, descriptions, prices and outputs.
    4. Configuration: A salesperson, dealer, engineer or customer selects requirements and options.
    5. Validation: The configurator checks dependencies, ranges, compatibility and required approvals.
    6. Calculation: The system calculates technical values, costs, prices, discounts and lead-time factors as configured.
    7. Output generation: CPQ creates a quote, proposal, configuration identifier and, where supported, a resolved BOM or CAD request.
    8. Enterprise handoff: CRM, ERP, PLM, CAD or MES receives the appropriate data through APIs, files or middleware.
    9. Order and production: The accepted configuration becomes an order, engineering package or manufacturing definition according to the selected workflow.

    This flow differs by operating model. Configure-to-order (CTO) uses predefined configurations and components. Engineer-to-order (ETO) requires engineering work for a significant portion of the product. Make-to-order (MTO) manufactures against an order, while assemble-to-order (ATO) combines stocked modules after the order. Product master data must indicate which path applies and what outputs are required.

    Data ownership and governance

    A product data governance model should answer four questions for every important field: who creates it, who approves it, which system is authoritative and which systems consume it.

    A practical ownership matrix may assign:

    • Engineering ownership of technical limits, component compatibility and design revisions
    • Product management ownership of product families, market options and lifecycle decisions
    • Manufacturing engineering ownership of production structures, routings and assembly constraints
    • Commercial ownership of price lists, discount policies and approval thresholds
    • IT or enterprise architecture ownership of interfaces, identifiers and integration monitoring
    • CPQ administration ownership of executable rules, user experience and model deployment

    Governance also requires common identifiers. Part numbers, option codes, revision codes, units of measure and effectivity dates must be mapped consistently. A description such as “high temperature seal” is not sufficient if ERP, PLM and CPQ use different codes or meanings for the same component.

    Change management is equally important. A new motor may require an ERP item, a PLM revision, a CAD update, a BOM rule change, a price update and new CPQ test cases. A release process should identify all affected systems and prevent partially updated models from being used for live quotes.

    Implementation considerations

    Start with a product data inventory

    Document the current sources of product information, including spreadsheets, ERP item masters, CAD libraries, PLM structures, price lists, dealer catalogs and engineering calculators. Identify duplicate fields, conflicting identifiers, obsolete options and undocumented rules.

    Model the configuration scope

    Do not migrate every product record into CPQ automatically. Define which product families require interactive configuration, which are sold as standard items and which require ETO review. Prioritize products where configuration errors, engineering effort or quote delays have a material operational impact.

    Separate source data from executable logic

    A source BOM or product structure may not be directly usable as a CPQ model. The CPQ implementation may need transformed options, conditional components, calculated attributes and user-facing descriptions. Document this transformation so that model maintainers can trace a rule back to its engineering or commercial source.

    Test combinations and lifecycle changes

    Testing should cover valid configurations, invalid combinations, boundary values, price changes, revisions, discontinued components, effectivity dates, currencies and integration failures. It should also verify that the resolved BOM, CAD request, quote and ERP order contain consistent identifiers.

    Plan for maintenance

    Product models are operational software assets. They need release calendars, rule ownership, regression tests, deployment controls and monitoring. A configuration model that is correct at launch can become unsafe when suppliers change components, standards change, prices expire or engineering releases a new revision.

    Implementation guidance covering migration, testing, deployment and governance is available in the manufacturing CPQ implementation guide.

    Common limitations and failure modes

    • Unclear ownership: Multiple systems edit the same field, producing conflicting values.
    • Catalog-only modeling: The CPQ model contains descriptions and prices but not technical constraints or downstream structure.
    • Overloaded CPQ: CPQ is made responsible for engineering, inventory, document control or manufacturing functions better handled elsewhere.
    • Hidden spreadsheet logic: Critical calculations remain outside the governed product model.
    • Part-number explosion: Every theoretical combination receives a separate item number without considering maintainability.
    • Weak revision control: Existing quotes or orders cannot be traced to the product rules and revisions used at the time.
    • Incomplete integration: A quote is generated successfully but the resulting configuration cannot be consumed by ERP, PLM, CAD or production.
    • Unmanaged exceptions: Sales teams bypass validation because the standard model cannot represent legitimate ETO or approval cases.

    These problems are not solved by adding more fields to a product catalog. They require a defined architecture, reliable identifiers, data stewardship and agreement about the desired manufacturing workflow.

    Product master data checklist

    Before implementing or expanding a CPQ configurator, verify that the organization can answer the following questions:

    • Which system owns each product, part, option, revision and price?
    • Are configuration rules documented and testable?
    • Which inputs are discrete options, numeric parameters, calculated values or engineering requests?
    • Can the model identify invalid combinations before a quote is released?
    • Does the configured product need a quote BOM, EBOM, MBOM, CAD output or only a configuration identifier?
    • How are CTO, ATO, MTO and ETO products distinguished?
    • How are revisions, effectivity dates and discontinued components handled?
    • Which data must flow to CRM, ERP, PLM, PDM, CAD, PIM or MES?
    • Who approves technical exceptions and commercial overrides?
    • How will product model changes be tested and deployed?
    • Can a historical quote be reproduced using the rules and master data that were active at the time?

    Semantic map

    The following relationships summarize how product master data connects a manufacturing CPQ configurator with engineering and enterprise systems:

    • Product master data defines configurable products.
    • Configuration rules prevent invalid combinations.
    • Product options select components and attributes.
    • Configured products generate resolved BOMs.
    • EBOMs represent engineering product structures.
    • MBOMs organize products for manufacturing.
    • PLM controls engineering revisions.
    • ERP manages operational item and order data.
    • CAD automation generates product-specific drawings.
    • CPQ calculates prices from configuration and commercial data.
    • CRM stores opportunities and uses quote results.
    • APIs exchange product and configuration data between systems.
    • MES consumes manufacturing definitions and production instructions.
    • Product data governance controls ownership and change.
    • ETO workflows route non-standard configurations to engineering.

    FAQ

    What is product master data for configurable products?

    It is the governed technical, commercial, engineering and manufacturing information used to define, validate, price and produce product variants.

    Is product master data the same as a product catalog?

    No. A catalog may contain descriptions and prices, while master data also includes identifiers, revisions, constraints, components, calculations and downstream manufacturing relationships.

    Which system should own product master data?

    There is usually no single owner for every field. PLM commonly owns engineering definitions, ERP operational item data, and CPQ the executable configuration and quoting model, subject to the company’s architecture.

    Should CPQ be the master data system?

    Usually not for all domains. CPQ should consume or reference authoritative data and may own the rules and model required for configuration, unless the selected architecture explicitly assigns it broader ownership.

    How does master data support a CPQ configurator?

    It supplies the products, options, attributes, constraints, prices and component relationships that allow the configurator to produce valid and commercially accurate results.

    What is the difference between product configuration and product master data?

    Product master data describes the product and its possible variants. Product configuration is the act of selecting values and resolving one valid instance of that product.

    What data does a configurable pump require?

    It may require flow, head, fluid, temperature, materials, seal type, impeller, motor, voltage, connection standard, price and component relationships.

    How do configuration rules relate to master data?

    Rules are governed logic built from product knowledge. They use master data such as options, attributes, components, ranges, revisions and compatibility relationships.

    What is a configurable BOM?

    A configurable BOM contains alternatives, conditions or selection rules that resolve into a product-specific BOM after configuration.

    Does CPQ generate an EBOM or MBOM?

    Some platforms can generate or integrate with BOM structures, but capabilities vary. The implementation must specify whether CPQ produces a quote BOM, EBOM, MBOM, order structure or reference only.

    How is an EBOM different from an MBOM?

    An EBOM represents the product from an engineering viewpoint. An MBOM organizes materials and assemblies for manufacturing and may include production-specific structures and consumables.

    What role does PLM play in configurable product data?

    Product lifecycle management (PLM) commonly controls engineering parts, structures, revisions, approvals and effectivity, which CPQ may consume for configuration and quoting.

    What role does ERP play?

    Enterprise resource planning (ERP) commonly manages item records, inventory, purchasing, manufacturing orders, accounting and operational transactions connected to the configured product.

    How does CAD use CPQ product data?

    Where supported, CPQ can pass dimensions, options and parameters to CAD automation. CAD may then generate geometry, drawings or design outputs, although not every CPQ system provides this capability.

    How should numeric dimensions be modeled?

    Define units, precision, valid ranges, rounding, dependencies and whether the value is entered, selected or calculated. These details are essential for engineering validation.

    How does master data support engineer-to-order products?

    It identifies standard limits, reusable modules, engineering inputs and approval triggers, allowing CPQ to distinguish valid standard configurations from cases requiring engineering work.

    What causes product master data conflicts?

    Common causes include duplicate ownership, inconsistent part numbers, manual spreadsheets, missing revision control, unsynchronized prices and undocumented configuration logic.

    How should product data changes be tested?

    Test valid and invalid combinations, boundary values, pricing, BOM resolution, revisions, effectivity dates and every affected integration before deployment.

    Can product master data improve quote accuracy?

    Yes, when the data includes current rules, costs, prices, components and engineering constraints. Master data alone cannot improve accuracy if it is incomplete or poorly governed.

    What is the difference between CPQ master data and PIM data?

    Product information management (PIM) focuses on publishing product content across channels. CPQ master data must additionally support configuration logic, technical validation, pricing and downstream transaction outputs.

    Should every product combination have its own part number?

    Not necessarily. Some products use configurable items or generated identifiers, while others require distinct part numbers for inventory, traceability, costing or production. The decision should reflect operational requirements.

    How often should CPQ product master data be updated?

    It should be updated whenever approved products, components, prices, rules, revisions or manufacturing processes change, using a controlled release process rather than an arbitrary calendar alone.

  • Product Catalog Design for Manufacturing CPQ

    Product catalog design for manufacturing CPQ is the process of structuring products, options, rules, technical attributes, prices and downstream manufacturing data so that a Configure, Price, Quote (CPQ) system can create valid and commercially accurate configurations. In a manufacturing environment, the catalog is not simply a sales list. It is part of the product and enterprise data architecture connecting sales, engineering, production and business systems.

    A well-designed catalog can help a sales engineer configure a pump package, industrial machine or specialty vehicle without selecting incompatible components. It can calculate a technically appropriate model, produce a quote, generate a configurable Bill of Materials (BOM), send order data to Enterprise Resource Planning (ERP), and—where supported—trigger CAD automation or engineering review. A poorly designed catalog usually creates duplicated products, hidden exceptions, manual engineering work and inconsistent prices.

    This article explains how to design a manufacturing CPQ catalog, what data belongs in it, how it should interact with ERP, Product Lifecycle Management (PLM), Customer Relationship Management (CRM), Computer-Aided Design (CAD) and other systems, and how to govern it over time.

    What is a manufacturing CPQ product catalog?

    A manufacturing CPQ product catalog is a structured product model containing the sellable offerings, configurable options, technical attributes, dependencies, constraints, calculations, pricing inputs and outputs required to configure and quote a manufactured product.

    The catalog normally represents a product family rather than only individual stock-keeping units (SKUs). A centrifugal pump family, for example, might include flow range, head, impeller diameter, casing material, seal type, motor rating, voltage, mounting arrangement and certification options. The catalog defines which combinations are valid and how the selected values affect price, cost, BOM content, lead time and engineering outputs.

    This differs from a generic sales catalog that may contain product names, descriptions, images and prices. Manufacturing CPQ requires technical relationships and downstream data. A catalog may need to represent mutually exclusive options, dimensional limits, engineering formulas, replacement components, manufacturing variants and approval requirements.

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

    Why catalog design matters in manufacturing CPQ

    The product catalog is often the central model used by the configuration experience, rules engine, pricing engine and quote process. It also acts as a controlled translation layer between commercial language and engineering or manufacturing data.

    Catalog responsibility Manufacturing purpose Example
    Product structure Organize families, models, variants and modules Base conveyor, drive package, guarding and controls
    Configuration data Capture technical selections and dimensions Belt width, conveyor length and motor voltage
    Rules Prevent invalid or unsafe combinations A high-temperature seal is required above a specified fluid temperature
    Calculations Convert requirements into engineering or commercial results Motor size calculated from load, speed and duty cycle
    Pricing Calculate price, cost, discounts and surcharges Material surcharge and regional labor adjustment
    Downstream mapping Generate or select production and engineering records Configured components mapped to an ERP BOM

    Catalog structure directly affects maintainability. If every possible product combination is created as a separate SKU, the organization may face a large and difficult-to-govern item master. If the model is too abstract, sales and engineering may lack the information needed to validate a configuration or build the product.

    Core layers of a manufacturing CPQ catalog

    1. Product families and models

    Start with a hierarchy that reflects how the manufacturer sells and engineers products. A typical structure may be product family, platform, model series, module, option group, component and service.

    For an industrial air-handling unit, the hierarchy could include the unit family, frame size, airflow range, coil section, fan assembly, filter bank, controls package and installation accessories. The hierarchy should support navigation for users while preserving the technical relationships needed by the rules engine.

    Do not assume that the commercial hierarchy and engineering hierarchy are identical. Sales may describe a product as a packaged system, while engineering manages it as a collection of assemblies and subassemblies. The catalog should provide a deliberate mapping between the two views.

    2. Features, options and attributes

    Features describe meaningful configuration decisions, while options are the selectable values within those features. Attributes describe measurable or descriptive properties such as length, material, rating, capacity, color or certification.

    For a valve assembly, features might include valve type, body material, connection standard, actuator and positioner. Attributes could include nominal diameter, pressure class, temperature range and flow coefficient. Some attributes are entered by the user; others are calculated or inherited from selected components.

    Use controlled values and units wherever possible. A free-text field for motor voltage or pipe diameter makes validation, pricing and integration difficult. Numeric values should have defined units, ranges, precision and conversion rules.

    3. Configuration rules and constraints

    Rules determine whether a configuration is valid and what the system should do when a selection changes. Common rule types include:

    • Compatibility rules: allow a component only with compatible models or interfaces.
    • Dependency rules: require one option when another is selected.
    • Exclusion rules: prevent two incompatible options from being selected together.
    • Range rules: restrict dimensions, capacity or ratings to supported limits.
    • Calculation rules: derive values such as motor size, wall thickness or required accessories.
    • Default rules: suggest a standard selection without preventing alternatives.
    • Approval rules: route unusual configurations to engineering or management review.

    Rules-based configuration evaluates explicit conditions defined by the manufacturer. Constraint-based configuration evaluates relationships and limits among variables, which is useful when a product has many interacting dimensions or performance requirements. Guided selling focuses on helping a user reach a suitable product through questions and recommendations; it does not necessarily provide the engineering validation required for a buildable product.

    Rules should be written so that their ownership and purpose are clear. A rule such as “Option X requires Option Y” is easier to test than an undocumented script that changes several fields and silently modifies the price.

    4. Technical and engineering data

    A manufacturing catalog may contain or reference dimensions, materials, performance curves, tolerances, ratings, environmental limits, standards, drawings, calculation coefficients and engineering classifications.

    Not every engineering record should be copied into CPQ. Product Lifecycle Management (PLM) or Product Data Management (PDM) may remain the system of record for released specifications, revisions and CAD documents. CPQ should receive the subset of data needed to configure, validate, price and hand off the product.

    For example, a pump catalog may store available impeller diameters, operating ranges and material compatibility in CPQ, while detailed design documents and approved CAD files remain managed in PLM or PDM.

    5. Commercial data

    Commercial data includes list prices, cost inputs, currencies, customer-specific agreements, discounts, surcharges, freight assumptions, labor factors, tax classifications and effective dates. Pricing should be separated conceptually from configuration. A product may be technically valid but commercially unavailable in a region, or a valid selection may require a special surcharge.

    Pricing ownership must be defined. In some architectures, CPQ calculates the quote price while ERP provides standard costs and item prices. In others, a pricing service or commercial master-data system supplies pricing conditions. The catalog should identify the source, update frequency and authority for each value.

    Product catalog relationships with enterprise systems

    Manufacturing CPQ should be designed as part of the wider technology stack rather than as an isolated sales application.

    System Typical responsibility Catalog relationship
    CRM Accounts, opportunities and customer interactions Starts the opportunity or stores the resulting quote
    ERP Items, inventory, purchasing, costing, orders and production transactions Provides or receives item, pricing, BOM and order data
    PLM Product lifecycle, revisions, released structures and technical change control Supplies approved product and revision information
    PDM CAD files, documents and design metadata Links configured selections to approved design records
    CAD Geometric and engineering design data May receive parameters and return drawings or models
    PIM Product information for channels and commerce Publishes descriptions, media and channel attributes
    MES Manufacturing execution and shop-floor activity May receive production-relevant configuration or routing information

    These systems are not interchangeable. ERP item records do not replace engineering configuration rules. PLM revision control does not automatically provide quote pricing. CRM opportunity data does not contain a complete manufacturing BOM. A successful architecture defines which system owns each data domain and how changes are synchronized.

    The manufacturing CPQ integration guide covers integration patterns, APIs and system boundaries in more detail.

    Catalog design and BOM generation

    A configured product may generate one or more BOM representations. An Engineering BOM (EBOM) describes the product from an engineering perspective, often emphasizing design structure and functional assemblies. A Manufacturing BOM (MBOM) describes how the product is built, including manufacturing assemblies, consumables, operations or plant-specific structures. A configurable BOM uses rules or selection logic to derive the relevant components for a particular configuration.

    CPQ may generate a complete BOM, select an existing ERP BOM, create a configuration-specific BOM request, or pass structured selections to another system that performs the final expansion. The correct approach depends on product complexity, ERP capabilities, manufacturing process and governance requirements.

    For a configurable electrical enclosure, CPQ could select the enclosure size, gland plate, breakers, cooling unit and control components. The resulting structure may be sufficient for quoting but not yet sufficient for manufacturing if routing, plant-specific substitutes or work instructions are managed elsewhere.

    Do not treat a quote BOM as automatically equivalent to a released production MBOM. The data may require engineering approval, revision validation and plant-specific transformation.

    See BOM, pricing and quoting in manufacturing CPQ for related architecture and workflow considerations.

    Catalog design and CAD automation

    Some manufacturing CPQ implementations connect configuration choices to parametric CAD, drawings, models or engineering calculations. When available, this can reduce repetitive design work and support faster handoff from sales to engineering.

    A catalog may pass parameters such as length, hole pattern, motor position, material thickness or mounting orientation to a CAD automation process. The CAD system may then generate a product-specific model or drawing. However, CAD automation is not a standard capability of every CPQ platform and should be evaluated separately.

    The catalog must define which parameters are safe for automated generation, which combinations have approved templates, and when engineering review is required. A visual 3D model can improve understanding, but visualization alone does not prove that a product is manufacturable.

    Read the CAD and engineering automation guide for more on parametric models, drawings, calculations and design-system integration.

    Catalog patterns for CTO, ETO, MTO and ATO

    Catalog design should reflect the manufacturer’s fulfillment model.

    • Configure-to-order (CTO): the customer selects from predefined options and the product is assembled or produced using an established structure.
    • Engineer-to-order (ETO): the customer requirement triggers additional engineering, design work or approval beyond the standard model.
    • Make-to-order (MTO): production begins in response to an order, often using a standard or configured product.
    • Assemble-to-order (ATO): standard modules are stocked or prepared and assembled after the order is received.

    A CTO catalog can usually expose a controlled set of options and generate predictable downstream data. An ETO catalog may capture requirements, calculate preliminary specifications, identify a reference design and create an engineering task rather than promise a fully automated output.

    Combining CTO and ETO logic in one catalog requires clear status indicators. Users should know whether a selection is standard, conditionally available, subject to review or entirely outside the supported model.

    The manufacturing workflow guide explains how CPQ fits into configure-to-order, engineer-to-order and sales-to-production processes.

    Data ownership and catalog governance

    Catalog quality depends on governance as much as on software configuration. Establish an owner for each major data domain and define how changes are proposed, reviewed, tested, released and retired.

    Data domain Possible owner Governance question
    Product options Product management or engineering When is an option commercially available?
    Technical constraints Engineering What evidence supports the rule?
    Prices and discounts Finance or commercial operations Which system controls effective dates?
    ERP item mappings ERP or master-data team How are revisions and inactive items handled?
    CAD templates Design engineering Which parameters are approved for automation?
    Approval thresholds Engineering and management Which configurations require review?

    Use versioning and effective dates for products, rules, prices and integrations. A quote created under an earlier product revision may need to remain reproducible even after the catalog changes. Audit trails should show who changed a rule, why it changed and which configurations were tested.

    Implementation approach

    Document the product before building the model

    Collect product family structures, option lists, engineering rules, price logic, BOM mappings, drawings, exceptions and approval paths. Workshops with sales engineering, product management, design engineering, manufacturing, finance and IT are usually necessary because no single department owns the complete product definition.

    Separate stable structure from changing business logic

    Keep the product hierarchy and technical concepts understandable while allowing prices, discounts and regional availability to change independently. Avoid embedding every commercial exception in a technical configuration rule.

    Build a representative pilot

    Select a product family with meaningful configuration complexity but manageable scope. Include common configurations, boundary cases, invalid combinations, engineering-review cases and downstream integration scenarios. A simple product may demonstrate screens but will not adequately test catalog architecture.

    Test the complete transaction

    Test more than whether the configurator accepts a selection. Verify calculated values, price, discount, quote text, BOM, ERP item mapping, revision, CAD parameters, approval status and error handling. Test both normal and exceptional configurations.

    For implementation planning, data migration, testing and governance, consult the CPQ implementation guide.

    Common product catalog design mistakes

    • Copying the ERP item master into CPQ: an item master may lack configurable relationships and engineering constraints.
    • Creating a SKU for every combination: this can produce duplication and make maintenance impractical.
    • Using free text for technical selections: free text is difficult to validate, price and integrate.
    • Hiding rules in custom code: opaque logic increases testing and ownership problems.
    • Mixing released and provisional products: users may quote products that are not approved for production.
    • Treating a visual model as engineering validation: a 3D view does not replace structural, electrical or performance checks.
    • Ignoring historical quotes: changes must not make previously issued quotes impossible to reproduce.
    • Failing to model exceptions: unusual configurations should be routed to review rather than silently accepted or rejected.

    How to evaluate catalog capability in CPQ software

    When evaluating CPQ software for manufacturing, ask vendors to demonstrate a representative product model rather than a generic quote screen. The demonstration should include multiple interacting dimensions, incompatible materials, calculated selections, configurable BOM output, price changes, revision handling and an ERP or PLM handoff where relevant.

    Important evaluation questions include:

    • Can the platform represent product families, modules, variants and reusable rules?
    • Can business users maintain options and rules without unsafe developer changes?
    • Does it support numeric constraints, formulas, units and engineering calculations?
    • How are configurable BOMs represented and transferred?
    • Can the system distinguish quote data from released manufacturing data?
    • How are product, rule, price and configuration revisions managed?
    • What APIs and integration methods are available?
    • Can it support CTO, ETO, MTO or ATO workflows appropriate to the manufacturer?
    • Does it provide CAD automation or only link to external CAD processes?
    • How are invalid configurations, exceptions and engineering approvals handled?

    Capabilities vary significantly between platforms. Some products focus on guided selling and commercial quoting, while others provide deeper product modeling, engineering automation or BOM generation. These capabilities should be verified in product documentation and a relevant proof of concept rather than assumed from the term CPQ.

    Benefits and limitations

    A well-designed catalog can reduce configuration errors, improve quote consistency, shorten sales-engineering handoffs, expose accurate option dependencies and provide structured data for ERP or engineering processes. It can also make product changes more controlled because rules and mappings are managed in a defined model.

    However, a catalog does not eliminate poor source data or unclear product ownership. It may expose contradictions between engineering documents, ERP items and price lists. Complex ETO products may still require engineering review. Integration latency, revision conflicts, plant-specific manufacturing rules and legacy data can limit automation. Catalog design is therefore an ongoing product-data discipline, not a one-time screen-building project.

    Semantic map

    The semantic relationships below summarize the main entities and flows discussed in this article.

    • Manufacturing CPQ configures configurable products.
    • Product catalogs define product families, features and options.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Configured products generate quote data.
    • Configured products can generate or select BOM structures.
    • EBOM represents engineering product structure.
    • MBOM represents manufacturing product structure.
    • Pricing rules calculate commercial values.
    • CPQ exchanges customer and quote data with CRM.
    • CPQ exchanges item, order and BOM data with ERP.
    • PLM manages product lifecycle and revision information.
    • PDM manages CAD files and design documents.
    • CAD automation generates product-specific drawings or models when supported.
    • ETO configurations trigger engineering review.
    • Catalog governance controls rules, revisions and ownership.

    Frequently asked questions

    1. What is a product catalog in manufacturing CPQ?

    It is a structured model of products, options, attributes, rules, calculations, prices and downstream mappings used to configure and quote manufactured products.

    2. How does a manufacturing CPQ catalog differ from a sales catalog?

    A sales catalog mainly presents products and prices. A manufacturing catalog also represents technical constraints, engineering logic, BOM relationships, revisions and production handoff data.

    3. Should ERP be the system of record for the CPQ catalog?

    Not necessarily. ERP commonly owns items, inventory, orders and financial transactions, while CPQ owns configuration logic and PLM or PDM may own released engineering data. Ownership must be defined by data domain.

    4. Should every configurable combination have its own SKU?

    No. Many manufacturers use product families, configurable options and rule-driven mappings rather than creating a separate SKU for every possible combination.

    5. What information should a CPQ catalog contain?

    It may contain product structures, options, technical attributes, constraints, formulas, prices, costs, BOM mappings, approval rules, revision data and integration identifiers.

    6. What is the difference between an option and an attribute?

    An option is usually a selectable value, such as stainless-steel casing. An attribute describes a property, such as casing thickness, diameter or operating temperature.

    7. What are configuration rules?

    Configuration rules define dependencies, exclusions, ranges, calculations, defaults and approvals that determine whether a product selection is valid.

    8. Does every CPQ system generate a BOM?

    No. Some systems generate configurable BOMs, some select ERP structures, and others pass configuration data to another system. This capability must be verified for the specific platform.

    9. Is a CPQ BOM the same as an MBOM?

    Not always. A CPQ BOM may support quoting or preliminary order processing, while an MBOM includes the manufacturing structure and plant-specific information needed to build the product.

    10. Can CPQ generate CAD drawings?

    Some platforms integrate with CAD automation or engineering systems, but CAD generation is not universal. The implementation must define supported templates, parameters and review conditions.

    11. How should ETO products be represented?

    The catalog should capture known requirements, identify a reference product or design envelope, and route nonstandard selections to engineering rather than presenting them as fully automated standard products.

    12. What is the role of PLM in catalog design?

    PLM may own product lifecycle status, released revisions, engineering structures and change control. CPQ can consume approved data needed for configuration and quoting.

    13. What is the role of PDM?

    Product Data Management systems commonly manage CAD files, drawings and related design documents. CPQ may link configuration results to approved PDM records or pass parameters to CAD automation.

    14. How should prices be managed in the catalog?

    Define which system owns list prices, costs, discounts, surcharges, currencies and effective dates. Separate commercial rules from technical configuration rules where practical.

    15. How do units affect catalog design?

    Dimensions and performance values should have defined units, ranges, precision and conversion behavior. This prevents errors when users, CAD systems or ERP operate in different unit systems.

    16. How should catalog changes be tested?

    Test valid, invalid, boundary and exception configurations, then verify prices, quote text, BOMs, revisions, integrations and approval routing.

    17. Who should own the product catalog?

    Ownership is usually shared. Product management may own commercial structure, engineering owns technical rules, finance owns pricing policies, and IT or master-data teams govern integrations and identifiers.

    18. How often should a manufacturing CPQ catalog be updated?

    It should be updated whenever products, prices, engineering rules, ERP items, revisions or regulatory requirements change. Release processes should control timing and effective dates.

    19. Can one catalog support CTO and ETO?

    Yes, but the model must distinguish standard selections from review-required configurations and clearly define when automated outputs stop and engineering work begins.

    20. What is the first step in designing a CPQ catalog?

    Document the product family, configuration decisions, rules, engineering outputs, prices, BOM relationships, system owners and workflow exceptions before configuring the software.

  • Composable CPQ for Manufacturing

    Composable CPQ for manufacturing is an architecture in which configure, price, quote (CPQ) capabilities are delivered as modular services and connected to the wider manufacturing technology stack. Instead of treating CPQ as one isolated application, a composable approach separates product configuration, rules, engineering calculations, pricing, quoting, bill of materials (BOM) generation, computer-aided design (CAD) automation and integration services where appropriate.

    This matters for manufacturers because the information required to produce an accurate quote is rarely owned by one system. Product definitions may be maintained in product lifecycle management (PLM) or product data management (PDM) software, customer and opportunity information may be held in customer relationship management (CRM), costs and item masters may belong to enterprise resource planning (ERP), and drawings or models may be generated by CAD systems. A composable CPQ architecture coordinates these capabilities while preserving data ownership in the systems responsible for it.

    In practical terms, composable CPQ can help a manufacturer configure a valid pump package, calculate a suitable motor and impeller combination, price the resulting assembly, generate a configurable BOM, request a CAD drawing, and send an approved order to ERP. However, not every CPQ platform provides every one of these functions. Buyers must establish which capabilities are native, which are delivered by extensions, and which remain in ERP, PLM, CAD or engineering applications.

    For background, see the broader guide to CPQ software for manufacturing and the guide to CPQ integrations.

    What is composable CPQ?

    Composable CPQ is a modular approach to CPQ in which business capabilities are exposed through reusable applications, services, APIs and data contracts. A manufacturer can combine these components to support a specific workflow rather than adopting one monolithic application for every configuration and engineering task.

    A composable architecture may include the following components:

    • Configuration experience: the user interface used by a salesperson, dealer, engineer, customer or ecommerce buyer.
    • Product model: the representation of products, options, variants, attributes, dependencies and selectable values.
    • Rules engine: logic that validates combinations, derives selections, enforces constraints or determines required actions.
    • Engineering calculation service: formulas or external engineering applications that calculate dimensions, capacity, performance or component selection.
    • Pricing and costing service: logic for list prices, discounts, surcharges, costs, margins, currencies and commercial approvals.
    • BOM service: logic that produces a configurable, engineering or manufacturing bill of materials for the selected product.
    • CAD and visualization service: tools that generate models, drawings, images or product-specific representations when supported.
    • Quote and document service: generation of quotations, specifications, approval records and customer-facing documents.
    • Integration and orchestration layer: APIs, events, middleware and workflow services that exchange data with ERP, CRM, PLM, PDM, CAD, product information management (PIM) and manufacturing execution system (MES) applications.

    These components can be deployed in one product, several products or a mixture of packaged software and custom services. “Composable” describes the architecture and assembly model; it does not guarantee that an implementation will be simple or that every component will be interchangeable.

    Why composable CPQ is relevant to manufacturers

    Generic sales CPQ often focuses on selecting commercial options, applying discounts and producing a quote. Manufacturing CPQ must frequently go further. The configuration may determine engineering feasibility, component dimensions, material requirements, production operations, compliance documentation and the data needed to manufacture the order.

    For example, configuring an industrial air-handling unit may involve airflow, static pressure, cabinet dimensions, insulation, coil selection, fan type, motor power, electrical supply, controls and environmental conditions. A valid configuration may require engineering calculations and may produce different components, drawings and production instructions. The pricing result is only one output of the configuration.

    Composable architecture is useful where a business has already invested in specialized systems or where different product families require different levels of engineering automation. One product line may need a deep CAD automation workflow, while another may only need rules-based option validation and ERP pricing. A modular design can support both without forcing every product family into the same technical model.

    Composable CPQ architecture in the manufacturing stack

    A typical architecture has several layers. The exact boundaries vary by business and software selection, but the following model helps clarify responsibilities.

    Layer Typical responsibility Manufacturing example
    Experience Guides a user through configuration, pricing and quoting Dealer selects a pump duty, materials, motor and accessories
    Configuration Maintains product options, attributes, dependencies and validation Prevents an incompatible motor and voltage combination
    Engineering Calculates or selects technical values and design outputs Calculates pump head, flow, shaft power or heat exchanger size
    Commercial Calculates prices, costs, discounts, margins and approvals Applies material surcharges and customer-specific discount rules
    Output generation Creates BOMs, specifications, drawings and quote documents Produces an order-specific BOM and a dimensioned arrangement drawing
    Enterprise systems Owns customer, item, cost, order, revision and production data ERP receives the approved order and manufacturing item references
    Integration Moves data between services and systems API or event sends configuration, price and revision information to ERP and PLM

    Configuration and product models

    The product model describes what can be sold and how it can be combined. It may include product families, models, features, options, dimensions, materials, accessories, software selections and service levels.

    The model should not be confused with a price list. A product configuration defines a technically and commercially meaningful product instance. Pricing is a separate concern, even though the selected configuration supplies inputs to pricing.

    Manufacturers should also distinguish several types of rules:

    • Rules-based configuration: explicit logic such as “if 480 V is selected, require a compatible motor option.”
    • Constraint-based configuration: a solver or constraint model determines whether a set of values satisfies technical relationships, ranges or dependencies.
    • Guided selling: questions and recommendations help a user reach a suitable product, but guided selling alone does not prove engineering validity.

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

    Engineering and CAD services

    Some manufacturing CPQ implementations include engineering calculations, parametric design automation, 2D drawings, 3D visualization or CAD file generation. Others validate configuration and hand the selected parameters to a separate engineering system.

    For example, a configurable conveyor may use CPQ to capture length, width, belt type, elevation, motor choice and guarding. A calculation service can determine drive requirements, while a CAD system generates a layout and an engineering application creates a product-specific drawing. The CPQ layer should record the inputs, calculation version and output references so that the quote can be traced to a particular engineering result.

    CAD automation is not an automatic consequence of composable CPQ. It requires suitable parametric models, stable interfaces, engineering rules, template governance and a process for handling exceptions. See CAD and engineering automation for CPQ.

    Pricing, costing and quoting

    A pricing service may calculate a selling price from the configured product, customer segment, currency, region, delivery terms, quantity, discount authority and commercial policies. A costing service may calculate material, labor, subcontracting, freight or estimated manufacturing costs.

    These are not necessarily the same as the configuration rules. A material may be technically valid but subject to a surcharge. A custom dimension may be valid but require engineering review. A customer may receive a discount that does not change the product definition but does change the commercial offer.

    Quote documents should identify the configuration, revision, assumptions, exclusions, lead-time basis and approval status. For BOM, pricing and quote architecture, see BOM generation, pricing and quote automation.

    Data ownership in a composable CPQ architecture

    The most important architecture decision is not whether to use APIs. It is deciding which system owns each type of data and how other systems consume it.

    Data domain Possible system of record CPQ relationship
    Customer, account and opportunity CRM CPQ reads customer context and returns configuration, quote and status information
    Product lifecycle, revisions and approved product structures PLM or PDM CPQ consumes released definitions, options, revisions or engineering references
    Item master, inventory, costs, orders and financial data ERP CPQ retrieves item and cost data and sends approved order information
    Product attributes and commercial content PIM or product master CPQ uses descriptions, images, documents and channel-specific content
    Geometry, templates and drawings CAD or engineering system CPQ sends parameters and stores generated-file references
    Production execution and work-center status MES CPQ usually provides order or configuration context rather than replacing execution control
    Configuration session and quote state CPQ CPQ records selected options, rule results, calculated values and commercial outcomes

    There is no universal answer for every domain. Some organizations manage configurable BOM logic in CPQ, while others maintain it in PLM or ERP. The decision should consider revision control, engineering approval, reuse, performance, auditability and the needs of downstream production.

    How a composable CPQ workflow works

    1. Start with commercial or customer context. A salesperson opens a CRM opportunity, or a dealer starts a new configuration. Customer, location, currency and channel data are passed to CPQ.
    2. Load the relevant product model. CPQ retrieves the applicable product family, market rules, effective date and product revision.
    3. Capture requirements. The user enters technical requirements such as flow, pressure, capacity, dimensions, temperature, material, voltage or environmental conditions.
    4. Validate and derive selections. Rules prevent invalid combinations, while calculations or selection services determine compatible components.
    5. Request engineering outputs when needed. CPQ may call a calculation engine, CAD automation service or engineering workflow. If the configuration exceeds supported rules, it can create an engineering review task.
    6. Generate commercial results. Pricing and costing services calculate price, margin, lead-time assumptions and approval requirements.
    7. Generate manufacturing-related outputs. Depending on the architecture, the system creates a configurable BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), drawings, specifications or references to these outputs.
    8. Produce and approve the quote. The customer-facing quote includes the selected configuration and relevant assumptions. Internal approvals are recorded before release.
    9. Transfer the approved result. CPQ sends an order, configured item, BOM reference, document reference or configuration payload to ERP, PLM, PDM or another downstream system.
    10. Retain traceability. The business should be able to identify which product model, rule version, price version and engineering output produced the quote.

    This workflow can support configure-to-order (CTO), assemble-to-order (ATO), make-to-order (MTO) and engineer-to-order (ETO), but the level of automation differs. CTO uses predefined configurations. ATO assembles stocked or semi-finished components. MTO produces a product after the order, often using established designs. ETO creates or modifies engineering outputs for the specific order and normally requires stronger engineering workflow integration.

    The differences between these operating models are discussed in manufacturing CPQ workflows.

    Configurable BOMs, EBOMs and MBOMs

    A BOM is a structured list of components and quantities required for a product or assembly. A configurable BOM represents possible components and selection conditions. An EBOM is an engineering bill of materials organized around design intent. An MBOM is a manufacturing bill of materials organized around how the product is assembled or produced.

    Composable CPQ may generate a configured BOM directly, select an approved BOM variant, or send configuration parameters to PLM or ERP for BOM resolution. These approaches have different governance implications.

    Approach Potential use Important question
    CPQ resolves configured components Fast CTO or ATO quoting with established options How are revisions and production changes synchronized?
    PLM resolves the EBOM Engineering-controlled products with formal lifecycle management Can CPQ consume only released and valid structures?
    ERP resolves the production BOM Organizations where ERP owns item and manufacturing structures Can the order retain the original configuration and rule version?
    CPQ sends parameters to an engineering workflow ETO or calculation-driven products How are exceptions, approvals and design changes tracked?

    A common implementation error is treating any list of selected options as a production-ready MBOM. A commercial configuration may omit phantom assemblies, operation sequences, alternate materials, scrap factors, work instructions or plant-specific manufacturing data. The receiving system must confirm whether the output is suitable for production or only for quotation and engineering review.

    Integration patterns for composable CPQ

    Synchronous APIs

    A synchronous API request returns a result during the configuration session. It is suitable for retrieving item attributes, validating a selection, calculating a price or checking a technical value when the response is expected quickly.

    For example, CPQ may send pump flow, head, fluid and temperature to a selection service and receive compatible pump models. Timeouts, error handling and fallback behavior are important because a slow or unavailable service can interrupt quoting.

    Asynchronous events and workflows

    Asynchronous integration is useful when an operation takes longer or requires human review. CAD generation, ETO engineering, supplier checks and formal approval can produce events such as “drawing generated,” “engineering review completed” or “quote approved.”

    Event-based designs require reliable message handling, correlation identifiers, retries, duplicate protection and clear ownership of status. A quote should not appear technically approved simply because an integration request was sent.

    Batch and scheduled synchronization

    Some data does not need real-time exchange. Product descriptions, price books, released items, costs and document metadata may be synchronized on a schedule. Batch synchronization can reduce integration complexity but introduces timing and effective-date risks.

    Headless configuration services

    A headless configuration service separates configuration logic from the user interface. The same product model can support a salesperson application, dealer portal, ecommerce front end or internal engineering tool. This approach is useful when several channels need consistent rules, but it requires a stable API and careful control of channel-specific behavior.

    Benefits and limitations

    Potential benefits

    • Reuse of existing systems: the business can retain specialized ERP, PLM, CAD or engineering applications rather than replacing every system.
    • Channel consistency: shared configuration services can apply the same product rules across sales, dealers and digital channels.
    • Incremental delivery: a manufacturer can begin with configuration and pricing, then add BOM, engineering or CAD services where the business case is clear.
    • Clearer ownership: explicit boundaries can reduce duplicate product, cost and revision data.
    • Product-family flexibility: different product lines can use different engineering depth while sharing commercial and integration services.
    • Better traceability: versioned services and data references can make it easier to understand how a quote was produced.

    Limitations and risks

    • Integration becomes a product of its own: multiple services require monitoring, version management, security, testing and operational support.
    • Data semantics may conflict: an “option,” “variant,” “item,” “assembly” or “revision” may mean different things in CPQ, ERP and PLM.
    • Distributed failures are harder to diagnose: a quote may depend on several services with different availability and response times.
    • Rule duplication can grow: copying the same compatibility logic into CPQ, ERP, PLM and CAD creates inconsistent behavior.
    • Transaction boundaries are complex: a quote, drawing and order may not be committed at the same time.
    • Composable does not mean low-code: sophisticated configuration and engineering models still require domain expertise, testing and governance.
    • Vendor boundaries may be unclear: a platform may advertise extensibility or APIs without providing the manufacturing capabilities needed for BOM, CAD or engineering automation.

    Implementation considerations

    Define the target workflow before selecting components

    Start with a specific product family and workflow. Document the inputs, rules, calculations, outputs, approvals and systems involved. A pump manufacturer might map the flow from duty-point entry through pump selection, motor validation, material selection, costing, drawing generation and ERP order creation.

    Assign ownership for every important data object

    Create a data ownership matrix for product options, rules, revisions, item numbers, costs, prices, BOM structures, CAD templates, documents and customer data. Identify who can change each object, how changes are approved and how effective dates are applied.

    Separate rules by purpose

    Keep commercial rules, technical constraints, engineering formulas and manufacturing transformations distinguishable. A rule that blocks a combination is not the same as a formula that calculates a dimension, and neither is the same as a discount condition.

    Version models and outputs

    Configuration results should identify the product model version, rule version, price book, calculation version and relevant engineering revision. Without this information, reproducing an old quote or explaining a changed result becomes difficult.

    Design for exceptions

    Not every product can be fully automated. The architecture should support engineering review, manual adjustments, substitutions, customer-specific requirements and incomplete data without silently creating an invalid result. An ETO request should have a visible status and a defined handoff rather than appearing as a normal CTO configuration.

    Test the complete chain

    Testing must cover more than the CPQ user interface. Use representative combinations and test configuration validation, calculations, prices, BOM resolution, CAD outputs, document generation, API failures, revisions, permissions and downstream order creation. Regression tests are particularly important when a shared product model supports several channels.

    Implementation planning, governance and testing are covered in the CPQ implementation guide.

    How to evaluate composable CPQ software

    Manufacturers should evaluate the architecture against actual product and workflow requirements rather than counting generic features. Important questions include:

    • Can the platform represent product families, variants, dimensions, ranges, dependencies and conditional options?
    • Does it support rules-based configuration, constraint solving, guided selling, or only simple option selection?
    • Can rules and product models be versioned, tested and maintained by appropriate business or engineering users?
    • Can it expose configuration, validation, pricing and quote functions through documented APIs?
    • Does it generate a BOM, select a BOM, or pass parameters to another BOM-owning system?
    • Can it distinguish commercial configuration from EBOM and MBOM requirements?
    • Does it support engineering calculations, CAD automation or 3D visualization natively, through extensions, or not at all?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can it support dealer, distributor, ecommerce and internal engineering channels with consistent logic?
    • How are ETO exceptions, approvals, manual engineering work and document revisions handled?
    • What happens when an external system is unavailable during configuration or order submission?
    • Can the organization export its product model, rules, configuration history and outputs if the architecture changes?

    Vendor claims should be verified through documentation, demonstrations using the manufacturer’s own product examples, API specifications, implementation references where available and a proof of concept. Do not assume that an API or modular architecture includes manufacturing-grade configuration, BOM, CAD or engineering behavior.

    Semantic map

    The following relationships summarize the main entities and how they interact in a composable manufacturing CPQ architecture.

    • CPQ connects product configuration with pricing, quoting and downstream manufacturing data.
    • Product models define selectable features, options, attributes and variants.
    • Configuration rules prevent invalid product combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Engineering calculations transform customer requirements into technical selections or values.
    • Configured products provide inputs to pricing and costing services.
    • Configured products can generate or select configurable BOM structures.
    • EBOM represents engineering design intent.
    • MBOM represents manufacturing assembly and production structure.
    • CAD automation generates product-specific models or drawings when supported.
    • CRM provides customer and opportunity context to CPQ.
    • ERP owns or consumes item, cost, order and financial data.
    • PLM or PDM governs product revisions and released engineering data.
    • MES executes or monitors production activities after order release.
    • APIs and events exchange configuration and engineering data between systems.
    • ETO workflows route unsupported configurations to engineering review.

    Frequently asked questions

    What is composable CPQ for manufacturing?

    It is a modular CPQ architecture that combines configuration, rules, engineering, pricing, quoting and manufacturing data services with systems such as ERP, PLM, CRM, CAD and MES.

    How is composable CPQ different from generic sales CPQ?

    Generic sales CPQ may focus on options, discounts and quote documents. Manufacturing composable CPQ also considers technical constraints, engineering calculations, BOMs, CAD outputs, revisions and production handoffs where those capabilities are required.

    Does composable CPQ replace ERP?

    Usually not. ERP commonly remains responsible for items, inventory, costs, orders, financial processing and manufacturing-related master data. CPQ supplies a validated commercial and technical configuration to ERP.

    Does composable CPQ replace PLM?

    Usually not. PLM often manages product lifecycle, engineering revisions and released product structures. CPQ may consume PLM data or manage a commercial configuration model linked to PLM references.

    Can composable CPQ generate a manufacturing BOM?

    It can in some implementations, but this is not universal. The BOM may instead be resolved in ERP or PLM. Buyers should verify whether the output is a configurable BOM, EBOM, MBOM or only a list of quoted options.

    What is the role of CAD in composable CPQ?

    CAD can receive configuration parameters and generate product-specific models, drawings or layouts. This requires compatible parametric models, automation interfaces and engineering governance; it is not guaranteed by a CPQ platform.

    Can composable CPQ support engineer-to-order products?

    Yes, when it includes or integrates with engineering workflow, calculation, CAD, approval and document processes. ETO should be treated as a controlled exception or design workflow rather than as simple option selection.

    Is a headless CPQ the same as composable CPQ?

    No. Headless CPQ separates the configuration service from its user interface. Composable CPQ is a broader architectural approach that may include headless services, modular applications, APIs and external engineering or enterprise systems.

    What systems commonly integrate with composable CPQ?

    Common systems include CRM, ERP, PLM, PDM, CAD, PIM, MES, ecommerce platforms, calculation services, document systems and integration middleware. The exact integration depends on the manufacturer’s workflow.

    Where should product rules be maintained?

    Rules should be maintained by the system best suited to their purpose and governance. Configuration rules may reside in CPQ, lifecycle-controlled engineering rules may reside in PLM or an engineering service, and manufacturing transformations may belong in ERP or manufacturing applications.

    How does composable CPQ handle pricing?

    It uses the configured product and commercial context as inputs to price books, cost data, discounts, surcharges, currencies, margins and approval policies. Pricing logic should remain distinguishable from technical configuration rules.

    Can one composable CPQ model serve dealers and internal engineers?

    It can when the platform provides reusable configuration services and role-specific interfaces. The dealer may see guided questions and prices, while an engineer may see calculated values, rule diagnostics and design outputs.

    What happens when an external integration fails?

    The system should provide explicit error states, retries where appropriate, monitoring and a controlled fallback or review process. It should not silently issue a technically incomplete quote or order.

    How does composable CPQ support configure-to-order?

    It validates a predefined product model, selects compatible options, calculates price and produces the required order or BOM data. The amount of downstream automation depends on ERP, PLM and production integration.

    How does composable CPQ support make-to-order?

    It captures the customer-specific requirements and creates a valid order configuration, while ERP or engineering systems determine procurement, production and delivery details.

    What is the main implementation risk?

    A major risk is unclear ownership or duplicated logic across CPQ, ERP, PLM, CAD and engineering services. This can produce conflicting rules, incorrect revisions, unreliable BOMs and difficult troubleshooting.

    How should a manufacturer start a composable CPQ project?

    Start with one representative product family and map the complete workflow from requirements through quote, engineering output and order release. Define data ownership, interfaces, exception handling and measurable acceptance criteria before expanding.

    How should composable CPQ vendors be evaluated?

    Evaluate product-model depth, rules, APIs, versioning, BOM behavior, pricing, engineering and CAD integration, ERP and PLM connectivity, exception workflows, governance, security, testing and implementation effort using real manufacturing examples.

  • From Quote to Production: The Manufacturing CPQ Workflow

    Manufacturing CPQ—Configure, Price, Quote software for complex products—connects the commercial quote with the engineering and production information needed to fulfill an order. A typical workflow starts when a salesperson, dealer or customer selects product options and ends when validated configuration data, pricing, a bill of materials (BOM), engineering outputs and order information are transferred to the appropriate enterprise systems.

    The important distinction is that manufacturing CPQ does more than calculate a price and generate a proposal. It may validate technical combinations, perform engineering calculations, identify components, create a configurable BOM, initiate CAD automation and distinguish between a standard configure-to-order product and an engineer-to-order project. The exact scope depends on the CPQ platform, product model and integrations implemented by the manufacturer.

    For example, a pump manufacturer might use CPQ to select pump type, impeller diameter, motor rating, materials, seals, connection standards and control options. The system can reject incompatible combinations, calculate performance requirements, determine price and produce a quote. After order acceptance, it may send the validated configuration to an enterprise resource planning (ERP) system, generate an engineering bill of materials (EBOM), request drawings from a computer-aided design (CAD) system or route an exception to an engineer.

    This article follows that process from initial requirements through production handoff. For a broader introduction, see the guide to manufacturing CPQ.

    What the manufacturing CPQ workflow does

    The manufacturing CPQ workflow transforms customer requirements into progressively more detailed business and technical records:

    1. Requirements are captured: the customer need is translated into product choices, dimensions, performance requirements and commercial conditions.
    2. The product is configured: a product model applies features, options, dependencies and constraints.
    3. The configuration is validated: the system checks whether the selected product can be designed, priced and manufactured within defined rules.
    4. Price and cost are calculated: list prices, discounts, material costs, labor assumptions, margins, freight or other commercial factors are applied.
    5. The quote is generated: the customer receives a commercial proposal describing the configured product, assumptions, price and delivery conditions.
    6. The order is released: an accepted quote becomes an order or sales order after approvals and commercial checks.
    7. Engineering and manufacturing data are produced: BOMs, specifications, drawings, calculations or work instructions are generated where supported.
    8. Enterprise systems are updated: ERP, product lifecycle management (PLM), product data management (PDM), CAD, manufacturing execution system (MES) or customer relationship management (CRM) systems receive the relevant data.

    Not every CPQ application performs every step. Some systems focus mainly on guided selling, pricing and quote documents. Others include product configuration, BOM generation, CAD automation and engineering workflow capabilities. A buyer must verify each downstream capability rather than treating CPQ as a single standardized product category.

    Stage 1: Capture the customer requirement

    The process begins with a business or technical requirement. This may be a salesperson selecting options, an application engineer entering operating conditions, a dealer using a web portal or a customer configuring a product through ecommerce.

    Manufacturing requirements often include more than a product name and quantity. A configuration may require:

    • capacity, flow rate, pressure, temperature or load;
    • overall dimensions, working envelope or installation constraints;
    • material, coating, ingress protection or environmental requirements;
    • motor voltage, frequency, power rating and control method;
    • connection standards, mounting arrangements or interface dimensions;
    • regulatory, safety or documentation requirements;
    • quantity, delivery location and requested date;
    • commercial terms, currency, discount authority and service requirements.

    Guided selling can help a user reach a suitable product by asking questions in business language. It may recommend a pump family based on flow and pressure, or an industrial enclosure based on environment and dimensions. Guided selling is not the same as a complete engineering rules engine. It may guide selection without proving that every detailed design constraint, component relationship or manufacturing requirement has been satisfied.

    Stage 2: Configure the product

    Product configuration is the selection and validation of a particular product variant from a defined product model. The model describes the product structure, features, options, components, relationships and rules.

    A product model for an industrial air-handling unit might contain:

    • unit size and airflow range;
    • fan type and motor selection;
    • coil arrangement and heat-transfer requirements;
    • filter class and access configuration;
    • casing material and insulation;
    • control panel and sensor options;
    • service access, mounting and connection options.

    Rules determine what can be selected together and what must happen when a choice is made. For example, selecting a high-temperature application may require a particular seal material, exclude a standard coating and trigger a special documentation requirement. Selecting a larger motor may require a different starter, cable size, enclosure or mounting arrangement.

    Manufacturers should distinguish three related approaches:

    Approach How it works Typical manufacturing use
    Rules-based configuration Explicit if-then logic controls options, dependencies and required selections. Preventing incompatible motor, material and accessory combinations.
    Constraint-based configuration Variables and constraints describe technical limits, ranges and relationships. Selecting a machine size based on load, dimensions or performance requirements.
    Guided selling Questions and recommendations help a user navigate a product family. Helping a dealer identify a suitable equipment model before detailed validation.

    These approaches can coexist, but they solve different problems. A recommendation is not necessarily a valid engineering design, and a valid configuration is not necessarily a complete manufacturing order.

    Detailed terminology and examples are covered in the guide to product configuration and configuration rules.

    Stage 3: Validate technical feasibility

    Before a quote is released, the configuration should be checked against technical and commercial rules. Validation may happen continuously as the user makes selections or as a final pre-quote step.

    Validation can include:

    • option compatibility and mandatory dependencies;
    • minimum and maximum dimensions;
    • capacity, load, flow, pressure or temperature limits;
    • material compatibility with the operating environment;
    • motor, drive, power supply and control compatibility;
    • component availability or approved-part restrictions;
    • regulatory and documentation requirements;
    • manufacturing plant, tooling or process constraints;
    • approval requirements for non-standard selections.

    Some requirements can be evaluated directly by the CPQ rules engine. Others require calculations, a lookup service, engineering review or a connected CAD, PLM or ERP system. A manufacturer should document which validations are authoritative and which are advisory.

    When the configuration falls outside the product model, the workflow may branch. The system can reject the request, offer an approved alternative, create an exception for engineering or convert the opportunity into an engineer-to-order (ETO) process. This is preferable to silently allowing a technically invalid order to reach production.

    Stage 4: Perform engineering calculations and automation

    Engineering automation is the point at which manufacturing CPQ can extend beyond sales configuration. Depending on the implementation, the system may calculate performance, size components, select standard parts, create design parameters or call an external engineering application.

    For a conveyor, calculations might involve belt width, speed, load, drive power and frame dimensions. For a pressure vessel, the design may depend on volume, pressure, material, wall thickness and applicable design rules. For a control cabinet, the configuration may determine enclosure size, heat dissipation, component count and wiring requirements.

    CAD automation can use configuration values to update a parametric model, produce a product-specific drawing or generate a three-dimensional representation. Some systems create only a visual preview; others can initiate more substantial design automation through a CAD or engineering integration. These capabilities must be verified for the specific CAD system, product model and release process.

    Engineering outputs may include:

    • calculated dimensions and performance values;
    • equipment specifications and technical datasheets;
    • product-specific 2D drawings or 3D models;
    • assembly instructions or manufacturing notes;
    • engineering change or review tasks;
    • approved component selections and design parameters.

    See CAD and engineering automation in CPQ for the relationship between product configuration, calculations, parametric CAD and drawings.

    Stage 5: Calculate cost and price

    Pricing is related to configuration but is not the same activity. Configuration determines what the product is. Pricing determines what the customer is charged under defined commercial rules.

    A manufacturing pricing model may include:

    • base product and option prices;
    • quantity breaks and customer-specific price lists;
    • material, size or performance surcharges;
    • labor, setup or engineering charges;
    • freight, installation, commissioning or service fees;
    • currency, tax and regional rules;
    • discount limits and approval thresholds;
    • target margin or cost-plus calculations.

    Costing may use standard costs, component costs, routing assumptions, purchased-part prices or other internal data. A CPQ system may calculate cost directly, retrieve it from ERP or another source, or use a simplified commercial model. Cost and price should be traceable so that users understand why an unusual configuration changes the quote.

    For example, selecting stainless steel wetted parts on a pump may change material cost, supplier lead time, manufacturing operations and selling price. The pricing logic should not be treated as an isolated discount table if the selection also affects the BOM and engineering work.

    Stage 6: Generate and approve the quote

    Once the configuration, calculations and price are acceptable, CPQ generates a quote or proposal. The document should describe the configured product clearly enough for the customer and internal reviewers to understand what is being offered.

    A manufacturing quote may contain:

    • configured product description and option summary;
    • technical specifications and operating assumptions;
    • quantity, unit price, extended price and discounts;
    • delivery estimate or lead-time assumptions;
    • drawings, images or datasheets where appropriate;
    • exclusions, exceptions and customer responsibilities;
    • validity period, payment terms and approval conditions.

    Approval workflows can be triggered by margin, discount, non-standard components, unusual delivery requirements, contractual terms or engineering exceptions. Approval does not automatically mean the configuration is production-ready. It confirms that the organization accepts the commercial and, where applicable, technical conditions of the quote.

    Stage 7: Convert the accepted quote into an order

    After customer acceptance, the quote becomes an order or sales order. This conversion should preserve the exact configuration version that was quoted. Re-keying options manually into an ERP system creates a risk that the ordered product differs from the approved product.

    Important order data can include:

    • product model and configuration identifier;
    • selected options, values and quantities;
    • calculated dimensions and engineering parameters;
    • price, discount, currency and commercial terms;
    • customer, ship-to and billing information;
    • requested delivery date and manufacturing location;
    • attached drawings, specifications and approval records;
    • status of engineering exceptions and customer approvals.

    Version control matters when product rules or prices change between quote and order. The manufacturer should decide whether the order uses the rules and prices from the quotation date, order date or a controlled product release.

    Stage 8: Generate the BOM and manufacturing data

    A bill of materials is a structured list of parts, assemblies, quantities and relationships required for a product. Manufacturing CPQ may generate or select a BOM, but the result must be defined carefully.

    An engineering bill of materials (EBOM) represents the product from an engineering design perspective. A manufacturing bill of materials (MBOM) represents how the product is assembled or produced, including manufacturing structure, operations or plant-specific requirements. A configurable BOM contains rules or option relationships that resolve into a product-specific structure after configuration.

    For a configured electrical enclosure, the resolved data might include the enclosure, mounting plate, circuit breakers, contactors, terminal blocks, wiring accessories, labels and documentation. The MBOM may additionally reflect assembly cells, kits, consumables or production steps that are not organized in the same way as the EBOM.

    Data object Purpose Typical owner or system
    Product model Defines features, options, rules and configuration behavior. CPQ, product management or configuration engineering.
    EBOM Describes the engineered product structure. PLM, PDM or engineering system.
    MBOM Describes the production structure and assembly view. ERP, MES or manufacturing engineering system.
    Sales order Records the commercial commitment and ordered configuration. ERP or order management system.
    CAD output Provides product-specific geometry, drawings or models. CAD, PDM or PLM system.

    Some CPQ implementations create a complete resolved BOM. Others send configuration parameters to ERP, PLM or an engineering application that owns BOM generation. The integration contract should specify which system is authoritative for each object.

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

    Stage 9: Handoff to ERP, PLM, PDM, CAD and MES

    Manufacturing CPQ is usually part of a wider application architecture:

    • CRM stores customer, opportunity and sales activity information. It may launch the CPQ process but is not normally the authoritative source for manufacturing structures.
    • ERP manages enterprise transactions such as sales orders, inventory, purchasing, production planning, costing and financial data.
    • PLM manages product lifecycle information, revisions, approvals, changes and engineering collaboration.
    • PDM manages product data and CAD files, often with controlled revisions and document relationships.
    • CAD creates or modifies product geometry, drawings and models.
    • PIM, or product information management, manages product content and attributes for publishing and sales channels.
    • MES, or manufacturing execution system, manages or records production execution on the shop floor.

    Integration can be synchronous, such as a real-time availability or pricing call, or asynchronous, such as sending an approved order to an ERP queue. Common exchange methods include application programming interfaces (APIs), middleware, files, webhooks and controlled batch processes.

    The integration should define identifiers, ownership, revision behavior, error handling, retries, security and audit history. A successful API call does not prove that the receiving system accepted a technically complete order. Reconciliation and exception monitoring are necessary.

    See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD, PIM and MES.

    How CTO, ETO, MTO and ATO fit the workflow

    The downstream process depends on the manufacturer’s fulfillment model:

    Model Meaning CPQ and production implication
    Configure-to-order (CTO) A product is selected from approved options and assembled or produced after the order. Strong configuration validation and resolved order data are important; engineering intervention may be limited.
    Engineer-to-order (ETO) Engineering work creates or adapts the product for a specific customer. CPQ captures requirements, defines the commercial baseline and routes exceptions or projects to engineering.
    Make-to-order (MTO) Production begins after the order rather than from finished-goods stock. CPQ must provide accurate specifications, lead-time assumptions and order data.
    Assemble-to-order (ATO) Predefined modules are assembled after the order. Configuration resolves the correct modules, components and assembly instructions.

    These categories can overlap. An industrial machine may be configure-to-order at the module level but engineer-to-order for its foundation, guarding or site interfaces. The CPQ workflow should expose that boundary rather than promise that every configuration can be fulfilled without engineering.

    The relationship between sales configuration and fulfillment is explained further in the guide to CTO, ETO, MTO, ATO and order-to-production workflows.

    Practical example: configuring an industrial pump skid

    Consider a pump manufacturer selling packaged pump skids. A sales engineer enters required flow, discharge pressure, fluid temperature, fluid composition, power supply and installation environment.

    1. The product model recommends a suitable pump family and available frame size.
    2. Rules require a compatible impeller range, seal material and motor configuration.
    3. A calculation checks the duty point and identifies whether a standard or special impeller is appropriate.
    4. The configuration adds valves, gauges, base frame, coupling guard and control panel options.
    5. Pricing applies component prices, a skid assembly charge, engineering fees and an approved discount.
    6. The quote includes the selected pump, duty assumptions, exclusions and expected delivery conditions.
    7. After acceptance, the configuration is transferred to ERP and the engineering system.
    8. A resolved EBOM is created or requested, while manufacturing engineering prepares the MBOM and routing.
    9. CAD automation may produce a layout drawing if the skid dimensions and interfaces are within the supported model.
    10. If the customer requires an unusual nozzle location or a non-standard material, the order is routed for ETO review instead of being released automatically.

    This example shows why quote accuracy depends on more than a price calculation. The same option can affect technical feasibility, cost, lead time, BOM structure, drawings and production work.

    Benefits of connecting quote and production

    • Fewer transcription errors: validated configuration data can flow into order and engineering systems without repeated manual entry.
    • Faster engineering response: standard configurations and calculations can be automated, leaving engineers to review exceptions.
    • More reliable pricing: option, material, labor and engineering effects can be represented in a controlled model.
    • Clearer customer expectations: the quote can show the exact product assumptions, limitations and deliverables.
    • Better production readiness: BOMs, specifications and drawings can be prepared earlier in the order lifecycle.
    • Improved product governance: changes to options, rules and approved components can be managed centrally.

    Limitations and common failure points

    CPQ does not eliminate the need for product data governance or engineering judgment. Common failure points include:

    • incomplete or contradictory product rules;
    • old price lists, costs or supplier data;
    • product models that do not reflect current engineering revisions;
    • unclear ownership between CPQ, ERP, PLM and CAD;
    • an EBOM that cannot be transformed into a usable MBOM;
    • calculations that work only for a narrow range of products;
    • uncontrolled manual overrides and undocumented exceptions;
    • integration failures that are not visible to sales or operations;
    • attempting to model genuinely new ETO designs as if they were standard options.

    A quote can be commercially valid but not production-ready. Production readiness requires agreed technical data, correct revisions, manufacturable structures, approved exceptions and a reliable handoff to the systems that execute the order.

    Implementation considerations

    Manufacturers planning a quote-to-production CPQ workflow should begin with a representative product family rather than attempting to model the entire catalog at once.

    Define ownership and scope

    Document which system owns product options, rules, prices, costs, revisions, BOMs, CAD files, customer data and order status. Decide whether CPQ generates a BOM or sends parameters to another system. Define the point at which a configuration becomes an engineering project.

    Build and test the product model

    Capture option definitions, dependencies, constraints, calculations, default values, units of measure and exception paths. Test valid configurations, invalid combinations, boundary values, changed revisions and manually approved exceptions. Include product experts, sales engineering, manufacturing engineering, IT and operations in testing.

    Control data and releases

    Rules, prices, components, drawings and integration mappings need controlled release processes. A change to a motor, material or accessory may affect configuration logic, cost, lead time, BOM, CAD and documentation. Treat the product model as an engineered asset, not merely a sales form.

    Measure the complete workflow

    Useful measures include quote cycle time, configuration error rate, engineering hours per order, percentage of quotes requiring manual correction, order-entry rework, quote-to-order conversion, BOM accuracy, integration failure rate and time from order acceptance to production release. Metrics should cover downstream quality, not only sales speed.

    More guidance is available in the manufacturing CPQ implementation guide.

    FAQ: manufacturing CPQ from quote to production

    1. What is the manufacturing CPQ workflow?

    It is the process of capturing requirements, configuring a product, validating technical choices, calculating price, generating a quote, converting the accepted quote into an order and transferring production-relevant data to engineering and manufacturing systems.

    2. How is manufacturing CPQ different from sales CPQ?

    Sales CPQ usually emphasizes guided selling, pricing, approvals and quote documents. Manufacturing CPQ may also manage technical rules, calculations, BOMs, CAD outputs, engineering exceptions and ERP, PLM or production handoffs.

    3. Does CPQ always generate a BOM?

    No. Some CPQ platforms generate resolved BOMs, while others send configuration parameters to ERP, PLM or an engineering system that owns BOM creation. This capability must be verified for the product and platform.

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

    A configurable BOM contains rules or option relationships that resolve for a selected product. An EBOM is the engineering view of a specific product structure. A configured product may use a configurable BOM to produce an EBOM.

    5. Does a CPQ system create an MBOM?

    Not necessarily. An MBOM represents the manufacturing view of the product and may be created in ERP, MES or a manufacturing engineering system. CPQ may supply the resolved product and component data needed to create it.

    6. Can CPQ automate CAD drawings?

    Some implementations can drive parametric CAD or generate drawings through an integration. Others provide only images or configuration data. The manufacturer should verify supported CAD systems, model complexity, revision control and approval workflows.

    7. When should a configuration become an ETO project?

    It should become ETO when the request requires new design work, an unsupported geometry, unusual interfaces, non-standard calculations or an engineering decision outside the approved product model.

    8. Can CPQ calculate product performance?

    It can, if the platform includes suitable calculation logic or connects to an engineering calculation service. Calculations should be validated against engineering methods and defined operating ranges.

    9. What information should move from CPQ to ERP?

    Typical data includes the customer and ship-to details, ordered configuration, item identifiers, quantities, prices, dates, commercial terms, configuration version and references to drawings or technical documents.

    10. Is CRM the same as CPQ?

    No. CRM manages customer and opportunity relationships. CPQ manages product selection, configuration, pricing and quoting. The systems may be integrated, but they have different purposes.

    11. What is the role of PLM in the workflow?

    Product lifecycle management (PLM) manages product definitions, revisions, approvals, changes and engineering information. It may be the authoritative source for product structures or CAD-related data that CPQ uses during configuration.

    12. Can a dealer use manufacturing CPQ?

    Yes. A dealer can use a controlled CPQ interface to configure products, apply permitted commercial rules and submit orders or opportunities. Access, pricing authority and technical complexity should be governed by the manufacturer.

    13. How are non-standard options handled?

    The system can block them, suggest an approved alternative, require an approval or route the request to engineering. The correct approach depends on risk, product strategy and the manufacturer’s ETO process.

    14. What happens if product rules change after a quote is issued?

    The manufacturer should preserve the quote’s configuration and rule version, then define whether the accepted order is revalidated against the new release. Any material change should be visible and controlled.

    15. Can CPQ manage lead times?

    It can display or calculate lead-time assumptions when connected to reliable component, capacity or planning data. Many systems use estimated lead times rather than a complete production schedule, so the source and accuracy of the value must be understood.

    16. Does CPQ replace ERP or PLM?

    No. CPQ complements ERP, PLM, CAD and other systems. It manages the configuration and commercial workflow, while each enterprise system retains its defined operational or engineering responsibilities.

    17. What is the biggest implementation risk?

    A common risk is automating an incomplete product model. If rules, components, prices, revisions and exception paths are not governed, CPQ can reproduce errors faster rather than create production-ready orders.

    18. How should a manufacturer start a CPQ project?

    Select a representative product family, document the current quote-to-production process, define system ownership, model the rules and test the complete handoff through order and engineering release before expanding scope.

    Semantic map

    The article connects the following entities and relationships:

    • Customer requirements lead to product configuration.
    • Product configuration applies options, dependencies and constraints.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate technical feasibility.
    • Validated configuration determines cost and price.
    • Configured products generate product-specific order data.
    • Resolved configurations can generate or select BOM structures.
    • EBOM represents the engineered product structure.
    • MBOM represents the manufacturing product structure.
    • CAD automation can generate product-specific drawings.
    • Accepted quotes become sales orders.
    • CPQ exchanges configuration and commercial data with ERP.
    • PLM manages product revisions and engineering changes.
    • ETO handles designs outside the approved product model.
    • MES can receive production-relevant information from enterprise systems.

    A manufacturing CPQ workflow is successful when the accepted quote remains consistent with the product that engineering and production are asked to build. The objective is not simply a faster proposal. It is a controlled chain from customer requirement to validated configuration, accurate commercial commitment and usable production data.

  • CPQ for Engineer-to-Order Manufacturing

    CPQ for engineer-to-order manufacturing helps manufacturers convert a customer requirement into a technically valid, priced and manufacturable order. It does more than generate a sales quote. A manufacturing CPQ system can capture application data, apply product rules, perform engineering calculations, identify standard and custom components, create a configurable bill of materials (BOM), initiate CAD or engineering work, and transfer approved order data to enterprise systems.

    Engineer-to-order (ETO) products are designed or substantially engineered for a specific customer after the order or quotation process begins. Examples include custom pumping systems, industrial machinery, material-handling equipment, process skids, large electrical assemblies and specialty vehicles. In these environments, the central question is not simply “What is the price?” It is “Can this product be designed, manufactured and delivered within the stated requirements, and what data is needed to do so?”

    This guide explains how CPQ fits into that process, which data and rules it requires, how it connects with engineering and production systems, and where its limitations must be managed.

    What is CPQ for engineer-to-order manufacturing?

    CPQ for engineer-to-order manufacturing is software that supports the configuration, pricing, quoting and engineering handoff of products that require customer-specific design or validation. CPQ means configure, price, quote. In an ETO context, configuration usually defines the design basis and requirements rather than producing a completely finished product definition without engineering involvement.

    A suitable CPQ process should distinguish between three outcomes:

    • Standard configuration: The selected options fit an existing product model and can often proceed through configure-to-order or make-to-order production.
    • Configured variant: The selection is valid but requires a product-specific BOM, calculation, drawing or engineering review.
    • New or exceptional design: The requirements exceed the approved product model and must be handled as an engineering project, with controlled assumptions, approvals and design work.

    CPQ does not replace computer-aided design (CAD), product lifecycle management (PLM), enterprise resource planning (ERP) or manufacturing execution system (MES). Instead, it coordinates information between these systems when the product model and integrations are designed appropriately. Not every CPQ platform supports BOM generation, CAD automation, engineering calculations or ETO workflows, so each capability must be verified during software evaluation.

    See the broader manufacturing CPQ guide for an overview of CPQ architecture and use cases.

    How ETO CPQ differs from generic sales CPQ

    Generic sales CPQ typically focuses on selecting commercial options, applying discounts and producing a proposal. That may be adequate for standardized products or subscription services. ETO manufacturing requires a deeper product and engineering model.

    Concern Generic sales CPQ ETO manufacturing CPQ
    Configuration Option selection and compatibility checks Technical requirements, dimensions, materials, ratings, capacities and constraints
    Pricing List prices, discounts and commercial rules Material, labor, purchased parts, engineering effort, risk, overhead, freight and margin
    Output Quote or proposal Validated requirements, configuration data, cost basis, BOM inputs and engineering work package
    Engineering Usually outside the CPQ workflow Calculations, CAD parameters, design review and controlled exceptions may be included
    Production handoff Order details for fulfillment Production-relevant master data, revisions, documents and approval status
    Exceptions Often handled manually Classified as standard, configurable, configurable-with-review or new design

    The distinction is important when selecting software. A platform may be strong at guided selling and proposal generation while having limited support for engineering calculations or manufacturing BOMs.

    The ETO CPQ workflow from requirement to production

    The exact workflow varies by industry and product architecture, but a practical ETO process usually contains the following stages.

    1. Capture the customer requirement

    The process begins with application and technical requirements rather than only a product name. A sales engineer may record flow rate, pressure, temperature, fluid properties, operating environment, required capacity, footprint, voltage, compliance requirements and delivery constraints for a pumping system. For a conveyor, the inputs may include load, length, elevation, throughput, belt type, motor characteristics and site conditions.

    Requirements should be represented as structured data wherever possible. Free-text notes are useful for context, but they are difficult to validate, calculate or transfer reliably to engineering and ERP systems.

    2. Apply product rules and constraints

    The CPQ product model evaluates whether the requested combination is allowed. Rules can express dependencies, exclusions, required selections, ranges and conditional behavior. For example:

    • A high-temperature seal requires a compatible elastomer and may exclude a standard coating.
    • A pump operating above a specified pressure requires a particular casing material and inspection level.
    • A vehicle body length may require a different chassis, axle rating and braking package.
    • A motor voltage must match the selected electrical enclosure and control system.
    • A structural span above a defined length may require an additional support assembly.

    Rules-based configuration uses explicit product logic such as “if option A is selected, require component B.” Constraint-based configuration evaluates permitted values and relationships, such as dimensional, capacity or compatibility limits. Guided selling leads a user through questions and recommendations but does not, by itself, guarantee complete engineering validation. These approaches may be combined.

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

    3. Perform engineering calculations

    Many ETO products cannot be priced or selected correctly without calculations. A CPQ application may contain calculation logic, call an external engineering service or pass requirements to a specialized application. Possible calculations include pump head and flow selection, heat-exchanger sizing, motor power, structural loading, pressure ratings, cable sizing, storage capacity and vehicle payload.

    Calculations should identify their inputs, formulas, units, assumptions, valid ranges and revision. A result such as “recommended motor: 30 kW” should be traceable to the requirements and calculation version that produced it. If the calculation is only advisory, the workflow should make clear that engineering approval remains necessary.

    4. Determine the engineering path

    After validation, the system can classify the order. A standard configuration may proceed automatically. A valid but unusual configuration may require an engineering review. A genuinely new design may create an engineering task with requirements, assumptions, selected reference products and customer documents.

    This classification prevents two common mistakes: sending an invalid order directly to production, or sending every order through a slow manual engineering process even when the design is already covered by approved rules.

    5. Calculate cost and price

    ETO pricing may include material, purchased components, manufacturing labor, engineering hours, testing, documentation, tooling, freight, installation and project risk. CPQ can calculate a target cost and apply pricing policies, but the calculation depends on reliable source data.

    Costing and pricing are related but different. Costing estimates what the manufacturer is expected to spend. Pricing determines what the customer is charged after considering margin, market conditions, commercial policy and risk. Engineering changes after quotation may require a revised cost and price.

    For related concepts, see the guide to BOM generation, pricing and quote automation.

    6. Generate quote and approval data

    The quotation should describe the technical basis of the offer. It may include selected options, operating assumptions, performance values, exclusions, delivery assumptions, documentation, testing and validity conditions. A technically detailed quote reduces ambiguity when the order moves from sales to engineering.

    Approval rules may be triggered by discount level, margin, non-standard materials, unusual delivery requirements, export restrictions, contractual terms or technical risk. Approvals should preserve the configuration revision and the price version used to create the offer.

    7. Create the engineering and manufacturing handoff

    When the customer accepts the quote, the approved configuration becomes an order baseline. The handoff may contain:

    • customer and project identifiers;
    • requirements and operating conditions;
    • selected options and parameter values;
    • calculation results and assumptions;
    • approved exceptions and deviations;
    • cost and price information where appropriate;
    • component and material requirements;
    • BOM or BOM-generation instructions;
    • CAD parameters, reference models or drawing requests;
    • required certificates, inspections and documentation;
    • revision, approval and change-control status.

    The goal is not merely to send a PDF to engineering. It is to send structured, versioned data that can be reused by PLM, CAD, ERP and production processes.

    How product data becomes production-ready

    A central ETO CPQ design question is how a commercial configuration becomes an engineering and manufacturing definition. This normally requires several related data structures.

    Product model

    The product model defines features, options, parameters, relationships, rules, calculations and outputs. It may include a machine family, allowable dimensions, compatible materials, standard assemblies and approved alternatives. The model should describe what users may select and what the organization is prepared to support.

    Configurable BOM

    A configurable BOM contains rules or selection logic that expands into a product-specific list of components. For example, a pump model may include one of several impellers, a selected seal package, a motor, coupling, baseplate, instrumentation and documentation package.

    The configurable BOM is not necessarily the final manufacturing BOM. It may be an intermediate structure used to derive an engineering BOM (EBOM) or manufacturing BOM (MBOM).

    • EBOM: An engineering bill of materials organized around the designed product and its functional or design structure.
    • MBOM: A manufacturing bill of materials organized around how the product is assembled, fabricated, inspected and produced.
    • Configurable BOM: A rule-driven structure that resolves into selected components based on configuration inputs.

    Some CPQ systems generate a complete BOM. Others send configuration parameters to ERP or PLM, where the BOM is expanded. The ownership of each structure must be defined rather than assumed.

    CAD and engineering outputs

    CAD automation can use configuration values to select models, set dimensions, create assemblies or generate drawings. In an enclosure project, for example, the configured width, height, mounting pattern and cable-entry arrangement may drive a parametric CAD model.

    However, CAD automation has technical prerequisites: stable templates, controlled parameters, naming conventions, compatible revisions and a way to handle geometry that falls outside the template. A CPQ platform that displays a 3D product image is not necessarily capable of generating production CAD.

    Read more about CAD, engineering and design automation.

    System architecture and integrations

    ETO CPQ normally sits between customer-facing processes and engineering or enterprise systems. The architecture should define which system owns each type of data.

    System Typical responsibility Possible CPQ exchange
    CRM Customer, opportunity, contacts and sales activity Opportunity context, account, quote status and acceptance
    CPQ Configuration, calculations, pricing, quote and handoff logic Validated configuration and commercial outputs
    CAD Geometric design and engineering models Parameters, references, models and drawing requests
    PDM Product data and CAD document control Files, metadata, revisions and approved references
    PLM Product structures, lifecycle, revisions and change management EBOM, requirements, specifications and engineering status
    ERP Items, inventory, purchasing, costing, orders and planning Items, sales order, BOM, routing and pricing data
    MES Shop-floor execution and production records Released work instructions, routings or production identifiers
    PIM Commercial product information and content Descriptions, attributes and customer-facing content

    CRM, ERP, PLM, PDM, PIM and MES are not interchangeable. Integration should specify data ownership, identifiers, revision behavior, error handling, security and timing. The CPQ integration guide covers these system relationships in more detail.

    CTO, ETO, MTO and ATO in one process

    Manufacturers often support several fulfillment models. Configure-to-order (CTO) uses predefined options and generally approved product structures. Engineer-to-order (ETO) requires customer-specific engineering. Make-to-order (MTO) means production starts after an order but may use an established design. Assemble-to-order (ATO) combines stocked or prebuilt modules after the order.

    Model Design status at order Typical CPQ role
    CTO Defined by approved options Validate selections, price and generate order configuration
    ETO Requires customer-specific engineering Capture requirements, calculate, price, route engineering and control revisions
    MTO Established design, produced after order Validate demand, price and trigger production supply
    ATO Modules already available Configure the finished combination and reserve or trigger assembly

    One product family may move between these models. A standard pump package may be CTO, while a custom skid with site-specific piping, controls and structural requirements is ETO. The CPQ workflow should make this distinction explicit.

    See the guide to CTO, ETO, MTO, ATO and order-to-production workflows.

    Benefits of CPQ in ETO manufacturing

    • Earlier technical validation: Invalid combinations and missing requirements can be identified before order entry.
    • Faster engineering triage: Engineers can focus on exceptions and new designs rather than rechecking routine selections.
    • More consistent costing: Material, labor, engineering and risk inputs can be calculated from the same configuration.
    • Better quote quality: Assumptions, exclusions and technical outputs are tied to a specific revision.
    • Reduced order-entry errors: Structured configuration data is less ambiguous than manually rekeyed descriptions.
    • Improved reuse: Approved product rules, calculations and templates can be reused across sales channels.
    • Traceable handoff: Sales, engineering, purchasing and production can reference the same approved order basis.

    Limitations and risks

    ETO CPQ is not a shortcut around product governance or engineering complexity. Its effectiveness is limited by the quality and scope of the product model.

    • Incomplete rules: Undocumented engineering knowledge still produces manual review and order risk.
    • Rule explosion: A large number of exceptions can make the model difficult to test and maintain.
    • Unbounded customization: A product that is effectively redesigned for every customer may not be suitable for full automation.
    • Unreliable source data: Incorrect costs, item identifiers, dimensions or revisions undermine every downstream output.
    • Integration complexity: Different systems may use different item structures, units, revisions and approval states.
    • False confidence: A configuration can be logically valid while still requiring engineering judgment, regulatory review or site verification.
    • Maintenance burden: Product changes, supplier substitutions and manufacturing changes must be reflected in rules and outputs.

    A useful design principle is to automate repeatable decisions and expose uncertain decisions for controlled human review. The system should show why an option is unavailable, which assumption produced a result and what remains unapproved.

    Implementation approach

    Start with a bounded product family

    Select a product family with meaningful configuration volume, recurring engineering work and reasonably stable rules. Avoid beginning with the entire catalog or with a product whose design process is still changing rapidly.

    Document the decision model

    Work with sales engineering, design engineering, manufacturing, costing and IT to document inputs, constraints, calculations, outputs and exceptions. Identify rules that are mandatory, advisory or subject to approval.

    Define data ownership

    Decide whether CPQ, ERP, PLM, PDM or another system owns items, descriptions, revisions, costs, BOMs, CAD files and manufacturing structures. Define how approved data moves between systems.

    Separate reusable logic from customer-specific data

    Product rules and approved templates should not be mixed indiscriminately with customer notes or project assumptions. This separation makes the model easier to govern and reuse.

    Test engineering edge cases

    Testing should include valid standard configurations, invalid combinations, boundary values, unit conversions, unavailable components, obsolete items, manual overrides, revision changes and integration failures. Test the generated quote, BOM, CAD request and ERP transaction—not only the screen flow.

    Establish release governance

    Assign owners for product rules, calculations, pricing, item data, templates and integrations. Use version control, approval status and change-impact analysis. A product change that affects a seal, motor, material or regulatory requirement may affect configuration rules, costs, CAD and production data simultaneously.

    The CPQ implementation guide provides a broader framework for requirements, migration, testing, deployment and governance.

    How to evaluate ETO CPQ software

    Manufacturers should evaluate an ETO-capable CPQ platform against actual product and engineering scenarios rather than generic feature counts. Ask vendors to demonstrate:

    • multi-level product models and reusable rules;
    • dimensional, capacity and compatibility constraints;
    • unit handling and engineering calculations;
    • configuration statuses and human approval steps;
    • configurable BOM expansion and EBOM or MBOM handoff;
    • CAD parameters, drawing requests or documented CAD integrations;
    • cost and price separation;
    • revision and change-control behavior;
    • ERP, PLM, PDM, CRM and CAD integration patterns;
    • API availability and error handling;
    • performance with large product models;
    • rule testing, audit trails and model governance;
    • support for dealer, distributor and internal engineering users;
    • handling of configurations that exceed the approved product model.

    Ask the vendor to identify which capabilities are native, which require configuration, which depend on partner or external systems, and which are not supported. A product configurator, quoting tool and engineering automation platform may be combined in one product or implemented as separate components.

    Practical example: engineer-to-order pump package

    Consider a manufacturer quoting a pump package for a chemical-processing site. The customer provides flow, differential pressure, fluid temperature, fluid properties, hazardous-area requirements, voltage, materials, instrumentation and delivery conditions.

    1. CPQ captures the structured requirements and checks units and required fields.
    2. A selection or calculation service identifies suitable pump families and motor ranges.
    3. Rules require compatible casing, impeller, seal, motor, controls and hazardous-area components.
    4. The product model identifies standard components and flags the custom base frame and piping arrangement for engineering.
    5. Costing includes purchased items, fabrication, engineering, testing and documentation.
    6. The quote records operating assumptions, exclusions and the technical approval status.
    7. After acceptance, the approved configuration and calculation results create an engineering work package.
    8. Engineering produces or approves the design, while PLM or PDM controls drawings and revisions.
    9. ERP receives the order and the appropriate product, BOM, purchasing and production information.

    In this example, CPQ does not need to pretend that every design decision is automated. Its value is to validate what can be validated, preserve the requirements, identify the engineering boundary and prevent the approved commercial configuration from being lost during handoff.

    Semantic map

    The following relationships summarize how ETO CPQ connects commercial, engineering and manufacturing concepts:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate application requirements.
    • A configured product generates or drives a configurable BOM.
    • A configurable BOM can produce an EBOM or provide inputs to one.
    • An EBOM can be transformed into an MBOM for production.
    • CAD automation generates product-specific models or drawings.
    • CPQ exchanges customer and order data with CRM.
    • CPQ exchanges items, orders and BOM data with ERP.
    • PLM manages product structures, revisions and lifecycle status.
    • PDM controls CAD files and engineering documents.
    • ETO requires customer-specific engineering.
    • CTO uses approved configuration options.
    • Pricing converts cost and commercial rules into a customer price.
    • An approved quote becomes an order baseline for engineering and production.

    Frequently asked questions

    1. What does CPQ mean in engineer-to-order manufacturing?

    CPQ means configure, price, quote. In ETO manufacturing, it captures technical requirements, validates selections, supports calculations and produces a controlled quote and engineering handoff.

    2. Can CPQ replace engineering in an ETO business?

    No. CPQ can automate repeatable decisions and route exceptions, but engineering judgment remains necessary for new designs, unusual conditions, compliance and final approval.

    3. Does every CPQ system support engineer-to-order workflows?

    No. Some products focus on sales configuration and quoting. Buyers must verify support for calculations, approvals, BOMs, CAD, revisions, engineering handoff and relevant integrations.

    4. How does ETO CPQ differ from configure-to-order CPQ?

    Configure-to-order generally selects from approved product options. ETO CPQ must also capture requirements, manage customer-specific design work and control the transition from quote to engineering.

    5. Can CPQ generate a manufacturing BOM?

    Some systems can generate or expand BOMs, while others send configuration data to ERP or PLM. The buyer must verify whether the system creates an EBOM, MBOM, configurable BOM or only BOM instructions.

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

    An EBOM represents the designed product structure. An MBOM represents how the product is assembled or manufactured. They may contain related but differently organized information.

    7. Can CPQ automate CAD for custom products?

    Some CPQ solutions support CAD parameters, model generation or drawing workflows through native or external tools. A visual configurator alone does not prove production CAD automation.

    8. What engineering calculations can ETO CPQ perform?

    Depending on the platform and implementation, calculations may cover sizing, capacity, pressure, power, loading, dimensions, materials or compatibility. Each calculation must be validated for its intended engineering use.

    9. How does CPQ handle a requirement outside the product model?

    It may reject the input, flag an exception, route the opportunity for engineering review or create a new design task. The correct behavior depends on company policy and product risk.

    10. Should CPQ own product data or should PLM own it?

    Ownership varies. CPQ commonly owns configuration and quote logic, while PLM owns product structures and lifecycle data. The architecture must explicitly define ownership and synchronization.

    11. Is ERP integration required for ETO CPQ?

    It is not technically mandatory, but integration is often important for item data, costs, sales orders, purchasing, inventory, BOMs and production planning.

    12. What role does CRM play in an ETO workflow?

    CRM typically provides account, opportunity and customer context. CPQ adds technical configuration and commercial calculation, then returns quote status and value to CRM.

    13. Can CPQ calculate the price of engineering effort?

    Yes, if engineering effort is modeled through estimated hours, task types, rates, complexity factors or project rules. The resulting estimate should be distinguished from actual labor recorded later.

    14. How should manufacturers test an ETO CPQ model?

    Test standard, boundary, invalid and exceptional configurations, along with calculations, prices, revisions, BOM outputs, CAD requests and system integration failures.

    15. What data is needed to implement ETO CPQ?

    Typical inputs include product options, rules, dimensions, materials, item masters, costs, prices, engineering formulas, BOM structures, CAD templates, approval policies and integration identifiers.

    16. Can one CPQ system support both CTO and ETO?

    Potentially. A product family can use automated CTO paths for approved variants and route more complex selections into ETO review. The platform must support different statuses and workflows.

    17. How does CPQ reduce sales-to-engineering errors?

    It replaces ambiguous manual descriptions with structured requirements, validated selections, explicit assumptions, revision information and reusable order data.

    18. What is the biggest implementation risk?

    A common risk is automating an incomplete or poorly governed product model. The software cannot reliably compensate for undocumented rules, inconsistent item data or unclear engineering ownership.

    19. Should every ETO exception be automated?

    No. Automation is appropriate for repeatable and well-understood decisions. Novel, high-risk or poorly bounded designs should remain subject to controlled human review.

    20. What should a manufacturer ask during a CPQ demonstration?

    Use a real product scenario and ask the vendor to show requirements capture, constraints, calculations, costing, quote revision, engineering review, BOM output, integration behavior and handling of an out-of-model request.

  • Quote Automation for Complex Manufactured Products

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

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

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

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

    What quote automation means in manufacturing

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

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

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

    How automated quoting works

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

    1. Capture customer requirements

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

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

    2. Select and validate the product configuration

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

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

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

    3. Perform engineering calculations

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

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

    4. Generate a product structure or BOM

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

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

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

    5. Calculate cost

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

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

    6. Apply pricing and commercial rules

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

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

    7. Route exceptions and approvals

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

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

    8. Generate the quote document

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

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

    Reference architecture for manufacturing quote automation

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

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

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

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

    Manufacturing example: quoting a configured industrial pump

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

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

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

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

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

    Where quote automation fits different manufacturing workflows

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

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

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

    Benefits of quote automation for manufacturers

    Shorter response cycles

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

    Fewer configuration and pricing errors

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

    Better engineering capacity

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

    More consistent manufacturing data

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

    Improved margin visibility

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

    Traceable decisions

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

    Limitations and risks

    Incorrect product models produce repeatable errors

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

    Engineering knowledge is difficult to encode

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

    Cost data may not be current

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

    BOM maturity may be misunderstood

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

    ETO remains partially manual

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

    Integration creates operational dependencies

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

    Rules can become difficult to maintain

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

    Data required for automated quoting

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

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

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

    Implementation approach

    Define the first product scope

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

    Document the current quote process

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

    Build a governed product model

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

    Separate configuration, cost and price

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

    Design the system handoff

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

    Test combinations and revisions

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

    Release and govern the model

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

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

    How to evaluate quote automation software

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

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

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

    Key measures after deployment

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

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

    Related concepts

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

    Semantic map

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

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

    Frequently asked questions

    What is quote automation for complex manufactured products?

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

    How is manufacturing quote automation different from sales CPQ?

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

    Does quote automation generate a BOM?

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

    Can CPQ calculate the cost of a configured product?

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

    What is the difference between costing and pricing in CPQ?

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

    Can quote automation handle engineer-to-order products?

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

    Can a CPQ system create CAD drawings?

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

    What product data is needed to automate quotes?

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

    Where should configuration rules be maintained?

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

    How does quote automation connect with ERP?

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

    Does quote automation replace application engineers?

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

    How are invalid configurations prevented?

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

    Can quote automation manage different currencies and customer prices?

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

    What is a configurable BOM?

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

    How should manufacturers test an automated quoting model?

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

    What are the main risks of automated quoting?

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

    How should a manufacturer choose a quote automation platform?

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

    What is the first product family to automate?

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

    How can a manufacturer measure quote automation success?

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

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