Mercura CPQ + IFS Cloud
Configure complex products, calculate the right price and create order-ready configurations while IFS Cloud remains the system of record for ERP and manufacturing.
IFS Cloud already provides powerful Configure-to-Order functionality, and IFS now offers its own dedicated IFS CPQ product. Mercura provides an alternative architecture: an independent, composable CPQ layer connected to IFS Cloud for manufacturers that want to use IFS for ERP, manufacturing, costing and order execution while delivering dedicated configuration experiences across sales, CRM, dealers, customers and digital channels.
Sales quotation
What is IFS CPQ?
There are three distinct layers worth understanding. Searching for IFS CPQ can refer to several related capabilities.
IFS Cloud has longstanding product configuration functionality for Configure-to-Order manufacturing. Configurable parts are organised into configuration families with characteristics and options. Rules guide users through valid combinations, and configurations can be used in sales quotations, customer orders, shop orders, Dynamic Order Processing and other manufacturing processes.
IFS now also offers a dedicated product called IFS CPQ. IFS positions it as an embedded CPQ experience for complex manufacturing sales, adding capabilities such as guided selling, dynamic pricing, multi-level and system-level configuration, pricing governance, dealer and reseller experiences and customer-facing web configuration.
You can also keep IFS Cloud as your ERP and manufacturing platform while using a separate CPQ system such as Mercura for product configuration, pricing, visualization and digital sales experiences. This architecture is particularly relevant when configuration must work across systems and channels outside IFS.
A confirmed IFS CPQ configuration can create the corresponding IFS source lines with the appropriate sales parts, quantities and IFS CTO Configuration IDs.
Existing configurator
Yes. This is important.
A credible CPQ evaluation should not begin with the assumption that IFS lacks product configuration. IFS Cloud's existing Sales Configurator and Configure-to-Order functionality can guide users through characteristics and options, apply configuration rules, calculate configuration-dependent pricing and connect the resulting configuration with downstream manufacturing processes.
IFS has since added the separate IFS CPQ offering for a broader CPQ sales experience.
Not the question
Can IFS configure products?
Not the whole question
Does IFS have CPQ?
The question that matters
Which configuration architecture is right for our products, users, sales channels and IFS environment?
Architecture choice
The right answer depends on the problem you are solving.
Use IFS for the manufacturing and operational knowledge that belongs in IFS. Use the CPQ architecture that best serves the people actually configuring and buying the product.
Three-way comparison
| Capability | IFS Cloud CTO / Sales Configurator | IFS CPQ | Mercura + IFS Cloud |
|---|---|---|---|
| IFS ERP and manufacturing | Native | Native integration | IFS remains responsible |
| Configurable parts | Yes | Uses IFS CTO integration | Can map to IFS configured parts |
| Characteristics and options | Yes | Yes | Yes |
| Configuration rules | Yes | Yes | Yes |
| Guided selling | Yes, configuration-oriented | Yes | Yes |
| Configuration pricing | Yes | Yes | Yes |
| Dynamic pricing governance | IFS pricing capabilities | Yes | Yes |
| Sales quotation integration | Native | Native integration | API integration |
| Customer order integration | Native | Native integration | API integration |
| IFS CTO Configuration ID | Native | Created through integration | Can be mapped where required |
| BOM / routing evaluation | Native IFS responsibility | Connected to IFS CTO | IFS can remain manufacturing master |
| Multi-level configuration | Manufacturing structures | Yes | Yes |
| System-level selling | Depends on model | Yes | Yes |
| Dealer / reseller experience | IFS B2B possibilities | Yes | Yes |
| Customer web configurator | Requires chosen IFS architecture | Yes | Yes |
| Custom frontend / SDK approach | Not the core purpose | IFS CPQ architecture | Core Mercura architecture |
| CRM-first workflow | Requires integration | Depends on landscape | Core integration pattern |
| Multi-ERP / ERP-independent CPQ | No | IFS-oriented | Yes |
| Interactive 2D / 3D | Depends on implementation | Supported; 3D assets remain customer responsibility | Core Mercura capability |
| Best fit | Manufacturing-centric CTO | IFS-centric end-to-end CPQ | Composable, multi-channel CPQ around IFS |
Embedded CPQ architecture
This distinction is useful for architecture teams.
IFS describes IFS CPQ commercially as embedded within IFS Cloud and natively integrated with IFS Cloud Manufacturing.
IFS's own technical documentation explains how this works underneath. The CPQ solution is provisioned as an external application and connected to IFS Cloud using:
A CPQ application does not have to run inside the ERP application itself to be deeply integrated with IFS Cloud.
Mercura follows the same broad separation-of-concerns principle: IFS continues to own ERP and manufacturing execution, while CPQ exchanges structured information with IFS through supported integration interfaces.
The difference is which CPQ platform you want to use.
What IFS Cloud should own
For an IFS manufacturer, the goal should not be to recreate IFS inside CPQ. IFS is exceptionally strong in manufacturing execution. Depending on your implementation, IFS may remain authoritative for:
Mercura should consume or reference the information that the sales configuration process actually needs.
What CPQ should own
The CPQ layer is primarily concerned with turning requirements into something that IFS can execute. Mercura can handle:
Turn customer requirements into technically meaningful choices.
Apply dependencies, constraints and calculations while the user configures.
Show users what they are building.
Generate commercial and technical documents from the structured configuration.
Configure-to-Order in IFS
IFS's CTO capabilities are deeper than a simple ERP item lookup.
A configurable part is connected to a configuration family. The family defines common characteristics and options used to describe valid variants. The IFS Sales Configurator can then guide a user through the choices.
Rules can:
Used in:
IFS also supports configuration revision control and reuse of identical existing configurations.
This means an IFS integration should reuse the existing CTO model where it is valuable, not blindly replace it.
ERP and manufacturing
Configure · Price · Quote
Commercial execution
Sales channels
Internal ERP users are only one possible audience. Complex products may also be sold by CRM users, field sales, distributors, dealers, resellers, partners, engineers, customers and ecommerce users. A dedicated CPQ layer lets the same governed product knowledge be exposed through different experiences.
Launch configuration from an opportunity or sales process. Sales receives guidance without having to understand the complete underlying manufacturing structure.
Give external sales channels controlled access to relevant products, valid configuration rules, customer-specific assortments, commercial logic and quote generation without exposing the complete ERP interface. IFS CPQ itself also offers dealer and reseller portal capabilities, so organizations should compare the required experience rather than assuming an external CPQ is automatically necessary.
Allow customers to configure products directly through your website or portal. IFS CPQ includes customer-facing web configurator capabilities. Mercura is relevant when you want that experience to be part of a wider headless or custom digital architecture rather than primarily an IFS-centric solution.
Many manufacturers use IFS for ERP and manufacturing but another platform for CRM. A typical architecture can therefore be CRM → Mercura CPQ → IFS Cloud. This avoids forcing salespeople into ERP simply because manufacturing runs there.
This is one of the strongest reasons to evaluate a specialist CPQ alongside IFS CPQ. Some organizations operate:
Should product configuration be an IFS capability exposed outward, or an independent product knowledge layer connected to IFS and the rest of the stack?
There is no universally correct answer. That is an architecture decision.
Visual CPQ
Complex industrial products are often difficult to sell using characteristics and ERP fields alone. Mercura can combine configuration logic with visual feedback.
IFS CPQ also supports visual configuration scenarios; IFS's product terms specifically note that any 3D models required for IFS CPQ are the customer's responsibility.
Use the same structured configuration to create branded proposal documents — then map the approved result to IFS Cloud.
When Mercura fits
Mercura is particularly relevant when the CPQ problem extends beyond ERP configuration.
The configurator should open from CRM or another sales workspace.
They need a branded experience rather than an ERP-oriented interface.
The product configurator is a digital sales product in its own right.
One CPQ model must serve several ERP, CRM or business units.
Customers need to see the result while they configure.
Sales logic changes on a different cadence from ERP master data.
Configuration must be consumed through APIs and custom applications.
The CPQ layer needs to orchestrate product knowledge across IFS, CRM, PIM, CAD and other systems.
When IFS CPQ fits
If IFS Cloud is clearly the centre of the sales and manufacturing architecture and you want the CPQ solution supplied within the IFS ecosystem, IFS CPQ deserves serious consideration.
Mercura should not be added simply for the sake of adding another application.
When Sales Configurator is enough
Not every IFS customer needs a dedicated CPQ product at all.
This is often the first architecture question worth answering.
Manufacturing handoff
This is where IFS is particularly strong. A sales configurator should not create a beautiful quotation that manufacturing cannot execute. The integration should determine how the approved commercial configuration becomes the correct IFS manufacturing input.
Mercura determines which existing sales part corresponds to the customer's requirements. The resulting part and quantity are transferred into the relevant IFS sales process.
Best when: You manufacture or stock a finite catalogue of valid variants.
Mercura captures the required choices and maps them to the corresponding IFS configuration characteristics and options. IFS then remains responsible for the formal CTO configuration and its downstream manufacturing evaluation.
Best when: Your existing IFS CTO setup already contains the manufacturing logic you want to preserve.
One high-level configuration can result in several sales parts and quantities. IFS can then use its manufacturing configuration rules, product structures, routings, DOP or other downstream processes to determine how the order should be fulfilled.
Best when: CPQ owns the sales solution while IFS owns the manufacturing definition.
IFS can evaluate configuration rules to create manufacturing structures. Configured products can feed product structures and routing logic, and IFS supports the creation of DOP structures based on configuration evaluation.
Best when: A customer's selections directly determine components and manufacturing operations.
Not every ETO product can or should be completely automated. Mercura can standardize everything that is repeatable and produce the parameters engineering needs. Engineering then finalizes the product before the approved BOM, project structure or manufacturing definition enters IFS.
Best when: Every order contains genuine engineering work but sales can still automate a substantial portion of the configuration.
The right architecture depends on your manufacturing process. We do not assume every manufacturer should generate BOMs in exactly the same way.
Interim orders
IFS provides an interesting bridge between configuration, costing and engineering. A configured product on a sales quotation or customer order can be exploded into an interim order.
For complex manufacturers, this creates a strong architecture:
This can be preferable to moving detailed manufacturing costing into the CPQ platform.
Pricing ownership
IFS already has substantial pricing functionality. Do not duplicate it unnecessarily.
For configurable sales parts, IFS can calculate price using the base price of the unconfigured sales part, the economic value of configuration characteristics and the economic value of options.
Mercura configures the product and requests or consumes the relevant price from IFS.
Best when
IFS already contains the commercial price logic, customer pricing belongs in ERP, sales-price governance is ERP-controlled and configuration does not require substantial additional CPQ pricing.
Example: IFS sales-part price + selected dimensions + material factor + performance package + accessories + project-specific additions = configured selling price.
Best when
ERP owns standard commercial data but the final sales price depends on calculations that exist only in the configuration context.
Mercura performs the complete configuration calculation and sends the resulting commercial value into the agreed IFS transaction process.
Best when
Pricing is inseparable from a highly specialized configuration model.
If you choose IFS CPQ itself, IFS markets dynamic pricing, scenario modelling, approval workflows and margin-protection controls as core capabilities. In that architecture there may be little reason to introduce another CPQ pricing layer.
Best when
You want one governed CPQ pricing layer supplied within the IFS ecosystem.
The most important pricing decision is not which system has the most powerful pricing engine.
Which system should own each pricing rule? Customer agreements, price lists and ERP commercial logic may belong in IFS. Configuration formulas may belong in CPQ. Manufacturing cost belongs close to IFS Costing and manufacturing. Approval logic should have one governed home.
A good IFS CPQ architecture minimizes duplicate rules.
IFS Cloud integration
REST and OData
IFS Cloud exposes business functionality through REST APIs based on OData. IFS describes REST APIs as its preferred integration method and exposes IFS Cloud Projections that can be reused for integration. Standard HTTP operations such as GET, POST, PUT, PATCH and DELETE are supported depending on the API.
For system-to-system integrations, IFS recommends the OAuth 2.0 client credentials flow. The external application obtains an access token using an IFS IAM client and uses that token when calling the relevant APIs.
External configuration
Yes.
IFS documentation explicitly states that a configuration can be initiated by an external application. IFS's own modern CPQ integration also demonstrates this architectural pattern.
For a Mercura implementation, we would first determine which IFS-supported business flow should own the resulting configuration rather than assuming that every customer requires the same mapping.
Data exchange
A typical design may include:
| Data | Direction | Purpose |
|---|---|---|
| Sales parts | IFS → Mercura | Reuse ERP product master |
| Part information | IFS → Mercura | Technical/product context |
| Customers | IFS → Mercura | Customer-specific quoting |
| Companies | IFS → Mercura | Organizational context |
| Sites | IFS → Mercura | Manufacturing/commercial context |
| Units | IFS → Mercura | Consistent quantities |
| Price information | IFS → Mercura | ERP pricing input |
| Inventory / availability | IFS → Mercura | Sales availability where relevant |
| Configuration characteristics | IFS → Mercura | Reuse existing CTO model |
| Configuration options | IFS → Mercura | Reuse allowed IFS values |
| Cost information | IFS → Mercura | Where commercially appropriate |
| Configuration | Mercura → IFS | Approved product definition |
| Sales parts | Mercura → IFS | Configured commercial lines |
| Quantities | Mercura → IFS | Order quantities |
| Configuration reference | Mercura → IFS | Traceability to CPQ |
| Sales quotation data | Mercura → IFS | Continue quotation flow |
| Customer order data | Mercura → IFS | Continue order process |
| Technical parameters | Mercura → IFS | Downstream manufacturing context |
| Component data | Mercura → IFS | Where agreed architecture requires it |
Landscape qualification
IFS implementations differ considerably. Before defining the integration, we review:
The result should be an integration design based on your actual IFS environment rather than a generic connector diagram.
Decision support
IFS CPQ is IFS's Configure, Price, Quote offering for manufacturers selling complex configurable products. IFS positions it as an embedded IFS Cloud experience with guided selling, configuration, dynamic pricing, approvals, multi-level and system-level configuration, dealer/reseller support and customer-facing web configuration.
Yes. IFS Cloud includes longstanding Configure-to-Order and Sales Configurator functionality based on configurable parts, configuration families, characteristics, options and configuration rules. IFS CPQ is a broader CPQ offering built around and integrated with these manufacturing capabilities.
The IFS Sales Configurator is part of the underlying IFS Configure-to-Order functionality and focuses on creating valid configurations of configurable parts. IFS CPQ is the broader sales-layer product. It adds a dedicated CPQ experience with capabilities such as guided selling, dynamic pricing governance, system-level configuration and external sales experiences while integrating the result with IFS business objects and CTO.
Commercially, IFS describes IFS CPQ as embedded and natively integrated with IFS Cloud. Technically, IFS documentation describes the CPQ solution as an external application integrated with IFS Cloud using REST calls, IFS Connect, SSO, webhooks and dedicated integration users. This gives users an embedded experience while maintaining a separate CPQ service architecture.
Yes. Mercura can be used as an independent CPQ layer alongside IFS Cloud instead of using IFS CPQ. The better architecture depends on your existing IFS CTO model, sales channels, CRM strategy, frontend requirements, system landscape and how closely you want CPQ coupled to the IFS ecosystem.
No. IFS should continue to own ERP, manufacturing and operational processes. Mercura handles the sales configuration experience and passes the approved result into the agreed IFS process.
Yes, an integration can be designed to preserve an existing IFS CTO architecture. For example, Mercura can determine or collect the configuration selections while IFS remains responsible for the formal configured part, configuration ID and downstream manufacturing evaluation. The exact model depends on the customer's CTO setup.
IFS documentation explicitly allows configurations to be initiated by external applications. The appropriate integration should use supported IFS APIs and preserve the business validations required by the customer's IFS process.
IFS Cloud exposes REST APIs using OData and Projections. IFS states that REST APIs are the preferred integration approach. An integration may use Premium APIs, Integration APIs, standard projections, IFS Connect or other supported interfaces depending on the business process.
IFS Cloud REST API documentation →IFS recommends OAuth 2.0 client credentials for system-to-system integrations. The final authentication setup depends on the interaction pattern and IFS environment.
IFS OAuth documentation →It can live in IFS, Mercura or in a controlled hybrid architecture. IFS already supports sophisticated configured pricing using base prices, characteristic and option pricing, formulas and combination tables. Do not recreate that logic in CPQ unless there is a clear reason.
IFS CTO can evaluate configurations to determine downstream manufacturing structures, including configuration-driven DOP structures and operations. Mercura can provide the sales configuration while IFS continues to evaluate and execute the manufacturing logic.
Yes. IFS supports interim orders for configured sales quotation and customer order lines. These can be exploded for inspection and estimated cost roll-up, and minor engineering changes can be made before recalculating the cost. This can be especially useful for complex or partially engineered products.
Yes. Both IFS CPQ and Mercura can support external sales experiences. IFS CPQ advertises dealer/reseller portal and customer-facing web configurator capabilities. Mercura is particularly relevant when those experiences must be embedded into a wider custom or multi-system architecture.
Yes. A common architecture is CRM → Mercura CPQ → IFS Cloud. CRM owns the opportunity, Mercura owns the sales configuration experience, and IFS owns operational execution.
This page focuses primarily on IFS Cloud. Older IFS Applications environments use different integration technologies and should be assessed individually before defining the architecture.
Official technical resources
Technical content last reviewed August 2026. Validate assumptions against your IFS Cloud release, enabled modules and integration landscape.
Explore the capability stack
IFS runs the operation. Use the CPQ architecture that best runs the sale.
If you already use IFS, the first question is not whether you need another piece of software. It is where configuration knowledge should live. For some organizations, the existing IFS Sales Configurator is enough. For others, the new IFS CPQ product is the most natural extension of IFS Cloud. And for manufacturers that need one composable configuration layer across CRM, ERP, dealers, customers and custom digital experiences, Mercura can provide the CPQ layer while IFS remains the manufacturing and operational backbone. Bring a configurable product, an example quotation and an overview of your current IFS CTO setup. We can map where product rules, pricing, costing and manufacturing logic should live — and whether Mercura, IFS CPQ or the existing IFS configurator is the best fit.