SAP CPQ vs Salesforce CPQ: How to Choose When You Already Run SAP

Nearly every evaluation call I join starts from the same place. There is an SAP back end holding the product master and the pricing conditions, a sales team working somewhere else, and someone who has been asked to produce a recommendation by the end of the quarter. The shortlist has two names on it, and the expectation is that I hand over a feature table.

I would rather hand over something else, because the market moved this year and most of the published material has not moved with it. Search for SAP CPQ vs Salesforce CPQ today and you get scoring grids and pricing that contradicts itself from one page to the next. Here is what changed, where the two products genuinely differ once you open them, and how I would frame the decision when the landscape already runs on SAP.

The SAP CPQ vs Salesforce CPQ comparison stopped being symmetrical

Salesforce CPQ is in an end of sale phase. That is Salesforce’s own wording, published on their own product page and repeated inside the product documentation. New customers can no longer purchase Salesforce CPQ licences. Investment has moved to Revenue Cloud Advanced, which sits inside the Agentforce Revenue Management suite and which Salesforce describes as the successor. If you have seen the name Revenue Lifecycle Management, that was an earlier name for the same product.

Two details matter more than the headline, and they point in opposite directions. End of sale is not end of life: there is no announced end of life date, the product is not on the active retirement list, and existing customers can renew, add users and keep receiving support under their current contract. At the same time, Salesforce describes the product as being in a maintenance phase with no new feature development.

What this changes if you already run it

Nothing forces your hand today, and I would be cautious about anyone who says otherwise, or who treats the move to Revenue Cloud Advanced as a version upgrade. Teams doing those migrations describe a different data model rather than a refresh, and one limitation comes up repeatedly: the Product Type field cannot be set on existing Product2 records, which can push a project into duplicating the entire product table. Salesforce itself puts a typical migration at three to six months from discovery through go live.

The change you will feel first is smaller and more irritating. Since July 2026 the Salesforce CPQ help documentation is no longer published as HTML pages. It still exists, as a single downloadable PDF, and old deep links redirect to one parent page, so years of admin bookmarks stop working. That belongs in your estimate of internal support cost, because it resembles what usually happens when a quoting platform enters its long tail: the product keeps running and the ecosystem around it thins out.

I checked the first page of search results before writing this. Out of ten, exactly one mentioned end of sale, and it was a forum comment rather than a published article. One review site, refreshed in late August 2026, still offers a demo and lists a free trial. Build an internal recommendation from that material and the recommendation inherits the errors.

Where each product puts the work

Underneath the marketing the difference is architectural, and it decides who maintains what for the next five years.

Salesforce CPQ is a managed package installed into a Salesforce org, working in the SBQQ namespace against custom quote and quote line objects. Logic lives in four kinds of product rules, documented as validation, selection, filter and alert rules, plus price rules that inject a static value, a field value or a summary variable into a quote field and can target either the configurator or the calculator. When declarative rules run out, the extension point is the Quote Calculator Plugin, a JavaScript hook with seven methods including onBeforePriceRules and onAfterCalculate. Approvals beyond the basics need Advanced Approvals, a separate package with its own permission set licences.

SAP CPQ splits the same work differently. Product logic sits under the Rules and Messages tab, and the execution order is fixed and worth memorising: attribute triggers first, then simple rules, then formula rules. Beyond that, scripting is IronPython bound to thirty three documented events, with OnProductRuleExecutionStart and OnProductRuleExecutionEnd wrapping rule evaluation and OnLandingFromCrm firing when a user arrives from a CRM.

Scripting also has hard limits that belong in any architecture discussion. A script running longer than twenty minutes is cancelled automatically, a single script is capped at forty thousand characters, and an outbound call to an external system times out at one hundred seconds. Those three numbers quietly rule out a whole category of design where somebody hoped to do heavy real time work inside a quote.

The configuration engine question nobody asks

Here is the question I wish more evaluation teams asked: which system actually runs the configuration?

For configurable products SAP CPQ does not execute variant configuration itself. It calls SAP Variant Configuration and Pricing, which supplies the knowledge bases, the configuration result and the pricing result. That service can forward configuration requests to SAP S/4HANA for advanced variant configuration, so there are no differences in processing between engines and the latest AVC syntax is available. SAP is candid that forwarding adds a small delay from the extra latency, and that AVC configurations are not persisted in S/4HANA until sales documents are created there. If you are weighing where classic variant configuration ends and the advanced engine begins, that forwarding decision is one of the first architectural forks on the project.

SAP is equally clear about the alternative. Variant configuration models can be recreated inside SAP CPQ, but at a high cost in time and resources, and avoiding that cost is the stated reason the integration exists. Any evaluation that puts a quoting tool in front of an existing KMAT model without answering this question is deferring the most expensive decision on the project.

Where the price is calculated

The same split applies to pricing. For variant configuration products SAP CPQ supports Variant Pricing, where prices come back from SAP Variant Configuration and Pricing, and Pricebook Lookup, where prices for simple products travel from SAP ERP to SAP Cloud Integration over IDocs, and SAP Cloud Integration then calls the SAP CPQ SOAP API to load them into pricebooks. That is why pricebooks have to be created manually in SAP CPQ, a detail that surprises people in week three. Pricing procedures are pulled from the back end under Setup, Pricing and Calculations, Pricing Procedures, with a Resync action for when the procedure changes in S/4HANA.

