A pricing engine in manufacturing CPQ is the software component that calculates the commercial price of a valid configured product. It uses the selected options, dimensions, materials, quantities, manufacturing data, cost records, customer terms, currencies, discounts and margin policies to produce a price that can be quoted and approved.
In a simple sales CPQ system, pricing may mean adding products, quantities and discounts to a price list. Manufacturing CPQ usually requires more. A configured pump, industrial enclosure, conveyor, machine or specialty vehicle may have dimensions, performance requirements, materials, motors, controls and safety options that change the bill of materials (BOM), manufacturing effort and final price. The pricing engine must therefore work with the product configuration and, in some implementations, with engineering calculations, cost estimates and generated manufacturing data.
The pricing engine is not the same as the product configuration engine. The configuration engine determines whether a product combination is valid. The pricing engine determines what that valid combination costs and what the customer should be charged. They normally operate as connected services in a broader configure, price, quote (CPQ) workflow.
For a broader explanation of BOM generation, pricing and quote automation, see the related CPQ Guide resource.
What a manufacturing CPQ pricing engine does
A manufacturing pricing engine transforms product and commercial data into a price calculation. A typical calculation may include:
- base product or assembly price;
- configured options and accessories;
- quantity-based pricing;
- dimensions, capacity or performance calculations;
- materials and purchased components;
- labor, machine time and subcontracting;
- setup, tooling, engineering and testing charges;
- freight, packaging and installation;
- customer, channel or project-specific discounts;
- currency conversion, taxes and payment terms;
- target margin and approval thresholds.
The engine may calculate a selling price directly from a price list, or it may first calculate an estimated or standard cost and then apply a markup or margin rule. More advanced manufacturing implementations calculate prices from a generated or derived BOM, routing assumptions, engineering formulas or external costing services.
Where pricing fits in the manufacturing CPQ workflow
Pricing is one stage in a chain of dependent decisions. A typical workflow is:
- Product selection: A salesperson, dealer, engineer or customer selects a product family.
- Configuration: The user selects features such as capacity, dimensions, motor type, material and controls.
- Validation: Rules and constraints identify incompatible or incomplete selections.
- Engineering calculation: The system may calculate performance, sizing, power, loads or other technical values.
- BOM derivation: The configured product is mapped to components, assemblies and quantities.
- Cost calculation: Material, labor, purchased parts, overhead and special work are estimated or retrieved.
- Price calculation: Price lists, markups, discounts, surcharges, freight and commercial policies are applied.
- Approval: Exceptions such as low margin, unusual terms or non-standard engineering are routed for review.
- Quote generation: The system produces a customer-facing quote and, where supported, internal BOM, CAD or order data.
Not every CPQ platform performs every step. Some systems calculate price and produce a proposal while relying on an enterprise resource planning (ERP) system for costs and a product lifecycle management (PLM) or product data management (PDM) system for engineering data. Buyers should verify which system owns each calculation and how results are exchanged.
Core data used by a pricing engine
Product and option data
The engine needs a product model that identifies base products, options, accessories, variants and dependencies. For example, a pump model may have selectable flow range, head, impeller material, seal type, motor rating, voltage and control package. Each selection can add a price, replace a standard component or trigger a calculation.
Product configuration is governed by rules. A stainless-steel wetted path may be required for a chemical application. A particular motor may be unavailable at a selected voltage. A larger impeller may require a larger housing. These rules belong primarily to the configuration model, but their outcomes provide inputs to pricing.
See the guide to product configuration, options and configuration rules for a deeper treatment of product models and constraints.
Price lists and price components
A price list may contain prices for finished products, options, spare parts, services or standard assemblies. The data can be organized by currency, market, customer class, sales channel, effective date or legal entity.
Price components may be additive, substitutive or conditional:
- An additive component adds a charge for an accessory.
- A substitutive component replaces the standard price when a premium material is selected.
- A conditional component applies only when a feature, market, quantity or delivery condition is present.
For example, a standard carbon-steel enclosure might have a base price, while stainless steel replaces the material cost and adds fabrication labor. A washdown finish may add a separate coating charge. The engine must avoid charging twice when one option replaces another.
Cost data
Cost-based pricing requires reliable cost data. Common sources include ERP item costs, supplier prices, standard costs, manufacturing routings, labor rates, machine rates, subcontractor estimates and engineering-service rates.
Cost can be stored at different levels of accuracy. A standard cost may be adequate for an early budgetary quote. A detailed estimate may be necessary for an engineered-to-order (ETO) machine involving custom design, purchased components and fabrication. The system should identify whether a result is an estimate, a standard cost or an approved project cost.
Customer and commercial data
Customer records may determine contract prices, discount groups, currencies, territories, payment terms, freight rules and tax treatment. A customer relationship management (CRM) system may provide the account and opportunity context, while the CPQ system applies the pricing logic.
Customer-specific pricing should be governed carefully. A broad discount stored against an account can unintentionally override a product-specific floor price or create a margin problem. Effective dates and versioning are important when contracts, supplier costs or exchange rates change.
Common pricing methods in manufacturing CPQ
| Method | How it works | Typical use | Main limitation |
|---|---|---|---|
| Price list | Retrieves a fixed price for a product, option or assembly. | Standard products and repeatable options. | Limited flexibility for engineered variation. |
| Option-based pricing | Adds or replaces prices based on selected features. | Configured equipment with known option premiums. | Can become difficult to maintain with many interactions. |
| Formula pricing | Uses dimensions, capacity, quantity or technical values in a formula. | Cut-to-size products, tanks, conveyors and fabricated assemblies. | Requires controlled formulas, units and validation. |
| Cost-plus pricing | Calculates cost and adds a markup or target margin. | Custom machinery and ETO work. | Depends on accurate and timely cost data. |
| Matrix pricing | Uses several factors such as product, region, quantity and customer class. | Dealer and industrial distribution channels. | Large matrices can be hard to govern. |
| Project or negotiated pricing | Starts with calculated values and permits controlled commercial adjustments. | Large capital equipment and strategic projects. | Requires approvals, auditability and version control. |
How rules and formulas affect price
Pricing rules express commercial consequences of configuration decisions. A rule might state that a high-temperature seal adds a defined charge, that a larger frame requires a larger motor, or that a custom paint system adds material and labor costs.
Rules can be simple or conditional. A simple rule adds a price for a selected option. A conditional rule may evaluate several values:
if material = stainless steel and pressure_class = high:The actual calculation might then select a different component cost, apply a fabrication multiplier and require engineering approval. In production systems, such logic should be represented in a maintainable rule model rather than hidden in ad hoc spreadsheets or code whenever possible.
Formula pricing is common when dimensions or performance influence cost. A fabricated duct, tank or conveyor may use length, width, gauge, material density and labor factors. A pump package may use motor power, enclosure class, controls and accessories. Unit consistency is essential: millimeters and inches, kilograms and pounds, or kilowatts and horsepower must not be mixed without explicit conversion.
Costing, margin and selling price
Manufacturing CPQ should distinguish at least three concepts:
- Cost: What the manufacturer expects to spend on materials, labor, overhead, purchased items or external services.
- Price: What the manufacturer charges before or after discounts and commercial adjustments.
- Margin: The difference between selling price and relevant cost, expressed as an amount or percentage.
A markup and a margin are not interchangeable. If cost is 1,000 and the business applies a 20 percent markup, the price is 1,200. If the business requires a 20 percent gross margin, the price is 1,250 because the cost represents 80 percent of the selling price. The pricing engine must use the organization’s defined convention consistently.
A practical pricing calculation may be:
- derive configured components;
- retrieve or estimate material and purchased-part costs;
- add labor, machine, engineering and subcontracting costs;
- apply overhead or cost factors where appropriate;
- apply target margin or markup;
- add logistics, installation or service charges;
- apply approved discounts and customer terms;
- check minimum price and margin thresholds.
Some businesses price from a published list and use cost only for margin analysis. Others use cost-plus rules for every engineered quotation. Both approaches can be valid if the ownership, timing and accuracy of the data are understood.
Relationship between pricing and BOM generation
A bill of materials (BOM) lists the components and quantities required for a product or assembly. A configurable BOM represents the component structure selected or derived for a particular configuration. Pricing may use this structure, but a quote BOM and a manufacturing BOM are not necessarily identical.
An engineering BOM (EBOM) describes the product from an engineering perspective. A manufacturing BOM (MBOM) organizes the product for production, including manufacturing assemblies, operations or plant-specific structures. A CPQ system may generate a sales BOM, an EBOM-like structure, an MBOM, or only a commercial summary. The implementation must define which output is required.
For example, selecting a conveyor length may add frame sections, guards, belts, supports and drive components. The pricing engine may price each component and labor operation, while the ERP later creates the production order. In another architecture, CPQ may send only a configured item and option codes to ERP, where the BOM is resolved using ERP rules.
Read more about configurable BOMs, EBOMs, MBOMs and quote generation.
Pricing in configure-to-order and engineer-to-order
Configure-to-order (CTO) products are assembled from predefined options and standard components. Pricing can often be calculated from maintained price components and a configurable BOM. Examples include standard pumps, switchgear packages and material-handling modules.
Engineer-to-order (ETO) products require new or substantially modified engineering for a specific order. Pricing may need engineering hours, design risk, prototype work, custom tooling, non-standard materials and project contingencies. A CPQ system may calculate an initial estimate and then send the opportunity for engineering review rather than presenting the result as a fixed production price.
Make-to-order (MTO) means production begins in response to an order, while assemble-to-order (ATO) uses stocked components assembled after the order. CTO, MTO and ATO can overlap operationally, but they describe different aspects of product and fulfillment behavior. The pricing design should reflect the actual workflow instead of assuming that every configurable product is CTO.
The relationship between commercial configuration and engineering handoff is described in the guide to manufacturing workflows such as CTO and ETO.
Approvals and pricing governance
Manufacturing quotes often require approvals when the result falls outside normal policy. Approval conditions may include:
- margin below a product-family threshold;
- discount above the salesperson’s authority;
- price below a minimum floor;
- non-standard payment or delivery terms;
- custom engineering or tooling;
- unusual material, supplier or warranty requirements;
- an ETO configuration with unresolved cost uncertainty.
Approval workflows should preserve the configuration, calculation inputs, price version, approver, decision and timestamp. If a salesperson changes a motor, dimension or discount after approval, the system should recalculate and determine whether approval is required again.
Integration architecture
Pricing engines rarely operate in isolation. Typical system responsibilities are:
| System | Possible responsibility |
|---|---|
| CRM | Account, opportunity, contact and sales-process context. |
| ERP | Items, inventory, standard costs, purchasing, orders, financial data and sometimes BOM resolution. |
| PLM | Product definitions, revisions, engineering change control and lifecycle status. |
| PDM | Engineering files, CAD documents, metadata and revision control. |
| CAD | Parametric models, drawings and design outputs where automation is supported. |
| PIM | Commercial product information, descriptions, attributes and channel content. |
| MES | Manufacturing execution, production status and shop-floor data. |
| CPQ | Configuration interaction, pricing logic, quote composition and commercial workflow. |
Integration can be synchronous, such as requesting a current cost during configuration, or asynchronous, such as publishing an approved quote and BOM to ERP. APIs, integration middleware and scheduled data synchronization may all be used. The important question is not whether a system has an integration label, but which system is authoritative for each data element and what happens when systems disagree.
See CPQ integration with ERP, CRM, PLM, PDM, CAD and other systems for architecture and ownership considerations.
Pricing and CAD or engineering automation
Some manufacturing CPQ implementations use engineering calculations or computer-aided design (CAD) automation. A user might enter tank dimensions, airflow, load capacity or vehicle wheelbase. The system can use those values to select components, calculate technical requirements and estimate price.
CAD automation may generate a product-specific model or drawing after configuration. That output can provide dimensions, material quantities or manufacturing information used by pricing, but the relationship is implementation-specific. A CPQ platform may support CAD integration, call an external engineering service or have no CAD capability at all.
Pricing should not depend on an unverified drawing result. Where engineering automation is used, the implementation should define calculation tolerances, failure handling, revision control and the point at which an engineer must review the output. More information is available in CAD and engineering automation for CPQ.
Benefits of a manufacturing pricing engine
- Faster quotation: Sales and application engineers can calculate repeatable configurations without rebuilding spreadsheets.
- Better price consistency: Rules reduce variation between salespeople, plants and dealers.
- Improved margin control: Cost and price can be evaluated before a quote is released.
- Traceable assumptions: The quote can retain the selected options, price version and approval history.
- Fewer configuration errors: Invalid options are blocked before they produce a misleading price.
- Stronger handoff: The same configuration can support the quote, BOM, engineering review and order entry.
- Better channel support: Dealers can receive controlled prices without maintaining private spreadsheets.
Limitations and common failure modes
A pricing engine cannot compensate for poor product data. Common problems include outdated costs, duplicate price rules, unclear ownership, missing option dependencies and formulas that are understandable only to their original author.
Pricing can also become unreliable when the system treats every product as a fixed catalog item even though dimensions, material grades or engineering effort vary significantly. Conversely, excessive customization can create an unmaintainable model with thousands of exceptions.
Other risks include:
- using standard cost as if it were a real-time project estimate;
- mixing markup and margin definitions;
- applying discounts before or after surcharges without documenting the sequence;
- failing to version price lists and rules;
- allowing manual overrides without reason codes or approval;
- sending a commercial BOM to ERP when ERP requires a different manufacturing structure;
- not recalculating after a configuration change;
- ignoring currency, tax, freight and delivery-date effects;
- embedding critical pricing logic in spreadsheets outside governance.
Implementation considerations
Define calculation ownership
Document whether CPQ, ERP, PLM, a costing application or an external service owns each value. For example, PLM may own the released option structure, ERP may own standard cost, and CPQ may own customer discount rules.
Model the product before the price
Start with valid product configurations and their dependencies. Pricing rules built on an unstable product model will need constant correction. Separate technical validity rules from commercial rules so that engineers can maintain constraints without changing sales policy unnecessarily.
Establish a pricing hierarchy
Define the order in which base prices, option adjustments, formulas, surcharges, discounts, taxes and freight are applied. Record whether a rule replaces, adds to or discounts another value.
Test representative scenarios
Test standard, maximum, minimum, boundary and invalid configurations. Include different currencies, quantities, customer classes, plants, effective dates, discounts and approval conditions. Compare calculated results with independently reviewed examples.
Govern changes and releases
Assign owners for product rules, price lists, cost data, formulas and approval policies. Use version control, effective dates, test environments and release procedures. A price change should be traceable to its source and should not silently alter previously issued quotes unless that behavior is intentional.
The broader CPQ implementation guide covers data migration, testing, governance, deployment and maintenance.
How to evaluate a manufacturing CPQ pricing engine
When comparing CPQ software, ask vendors and implementation teams:
- Can the engine price option-based, formula-based and cost-plus products?
- Can it use dimensions, quantities, engineering calculations and derived components?
- How are price rules versioned, tested and assigned to owners?
- Can it distinguish standard, estimated and project-specific costs?
- How are currencies, taxes, freight, installation and payment terms handled?
- Can it calculate margin and enforce price floors?
- Can discounts and overrides require approvals?
- Does it generate a configurable BOM, and what type of BOM?
- Which system is authoritative for item and cost data?
- How are ERP, CRM, PLM, PDM, CAD and external costing services integrated?
- Can a revised configuration trigger a complete recalculation?
- Are formulas, rules and price components visible to administrators?
- Can the system support CTO, MTO, ATO and ETO scenarios?
- How are failed calculations, missing costs and engineering exceptions presented?
Do not evaluate pricing by feature count alone. A platform with a simple price-list engine may be suitable for standard configurable products, while an ETO manufacturer may require governed formulas, cost rollups, engineering review and integration with ERP or PLM.
Semantic map
The following relationships summarize how pricing connects configuration, engineering, BOMs, enterprise systems and quoting in manufacturing CPQ.
- CPQ configures complex manufactured products.
- Configuration rules prevent invalid combinations.
- Valid configurations provide inputs to pricing.
- Pricing engines calculate commercial values.
- Cost data supports margin analysis.
- Configured products generate configurable BOMs.
- Engineering calculations influence component selection and price.
- CAD automation can generate product-specific drawings.
- ERP provides or receives item, cost and order data.
- PLM governs product definitions and revisions.
- Approvals control discounts and margin exceptions.
- Quote documents communicate configured products and prices.
Frequently asked questions
1. What is a pricing engine in manufacturing CPQ?
It is the calculation component that determines the cost or selling price of a valid configured product using options, quantities, formulas, costs, discounts, margins and commercial terms.
2. Is a CPQ pricing engine the same as a product configuration engine?
No. The configuration engine validates the technical product combination. The pricing engine calculates its cost and price. They exchange data but have different responsibilities.
3. Can a pricing engine calculate the price of an engineered machine?
Yes, if it has the required product rules, cost data, engineering formulas and approval workflow. For complex ETO work, the result may be an estimate that requires engineering review rather than a final production price.
4. How does a CPQ system price configurable options?
It can add an option charge, replace a standard component price, use a formula, or retrieve a price based on product, customer, quantity, region or effective date.
5. What is the difference between cost and price in CPQ?
Cost represents expected expenditure to manufacture or deliver the product. Price is the amount charged to the customer. The pricing engine may use cost to calculate a target margin or markup.
6. Can manufacturing CPQ calculate margin?
Many systems can calculate margin when cost and price are available, but the exact capability and cost detail vary. The implementation must define which costs are included.
7. Does pricing depend on the BOM?
It can. A CPQ system may price the components and quantities in a configurable BOM, or it may use a high-level price model while ERP resolves the manufacturing BOM later.
8. What is the difference between an EBOM and an MBOM for pricing?
An engineering BOM describes the product from an engineering perspective. A manufacturing BOM organizes it for production. Pricing may use either, a sales BOM, or a separate commercial structure depending on the architecture.
9. How does ERP interact with a CPQ pricing engine?
ERP may provide item data, standard costs, currencies or customer terms. CPQ may send the configured product, price, BOM or order information back to ERP. The exact ownership must be defined.
10. Can a CPQ pricing engine use real-time supplier costs?
It can if the architecture integrates a current supplier or ERP source. Without such an integration, the engine may rely on maintained standard, average or manually updated costs.
11. How are discounts controlled in manufacturing CPQ?
Discount rules can be based on customer, channel, quantity, product family or contract. Approval thresholds can require review when discounts reduce price or margin below policy.
12. What happens when a salesperson changes a configured option?
A well-designed system revalidates the configuration and recalculates dependent components, costs, prices, margins and approvals. Previously approved results may need approval again.
13. Can pricing engines support multiple currencies?
Many can, but currency conversion, rounding, price-list ownership, tax treatment and exchange-rate timing must be explicitly configured and tested.
14. How does formula pricing work for manufactured products?
Formula pricing uses values such as length, area, weight, capacity, power or quantity to calculate a component, labor amount or surcharge. Units and boundary conditions must be controlled.
15. Does every manufacturing CPQ platform include costing?
No. Some platforms provide price-list and discount logic but rely on ERP, estimating software or custom services for detailed costing. Buyers should verify documented capabilities.
16. Can CPQ price ETO products?
It can support initial estimates, engineering charges and controlled exceptions, but ETO pricing often requires human review because design effort, supplier costs and production requirements may be uncertain.
17. How does CAD automation affect pricing?
CAD or engineering automation can calculate dimensions, materials or derived components that influence price. However, not every CPQ platform supports CAD automation, and generated outputs may require engineering validation.
18. How should pricing rules be maintained?
Assign owners, use versioning and effective dates, separate technical rules from commercial rules, test representative configurations and document the calculation sequence.
19. What should manufacturers test before deploying a pricing engine?
Test standard and boundary configurations, invalid combinations, quantity breaks, discounts, currencies, taxes, freight, revisions, cost changes, approval thresholds and integrations with downstream systems.
20. What is the main risk of spreadsheet-based manufacturing pricing?
Spreadsheets can contain hidden formulas, inconsistent versions, manual overrides and outdated costs. They may be useful during analysis, but governed CPQ logic provides stronger repeatability and traceability for recurring configurations.