SAP CPQ is often positioned as a natural extension to S/4HANA. In some cases, the conversation is framed as SAP CPQ vs S/4HANA, with CPQ seen as the next step in building out a modern quote-to-cash architecture.
But for many organizations, particularly those with relatively simple sales processes, S/4HANA’s capabilities are sufficient. Introducing CPQ in these cases does not necessarily improve performance. It can add unnecessary complexity, increase integration overhead and create additional boundary challenges across systems.
So how do you know whether it makes sense for your organisation? The decision should not be based on availability, but on whether the existing quoting process has reached a level of complexity that ERP alone can no longer manage.
When S/4HANA is enough on its own
There are many scenarios where S/4HANA can support quoting without the need for CPQ.
This is typically the case in smaller organisations, or in business units where the commercial model remains relatively straightforward. Product catalogues are limited, pricing logic is simple, and the quoting process follows a predictable path from initial request to order creation. E.g if no revisions and iterations are required during billing.
In these environments, quoting is closely tied to execution. The system is designed to move efficiently from one stage to the next without requiring additional abstraction. There is little need for guided selling, structured negotiation, or complex configuration logic. As a result, the native capabilities within ERP are often sufficient.
Introducing CPQ at this stage does not simplify the process. It introduces a new layer that needs to be managed.
Where S/4HANA-based quoting starts to break down
The need for CPQ does not emerge suddenly. It becomes visible as complexity increases across different parts of the sales process. In most cases, that complexity shows up through a consistent set of signals:
- Product configuration becomes harder to manage
As catalogues expand and offerings become more configurable, selecting and validating the right combinations becomes increasingly complex. CPQ allows organizations to add more user friendly UI and separates sales and technical configuration for simpler sales processes.
- Pricing becomes distributed and difficult to control
Different discount types, contract-specific terms and variable pricing structures introduce multiple layers of logic. Pricing is no longer centrally defined, it needs to be fine tuned and adjusted for each deal, which is where CPQ is stronger.
- Quoting becomes more collaborative and iterative
Quotes involve multiple stakeholders, approval steps and revisions. ERP systems are not designed to support this level of interaction and work begins to move outside the system.
This shift is structural rather than incidental. Research indicates that B2B buying decisions now involve an average of 6–10 stakeholders, increasing the number of interactions, approvals, and iterations required to produce a final quote.
Where SAP CPQ and S/4HANA should and shouldn’t overlap
When SAP CPQ is introduced alongside S/4HANA, the challenge is defining where responsibility sits between the two systems.
Both platforms operate within the same quote-to-cash process, but they are designed to handle different stages of it.
CPQ as the decision layer, S/4HANA as the execution layer
CPQ structures the commercial proposal. It handles configuration, applies pricing logic, and supports negotiation during the deal stage.
S/4HANA executes the outcome. It takes the confirmed quote and manages order processing, fulfilment, and financial transactions. In theory, this division is clear. In practice, it is often blurred.
Pricing and configuration logic frequently overlap. ERP may define base pricing, while CPQ applies discounts or deal-specific adjustments. Configuration may be split between systems, with structural rules in ERP and commercial logic in CPQ.
These models can only work when ownership is clearly defined and consistently applied.
What happens when boundaries are unclear
When boundaries are not clear, CPQ becomes a reconciliation layer. Quotes depend on inputs from multiple systems, each with different logic and ownership. This introduces delays, increases inconsistencies, and makes the process harder to manage.
The same issue appears at the quote-to-order handoff. If CPQ outputs are not complete and trusted, S/4HANA begins to reinterpret or override them, leading to duplication and rework.
The objective is not to remove overlap entirely, but to define it properly. CPQ should own how the deal is constructed. S/4HANA should own how it is executed. When that separation is clear, the systems complement each other. When it is not, they compete.
The role of CPQ within an S/4HANA landscape
When implemented correctly, SAP CPQ complements ERP systems, rather than replacing them..
CPQ is responsible for structuring the commercial proposal, guiding configuration, applying pricing logic, and supporting negotiation. ERP remains responsible for execution, handling order processing, fulfilment, and financial transactions.
The boundary between these systems is critical. CPQ operates in the negotiation phase, while ERP takes over once a deal is confirmed. When that boundary is clearly defined, the process remains efficient. When it is not, complexity increases. And that complexity is passed on to customers.
With 77% of B2B buyers describing their last purchase as “complex” or “difficult”, reducing friction is a critical move for most organizations.
The risk of introducing CPQ too early
Introducing CPQ before it is needed can create more problems than it solves.
If the underlying sales process needn’t be overly complex, CPQ adds an additional layer without delivering proportional value. It introduces integration requirements, expands system ownership, and increases the effort required to manage changes.
In some cases, it can also lead to the need for additional skillsets for maintenance.
A practical checklist: do you actually need SAP CPQ?
In most cases, the decision to introduce CPQ can be assessed through a small number of signals.
If several of the following apply, it is likely that S/4HANA alone is no longer sufficient to support the quoting process:
- You need more integration with your CRM
You need integrations with SAP and non-SAP CRM applications, like SalesForce
- Product configuration is difficult to manage manually
Sales teams rely on experience or multiple external sources to ensure configurations are valid
- Pricing varies significantly between deals
Discounts, contract terms, or customer-specific conditions require frequent adjustments
- Customer negotiation iteration
CPQ allows you to create as many quote revisions as you need for optional and additional items, with customers able to view these in the system itself.
- Approval processes are slowing down deal progression
Pricing or configuration decisions require repeated validation and multiple approval processes with multiple stakeholders.
- Sales teams rely on spreadsheets or external tools
Quoting is partially handled outside the system to maintain speed or flexibility
- Distributors or partners need controlled access to quoting
External stakeholders require visibility or input into the quoting process, or may need to create quotes themselves
If these conditions are not present, CPQ may not be necessary.
If they are, it is usually a sign that complexity has already outgrown ERP-based quoting and that a dedicated CPQ layer is required to bring structure and control back into the process.
CPQ should be driven by complexity, not strategy alone
SAP CPQ is not a standard component of every S/4HANA implementation.
It becomes necessary when complexity reaches a point where ERP can no longer support the quoting process effectively. This may be driven by product structure, pricing models, sales processes, or organisational scale.
Introducing CPQ too early adds complexity without solving a problem. Introducing it at the right time creates structure, consistency, and control. The difference lies in understanding where that threshold sits.