The Salesforce route to the same outcome is an integration pattern rather than a product feature. The documented approach for pulling live SAP pricing into a quote is the MuleSoft accelerator for SAP, whose quote to cash use case explicitly covers Salesforce CPQ with S/4HANA, retrieves net prices from the pricing conditions configured in S/4HANA including pricing scale and contract pricing, and validates additional discounts against thresholds held there. The stated principle is worth quoting on its own: S/4HANA is the system of record for pricing conditions. It is a clear statement about where the truth lives, and about how many moving parts you are agreeing to own.

The integration question, answered with names instead of adjectives

Anyone can say native. What I want from a comparison is version numbers, and SAP publishes them. The system requirements for SAP integrations set the minimums out plainly: SAP ERP 6.0 EHP 0 or higher for simple products, SAP S/4HANA 1809 or higher on premise, SAP ERP 6.0 EHP 5 or higher on a Unicode system when variant configuration is in scope, and SAP Sales Cloud 1905 or higher with SAML 2.0 single sign on as a hard requirement. Several of those paths also need the ERP C4 integration add on, CODERINT, on the back end.

Two entries deserve more attention than they get. SAP ERP Central Component is listed as a project based implementation, not available out of the box, so an ECC landscape does not get the shortcut an S/4HANA landscape does. And out of the box, SAP CPQ and SAP Sales Cloud do not share the same product master. That second one punctures the assumption that everything inside one vendor’s portfolio is automatically joined up, and an evaluation built on that assumption produces a plan short by a data workstream. Deciding how the quoting layer connects to the systems that already hold your data is the part of this that survives longest after go live.

Note what SAP supports on the other side, too. Salesforce appears in SAP’s own integration matrix as supported in both quote engines, delivered as a partner based solution for SAP paper clients, with an opportunity first and a quote first user journey. The two products are not mutually exclusive, so the SAP CPQ vs Salesforce CPQ framing can be a false binary depending on which system you keep as the front end.

The bundle that has no material number

The best illustration of what breaks sits in an SAP Community thread that has been open since 2023 without a real answer. The question, in the author’s words, is that CPQ allows defining ad hoc bundles of products so a better price can be offered, but when the order is transacted, SAP expects the header of the bundled product to be a predefined material number. The only reply was another question, asking whether it would be a LUMF bundle or a variant configuration.

That thread is the whole integration problem in one paragraph. Quoting tools compose freely, ERP order entry runs on identifiers that exist beforehand, and whichever CPQ you pick, somebody has to decide where that translation happens. Treating it as a mapping exercise is how projects lose a month, and the pattern repeats in less obvious places, which is why the integration layer tends to decide how far a rollout scales more than the quoting tool does.

The failure I flagged earlier is real and specific. When SAP CPQ is embedded inside a Salesforce CRM and the handover has not been scripted, the user sees a message saying there was an issue with landing to SAP CPQ, and the log reads that no script handler is defined for the OnLandingFromCrm event. The fix has three conditions, not one: the script must be active, return a correctly constructed redirect link, and run to completion.

How to decide when you already run both

The scenario nobody writes for is the most common one I meet. SAP holds the ERP, Salesforce holds the CRM, the sales organisation is attached to its interface and finance is attached to its conditions. Four questions will get you further than any feature table.

Which system owns the pricing truth? If the answer is the ERP, any architecture that recreates pricing logic elsewhere is signing up for dual maintenance, and you should price that in years rather than project weeks.

Do you have configurable products with existing knowledge bases? If yes, the conversation is really about whether you call those models or rebuild them. I have never seen the rebuild come in cheap.

How many CRMs will touch the quoting layer? SAP’s own answer to whether one SAP CPQ tenant can serve both SAP Sales Cloud and Salesforce Sales Cloud at once was that it is theoretically possible but not recommended. Theoretically possible is not an architecture.

What is the actual trigger for changing anything? A partner working on these migrations put it well: replacing a quoting platform simply because it is no longer sold is not, by itself, a business case. If your contract runs into 2028 and the system meets the need, you have time to do this properly. If it does not meet the need, that is the reason, and it would have been the reason regardless.

When those answers point toward consolidating on SAP, the work becomes concrete: rebuilding product structures, pricing logic and approval rules so they run inside the SAP landscape rather than beside it. When they do not, the honest recommendation is to leave things alone and revisit in a year. Either way, a structured review of what your current setup already does well usually changes the shape of the argument, because teams underestimate how much of their pain is configuration rather than platform.

Three things to take into the room

The comparison is no longer between two products you can buy, whatever the publication date on the page says. For a net new purchase the honest comparison is SAP CPQ against Revenue Cloud Advanced, which is a different conversation with a different risk profile.

The decision that costs the most is not the licence, it is where configuration and pricing logic live. Calling existing models is cheaper than rebuilding them in either product, and that is the number that compounds, which is also the argument for settling early how much pricing belongs in the quoting tool and how much stays in the ERP.

Neither path removes the integration work, it relocates it. Middleware, mappings and version prerequisites do not disappear because a vendor logo matches. If you want a second opinion from people who have opened both admin panels, we are glad to look at your landscape and tell you what we would do.