Is your product data ready for AI? Find out in this Whitepaper.
Download now ➔
Virtocommerce
Home Virto Commerce blog CPQ Software for B2B eCommerce: When You Need It, When You Don't, and What Your Platform Should Do Instead 

CPQ Software for B2B eCommerce: When You Need It, When You Don't, and What Your Platform Should Do Instead 

Marina Conquest Written by Marina Conquest
May 6,2026•5 min

There is a sequence B2B procurement teams have followed for the better part of two decades whenever sales operations asks for ‘configure price quote software’. A shortlist materializes—Salesforce CPQ, Oracle CPQ, SAP CPQ—and a six-figure evaluation begins. What the sequence rarely accommodates is the step that ought to precede it: a candid look at whether configuration, pricing and quoting need to live in a separate product at all. Until recently that step was easy enough to skip, since the answer was almost always yes. In 2026 the answer is less obvious, and the cost of not asking has risen accordingly.

What changed is partly the platform category and partly the buyer. B2B commerce platforms have absorbed configuration, quoting and approval workflows as native capabilities, with Forrester now scoring assisted purchasing and quoting as a core criterion in its B2B Commerce Wave alongside account rights and contract entitlements. Salesforce, the largest standalone CPQ vendor in the world, has begun shipping configurator and RFQ features inside its own B2B Commerce platform—a development the Spring '26 release notes describe in some detail. Either signal would warrant a fresh look at the architectural question on its own; taken together they make it difficult to keep deferring.

The pages that follow work through what CPQ software in B2B ecommerce actually does in 2026, when standalone CPQ earns its TCO, when commerce-native CPQ delivers comparable capability without the integration debt, and what to look for in either approach before a procurement process opens. CPQ for B2B ecommerce as a category has changed enough in the past three years that the question worth asking has changed with it.

Contents

TL;DR

  • CPQ describes a category of capability—configuration, pricing, quote generation—rather than a category of product.
  • Standalone CPQ continues to make sense for deeply nested manufacturing BOM, specialty pricing science, and Salesforce-ecosystem organizations.
  • Commerce-native CPQ delivers comparable capability for distribution, medium-complexity manufacturing, hybrid B2B/B2C and multi-region sellers.
  • Salesforce CPQ entry sits at $50K–$100K annually and enterprise crosses $200K—license is roughly a quarter of eventual TCO.
  • The architecture decision made in 2026 sets the AI ceiling reachable in 2028.

What Is CPQ Software, and What Most Teams Mistake It for

Configure, Price, Quote describes software that helps sellers and buyers configure complex products, calculate accurate prices for each configuration, and generate a formal quote document. The work is done by three components operating together—

  • a configuration engine that determines which combinations of options remain valid as choices accumulate, 
  • a pricing engine that resolves contract terms, customer tiers, regional adjustments and promotional rules in their correct sequence, and 
  • a quote-generation layer that produces the document and routes it through whatever approvals the deal size requires.

The category is regularly confused with adjacent ones, occasionally with expensive consequences. 

  • Quote Management Systems handle the workflow around a quote—versioning, approvals, expiration, conversion—without necessarily configuring or pricing anything themselves. 
  • Request for Quote describes the buyer-initiated mechanism that triggers a seller's quoting process; an entry point, in other words, rather than the engine itself. 
  • A product configurator handles configuration alone, with no pricing engine, no quote document and no approval routing. 

CPQ properly defined includes all three components, which is the reason the category has historically been treated as a single-product purchase—and the reason the question of where each component lives architecturally is worth examining before any vendor demo begins. 

👉 We've covered the disambiguation in greater depth in our B2B quote management guide.

The most consequential point in any honest evaluation of the category is also the one most readily passed over. CPQ describes a category of capability rather than a category of product. 

The configuration engine, the pricing engine and the quote-generation layer can be delivered as a single standalone product—Salesforce CPQ, Oracle CPQ (formerly BigMachines), SAP CPQ (formerly CallidusCloud), DealHub, Conga CPQ, PROS, Logik.io, Vendavo—or as packaged business capabilities running inside a B2B commerce platform. The second pattern, which we'll refer to as commerce-native CPQ throughout the article, is the one that has gained the most ground across 2024 and 2025.

Once that distinction is in view, the buying decision begins to look different from the inside. What is usually framed as a standalone CPQ vs commerce platform comparison—or, in procurement language, a CPQ vs B2B ecommerce platform decision—is, on closer examination, a question of architectural placement. The shortlist matters considerably less than the architectural choice underneath it.

Fig. Standalone CPQ vs commerce-native CPQ vs hybrid—capability and cost comparison.

Why the Standalone-CPQ Default Is Ending

The assumption that complex configuration requires a standalone CPQ product was reasonable in 2010, when commerce platforms could barely process a multi-step product configurator and most B2B catalogs ran on hand-maintained spreadsheets. The intervening decade and a half has done several things to that assumption, and the cumulative effect is more interesting than any single development.

1. The most visible change is in the platform category itself. Forrester's 2024 Wave for Commerce Solutions for B2B evaluates platforms against 24 criteria including assisted purchasing and quoting, account rights and customer contracts, and workflow and business process modeling. The analyst body that defines the category has begun treating quoting capability as core platform infrastructure rather than as a third-party integration to be bolted on later. Lead analyst Joe Cicman's framing on the report—that the B2B commerce solutions market is no longer a tale of two cities, with vendors having collectively closed the chasm between cloud architecture and robust feature sets—captures the direction of travel. Forrester's January 2026 Commerce Solutions Landscape report goes further still, unifying B2B and B2C commerce solutions in a single research view for the first time.

2. The second change is harder to dismiss as analyst commentary, since it comes from the dominant standalone CPQ vendor itself. Salesforce has begun shipping configurator and RFQ capabilities inside its B2B Commerce platform, packaging configuration and quote-request features as native commerce capabilities rather than as separate Salesforce CPQ entitlements. Shopware now ships customer-specific pricing, approvals and quote management as native B2B functions. OroCommerce also positions integrated CPQ and RFQ as core platform capability. When the dominant standalone CPQ vendor packages CPQ features into its own commerce platform, the market is delivering its own assessment of where the architecture is headed.

3. A third pull comes from buyers, whose expectations of a digital purchasing experience have grown faster than most CPQ tools have adapted. McKinsey's 2024 B2B Pulse Survey found that 39% of B2B buyers now place orders over $500,000 through self-service ecommerce or remote channels—up from 28% two years earlier—and 20% are now willing to place orders exceeding $1 million digitally. McKinsey's analysis of what these numbers require from suppliers points directly to the need for "new pricing processes to streamline quoting and approvals for large-value purchases." Gartner's parallel finding that 61% of B2B buyers now prefer a rep-free buying experience, together with McKinsey's observation that around two-thirds of sales-team time still goes to non-value-adding activities like manual quoting (with more than 30% of that work partially automatable) describes a buying environment that has stopped waiting for a sales rep to walk a configurator interface on the buyer's behalf.

4. The fourth and least immediately visible change concerns where AI can usefully be deployed. AI works cleanly on extensible, API-first foundations with structured pricing and configuration data. Standalone CPQ tools sit on proprietary data models—Apex scripts in Salesforce CPQ, BML in Oracle CPQ, QCP in SAP CPQ—that constrain which AI providers can do useful work against the underlying data. Composable commerce platforms allow any AI provider to operate against the same configuration and pricing model. The AI argument deserves its own section further down, though it is worth noting here as one of the structural reasons the architectural choice in 2026 has long-tail consequences.

None of this implies that standalone CPQ is finished. It continues to be the right answer for specific use cases the next section covers honestly. What has gone is the default—the assumption that the right answer is necessarily a separate product, made before anyone has examined whether the commerce platform already does the job. What looks like a CPQ shortlist in 2026 is often an architectural decision in disguise.

The Hidden Costs of Standalone CPQ for B2B eCommerce

License cost is what shows up in the procurement spreadsheet, and it is rarely the largest number. 

Salesforce CPQ entry-level deployments run $50,000 to $100,000 annually before any customization, and enterprise deployments cross $200,000—Salesforce's own Revenue Lifecycle Management pricing page gives the sticker. Oracle CPQ and SAP CPQ sit in similar bands. 

Across most deployments the license accounts for roughly a quarter of the eventual total cost of ownership; the other three quarters live below the surface, in places most buyer conversations never reach.

The cost of CPQ integration with ecommerce—the largest of the hidden costs—comes down to a four-way reconciliation. When a CPQ tool sits alongside a commerce platform, an ERP and a CRM, pricing rules need to remain synchronized across four separate systems. Every contract change, every promotional period, every regional adjustment becomes a four-way reconciliation, and real-time sync rarely is real-time—most deployments end up with batch jobs that fall behind during high-volume periods, which is precisely when pricing accuracy matters most. hen CPQ workflows integrate with Microsoft Dynamics 365 Commerce or other Microsoft-based ERP systems, configuration logic, pricing, and order capture stay synchronized within a single ecosystem.

Beneath integration debt sits the deeper architectural problem of dual logic. When the commerce platform has a pricing engine and the CPQ tool has its own pricing engine, the source of truth becomes ambiguous, and whichever engine loses the architectural argument needs custom code to defer to the winner. That code lives at the integration layer, where every release breaks something. The compounding effect is on velocity. Every pricing rule has to be coordinated across two systems with different update cycles and two different teams; change velocity drops because every change becomes a coordination problem rather than a configuration one.

Customization debt compounds the velocity problem. Apex, BML, QCP—every CPQ rule that doesn't quite fit the native configuration model becomes a custom script, written by specialized developers, prone to breaking during vendor upgrades and requiring re-implementation each major release cycle. Three years into a deployment, the standalone CPQ layer accumulates the same customization debt that drove the original commerce replatforming, only now the debt is spread across two systems instead of one. 

The talent cost that follows is harder to quantify but easier to feel: BML developers and Apex CPQ developers are expensive to hire, expensive to retain and represent a single-vendor skill set. When they leave, the institutional knowledge of how the pricing rules actually work walks out with them. This last cost rarely appears in any vendor RFP.

The pattern shows up most clearly at scale. A multi-billion-dollar industrial manufacturer running Salesforce CPQ across its commercial sales organization spent roughly $1.2M over 18 months on the deployment—license, integration and customization combined. Three years in, the team is now evaluating whether to migrate the configuration and pricing logic into its commerce platform, where the same workflows can run without the integration layer that has been the source of every release-cycle delay. The story is unremarkable in the sense that variations of it appear across most large enterprise CPQ deployments. The pricing engine question—where pricing rules live, who owns them and how quickly they can change—is the question that determines whether the standalone CPQ ever pays back the investment that went into deploying it.

Consider what is already running on commerce platforms today, without standalone CPQ in the picture. Lavazza by Bluespresso, the Italian coffee group's Dutch B2B operation, manages thousands of customer-specific price lists across roughly 2,500 corporate clients with around 4,000 SKUs. The pricing complexity is exactly the sort that standalone CPQ buyers typically pay six figures to replicate, and it is handled by the pricing engine that comes with the commerce platform itself. Individual price-list maintenance was eliminated post-migration through automated pricing logic. The point is not that pricing complexity is easy. It is that the cost premium standalone CPQ charges for handling complexity is not always buying capability the commerce platform doesn't already deliver.

👉 Read the full case study here: Lavazza by Bluespresso case study

When Standalone CPQ Is Still the Right Answer

A contrarian argument earns its credibility by conceding ground where ground is genuinely owed. The list below answers the practical question of when to use CPQ software in its standalone form—the honest version of when it earns its TCO and shouldn't be replaced.

The strongest case is deeply nested manufacturing bills of materials. Heavy machinery, defense aerospace, large-scale industrial equipment with thousands of interdependent parts where selecting one component invalidates twelve others and requires three more—Oracle CPQ processes constraint rules at depths that most commerce platforms genuinely cannot match. A global industrial-equipment manufacturer running deeply nested bills of materials across switchgear, automation and power distribution lines operates configuration rules in which one component selection cascades through dozens of dependencies. That is standalone-CPQ territory by architecture rather than by accident, and where the BOM depth is real, the specialized engine earns its license.

The second case is highly regulated pricing science. Insurance underwriting, telecom subscription pricing with billing-cycle complexity, financial services product structuring—specialty pricing engines from PROS or Vendavo do work that commerce platforms do not try to do, because the math involved is genuinely different from the math involved in B2B distribution. The same pattern shows up in life sciences, where regulatory constraints layer on top of the pricing complexity. A leading life-sciences manufacturer dealing with regulated product configurations across multiple jurisdictions needs configuration logic that satisfies regulatory audit alongside pricing logic that handles tier structures and contract eligibility. When the pricing science requires a domain-specific engine and the configuration must satisfy regulatory review, standalone CPQ remains the right answer; industries with that combination should not try to commerce-native their way out of standalone CPQ.

The third case concerns Salesforce-ecosystem lock-in. When 80% or more of revenue operations live inside Salesforce—Sales Cloud, Service Cloud, Marketing Cloud, Data Cloud—the cost of leaving the Salesforce data model exceeds the cost of Salesforce CPQ regardless of how the architectural argument plays out in a vacuum. Native integration wins on practical economics here, even though commerce-native CPQ would tend to win the architectural debate in a greenfield evaluation.

A fourth case applies wherever one CPQ engine must power reps, dealers, ecommerce and a partner portal—and the commerce platform handles only one of those channels. A standalone CPQ that sits above all four channels can be the right architectural choice when the commerce platform's reach is limited; the capability boundary becomes the deciding factor. If the commerce platform doesn't reach the partner portal, the partner portal cannot share its CPQ logic with ecommerce through the platform.

The fifth case is the simplest one and gets less attention than it deserves. Existing standalone CPQ that already works. Replacement risk is rarely worth the architectural improvement, and migration cost is real and usually under-modeled in the architectural discussion. If Salesforce CPQ or Oracle CPQ is functional and the team is fluent in it, the case for migration is generally weaker than the case for staying.

Roughly a fifth of B2B sellers fall into one of these five categories. The other four-fifths are evaluating standalone CPQ by default rather than by fit. The principle that catches the difference is straightforward: a digital commerce ecosystem should never be more complex than the business model it serves. When the business model genuinely requires nested-BOM configuration or specialty pricing science, standalone CPQ matches that complexity legitimately. Where it does not, standalone CPQ adds complexity the business does not actually need—and the cost of carrying unneeded complexity tends to surface in TCO, change velocity and the customization debt the previous section covered.

Fig. When standalone CPQ wins vs when commerce-native is enough.

For organizations evaluating CPQ alternatives in 2026, the meaningful comparison is no longer between two standalone products. It is between standalone CPQ and the commerce-native option, which is what the next section examines.

When Commerce-Native CPQ Is Enough (the 80% Case)

The four-fifths case has a recognizable pattern. Configuration complexity is bounded—products with five to fifty variables rather than five thousand interdependent parts. Pricing logic follows clear contract structures. The workflow runs from quote to order rather than from configuration through engineering review and back. Within that pattern, commerce-native CPQ delivers what standalone CPQ delivers, without the integration layer where dual-logic problems live.

Distribution is where the pattern is clearest:

  • OMNIA Partners, the largest group purchasing organization in North America, runs OPUS—7M+ products across 120 categories, 630 suppliers and $35B in B2B spending managed annually—entirely on its commerce platform. Quote-driven multi-supplier procurement at scale, with a 48% reorder rate and Quick Connect technology serving more than 11,000 public agencies, runs without a separate CPQ system. 
  • A leading multi-billion-dollar industrial distributor handles consumable categories, packaging and facilities supplies through commerce-native quoting.
  • A national MRO distributor manages multi-warehouse quote configuration across regional inventory.
  • A specialty industrial distributor handles quote-driven distribution for engineering and electronics buyers. 

Distribution at this scale was supposed to be the case standalone CPQ owned, and for some time now it has not been.

Manufacturing splits in two. The deeply nested BOM cases belong in the previous section, while medium-complexity cases—products with five to fifty configuration variables, dealer- and end-user-driven configuration, regional pricing logic—belong here. 

  • Flokk runs configurable furniture ordering with auto-generated price lists across its B2B dealer network and its B2C end-users on a single commerce platform, with a product configurator that serves both audiences. 
  • A global HVAC manufacturer handles partner-driven configuration for distributor networks. An engineered-building-products manufacturer sells configuration-heavy products through its commerce platform without a separate CPQ layer. 
  • A multi-billion-dollar building materials manufacturer handles engineered-product configuration at enterprise scale. 
  • A global electronic-components manufacturer handles multi-region configuration where the configuration logic must localize per market.
  • A multi-billion-dollar specialty manufacturer runs multi-region pricing on a single unified pricing engine. 

Each of these companies has the configuration complexity that standalone CPQ vendors built their pitch around, and none of them runs a standalone CPQ.

Hybrid B2B and B2C is one of the patterns standalone CPQ handles least gracefully. A platform that must serve gated B2B configuration alongside public B2C asks standalone CPQ tools to do something they were not architected for, since they were built for sales-rep workflows rather than for buyers who toggle between contexts. 

  • InstallatieBalie, a Dutch technical wholesaler, runs four storefronts—two B2B, two B2C, two in-store—on one composable commerce platform, with Microsoft Dynamics 365 integration, two PIMs, an MVP delivered in eight weeks, and 80% year-on-year B2C revenue growth in 2025. 

The hybrid model is becoming more common across distribution and manufacturing as B2B sellers add direct-to-consumer channels, which is one of the structural reasons commerce-native CPQ continues to gain ground.

Multi-region commerce is the case where standalone CPQ's deployment model genuinely struggles. 

  • HEINEKEN runs digital commerce across more than 20 countries with 370,000+ users, regional pricing rules, configuration-by-region and 30% of operating-company revenue flowing through digital channels—built as a two-month MVP and now powering a tenfold increase in online transactions. 
  • Cadillac & KW Parts handles 4M products and 5,000+ B2B clients across 30 countries with multi-currency EUR/SEK auto-rate updates and a multi-storefront B2B+B2C model. 
  • Bosch Home Comfort Group runs a partner portal serving 150,000+ users across 50+ brand and country combinations with 115+ fulfilment providers, 22,000+ articles and a points-based rewards system layered on top of the configuration and ordering engine.

Standalone CPQ can be deployed regionally, though it usually means a separate deployment per region with separate pricing rules to reconcile. Commerce-native CPQ handles localization without forcing the architectural fragmentation.

Platforms with CPQ-grade native capabilities—Virto Commerce, BigCommerce B2B, OroCommerce, Shopware, commercetools—each deliver multi-step configuration, dynamic pricing, quote generation and approval routing as packaged business capabilities rather than as a separate product layered on top. The capability set has come to be treated as commerce-platform standard rather than as standalone-CPQ exclusive.

For the four-fifths of B2B sellers fitting these patterns, commerce-native CPQ delivers the capability standalone CPQ delivers, at a fraction of the TCO, and without the integration layer where dual-pricing-logic problems live. That is the architectural decision standalone-CPQ comparisons rarely surface honestly.

👉 Read all case studies mentioned above here:

AI CPQ Software 2026: What 2026 Actually Looks Like

AI in CPQ has moved from feature-list bullet to operational reality, and the more interesting question for buyers is which architecture lets AI do useful work rather than constraining it.

The 2026 baseline is set:

  • Salesforce's 2026 State of Sales report found that 89% of revenue organizations now use AI in some form, with AI-using teams 3.7 times more likely to hit quota. 
  • Forrester's 2026 B2B predictions forecast that 20% of B2B sellers will be forced to engage in agent-led quote negotiations during the year—buyer-side AI agents talking to seller-side AI agents through structured quote interfaces, with humans reviewing only the exceptions. 
  • Forrester also found that 94% of B2B buyers now use generative AI for self-guided research, the upstream signal that quote interfaces will increasingly be agent-mediated rather than rep-mediated. 
  • Gartner forecasts that 30% of B2B sales cycles will be managed through digital sales rooms by 2026, with CPQ workflows running inside those sales rooms.

The use cases inside CPQ are now well-defined:

  • Pricing recommendations from historical-deal data, pioneered by PROS and Pricefx and now standard across mid-market platforms. 
  • Configuration assistance through guided selling that suggests valid combinations and flags invalid ones at config time rather than at fulfillment. 
  • Margin protection through anomaly detection on discount patterns and automated approval routing for deals below threshold. 
  • Deal coaching surfaced to reps mid-quote with next-best-action recommendations. 

None of these is exotic anymore.

The architecture argument is where the standalone-versus-commerce-native question becomes consequential. 

  • AI deploys cleanly on extensible, API-first foundations with structured pricing and configuration data. 
  • Standalone CPQ tools sit on proprietary data models that limit which AI providers can plug in—Salesforce CPQ has Einstein, though Einstein operates inside the Salesforce data model and against Salesforce-shaped data. 
  • Composable commerce platforms allow any AI provider to work against the same configuration and pricing data, because the data lives in one structured model rather than in two reconciled ones. 

👉 The deeper coverage of this dynamic sits in our pieces on dynamic pricing in B2B and B2B pricing automation.

Virto Commerce's AI capabilities—xRecommend for product recommendations, Virto OZ for assistance, Smart PO for purchase order intelligence, MCP integration for plug-in AI agents—sit on the same composable architecture, which means the same AI providers can work across the configuration, pricing and quoting layer rather than each one needing a separate integration. The personalized pricing capability is the visible expression of that architecture choice.

📍 A note worth adding: AI doesn't fix a broken CPQ workflow. Companies stacking AI on top of dual-pricing-logic problems amplify the problem rather than solving it, since the AI now has two sources of truth to disagree with and inherits the worst of both data models. Architecture decision first, AI layer second; the order of those two decisions matters more than most 2026 vendor pitches admit.

The AI question and the architecture question are the same question at different time horizons. The architecture chosen for CPQ in 2026 sets the AI ceiling reachable in 2028, by which point Gartner forecasts that 90% of B2B buying will be AI-agent intermediated, pushing more than $15 trillion of B2B spend through AI-agent exchanges. Whichever architecture the business chooses now will be the one those agents are negotiating against.

What to Look For in CPQ Capability: Standalone or Commerce-Native

The criteria that follow apply whether the evaluation is standalone CPQ, commerce-native CPQ or a hybrid combination. The question is whether the capability (wherever it lives architecturally) handles the business correctly.

Configuration engine power

Constraint logic depth determines whether the engine can handle nested dependencies in which selecting one option invalidates another, requires a third and modifies the BOM. 

Visual configuration support matters for non-technical buyers—3D rendering, real-time visual feedback, image-based variants for products where the spec sheet does not communicate the actual product. 

Configuration validation should happen at configuration time rather than at fulfillment, which means the engine must catch invalid combinations before the quote leaves the system. 

Rule modifiability is the underrated criterion: whether a non-developer can add a new compatibility rule, or whether every rule change requires Apex, BML, Python or another specialist skillset. 

The configuration engines worth avoiding are the ones that demo well but require professional services for every real-world rule, and the vendor question worth asking is for concrete examples from their customer base of rules that customers added themselves, in production, without engineering support. 

👉 Reference layer: configurable products and product configurator.

Pricing engine capability

Customer-specific pricing at scale is table stakes—thousands of price lists without manual maintenance, derived from contract terms rather than rebuilt each quarter. 

Real-time pricing data should be queried from ERP at quote-generation time rather than read from yesterday's batch sync.

Pricing-rule layering must apply list price, contract price, tier discount, promotion, regional adjustment and currency conversion in the correct order, with that order configurable rather than hard-coded. 

Margin protection through automated approval routing closes the loop, since deals below threshold should route automatically rather than depending on rep judgment. 

The pricing engine criterion matters more than most vendor evaluations acknowledge: Bain's research on B2B pricing found that only 15% of B2B companies have effective pricing tools, which is to say that pricing-engine capability is the area where buyers are most likely to be undermatched relative to their actual business needs. 

The pricing engines worth avoiding are those that require Excel-based price-list maintenance or batch sync with ERP; either design pattern locks the business into a velocity ceiling regardless of how good the rest of the engine looks in a demo. 

👉 Reference layer: account-specific pricing and catalogs, tiered B2B pricing and the broader B2B ecommerce pricing strategy guide covering contract pricing in B2B.

Quote generation and workflow

Quote document customization should handle branding, layout, multi-language and multi-currency without requiring a separate template per variation. 

Multi-tier approval workflows need conditional routing by deal size, customer type or discount level, with audit trails that survive vendor upgrades. 

Quote-to-order conversion should preserve negotiated terms and the approval audit trail in a single click—a requirement that sounds trivial and is genuinely difficult to deliver.

E-signature integration should be available natively or through API to DocuSign, Adobe Sign or equivalent, with structured data flow back to ERP rather than a PDF attachment that loses everything that was agreed. 

The quote tools worth avoiding are those that generate PDFs and lose the structured data when the buyer signs, since the quote document is also the authoritative record of what was agreed, and ERP needs that data structured rather than attached. 

👉 Reference layer: quote approval and conversion to order, custom approval workflows and B2B rebate management for post-quote workflow.

Cost of change

The cost criteria that rarely make it into vendor RFPs are the ones that determine TCO over three years. 

  • Cost of adding a new pricing rule—config change versus development project, with concrete examples requested from the vendor's customer base. 
  • Cost of upgrade—whether customization survives vendor releases, or whether each release requires re-implementation. 
  • Cost of integration with new tools (e-signature, contract management, AI assistant)—whether the platform offers API-first integration or requires proprietary connectors. 
  • Cost of exit—whether pricing rules, configuration logic and quote history can be exported in usable form if the business decides to leave. 


The vendors worth avoiding are those who cannot give concrete change-cost examples, those who treat upgrades as paid migration projects and those who own the export formatю

Fig. Capability criteria checklist for CPQ evaluation

For organizations evaluating CPQ for the second time

For organizations replacing or extending an existing standalone CPQ, the architectural question takes a different form. 

  • The first deployment answered "do we need CPQ?" with yes. 
  • The second deployment is answering a different question: whether the underlying assumption that complex configuration requires standalone CPQ still holds for the business in 2026. 

For many sellers it no longer does, and the replacement decision is rarely between standalone CPQ products. It has increasingly become a decision between standalone CPQ and commerce-native CPQ.

Migration Paths: Three Realistic Scenarios

Migration is rarely as binary as the architectural argument suggests, and three scenarios cover most real-world cases.

1. The first applies when an organization is replacing legacy standalone CPQ—BigMachines deployments, early Salesforce CPQ instances, custom-built CPQ from the 2010s that has aged into a maintenance project. The search query that surfaces this scenario is usually some version of "Salesforce CPQ alternative," and the answer that has emerged in 2026 is that the alternative is rarely another standalone product. The phased move starts with turning on commerce-platform configuration logic for one product line, migrates pricing rules second by contract type, and deprecates the standalone layer over six to twelve months. The phasing matters because pricing rules migrate one contract type at a time rather than in a big-bang cutover, which would create the dual-logic problem the migration is trying to solve. This is the expanding-rather-than-replacing pattern: extending what the commerce platform already does, retiring what the standalone CPQ was doing, on a timeline that protects ongoing quote workflow.

2. The second scenario is greenfield—a new commerce build with no existing CPQ. The default has shifted, and noticing the shift is part of the architectural decision. Five years ago a greenfield B2B build would have shortlisted Salesforce CPQ, Oracle CPQ and SAP CPQ as a near-reflex; in 2026 the default is commerce-native unless one of the use cases from the previous section applies—deeply nested BOM, regulated pricing science, Salesforce-ecosystem lock-in, multi-channel CPQ where commerce reaches only one channel. Buyers who don't notice the change in default end up evaluating against a 2018 frame of reference.

3. The third scenario is hybrid retention. Keep standalone CPQ for the one product line that genuinely needs it—the heavy-machinery line, the regulated-pricing line—and use commerce-native for everything else. Synchronize via API, but keep pricing in one source of truth to avoid the dual-logic trap. Hybrid is the pragmatic answer for organizations whose product mix straddles the 80/20 line, which describes most large industrial sellers. The mistake to avoid is letting hybrid become a synonym for "two CPQs running in parallel without architectural intent." Hybrid works when each layer owns specific product lines clearly and fails when the boundary between the two is ambiguous.

A handful of signals indicate that the standalone-CPQ-plus-commerce model has reached its ceiling.

  • Sales reps building quotes outside both the commerce platform and the standalone CPQ—usually in spreadsheets—because neither system handles a particular customer's pricing arrangement quickly enough. 
  • Pricing rules in shadow Excel files maintained by individual reps. Integration backlog growing faster than it shrinks. 
  • Release-cycle delays attributed to CPQ-platform sync timing. 

These are platform lifecycle stress signals, the kind that show up before the migration question becomes urgent. 

The question worth asking when one or more appears is whether the underlying architecture can support the next three years of product growth, or whether the team is patching its way toward a forced migration on someone else's timeline.

👉 The deeper architectural decision framework lives in our When to Replatform Your B2B eCommerce guide.

The CPQ Decision Is Not About Buying CPQ | Conclusion on CPQ Software in B2B eCommerce

CPQ describes a category of capability rather than a category of product, and the first decision facing any buyer in 2026 is which approach fits the business—standalone, commerce-native or hybrid—rather than which CPQ tool fits the budget. Getting that sequence right reorders almost every subsequent question.

Three observations follow. 

  1. For the four-fifths of B2B sellers whose configuration sits in the medium-complexity band—distribution, mid-complexity manufacturing, hybrid B2B/B2C, multi-region—commerce-native CPQ delivers the capability standalone CPQ delivers, at a fraction of the TCO, without the integration debt that consumes the second half of every standalone deployment's roadmap. 
  2. For the fifth of sellers with deeply nested manufacturing BOM, regulated pricing science or Salesforce-ecosystem lock-in, standalone CPQ remains the right answer, and recognizing that openly is the difference between honest fit and procurement-driven failure. 
  3. AI in CPQ deploys cleanly only on extensible architecture, which means the architecture decision made in 2026 sets the AI ceiling reachable in 2028.


Whether the commerce platform should be the CPQ—and if not, why not—is the question that deserves a real answer before any procurement process opens. Working through that question for a specific business is what the next step looks like.

What that question looks like in practice is something Flokk, Bosch and Cadillac & KW Parts have already worked through—each running configuration, pricing and quote-to-order on Virto Commerce, without a standalone CPQ layer above it. Explore the whole library of Virto Commerce use cases → B2B Ecommerce Case Study: Success Stories by Virto Commerce 

Book Your Discovery Session with Our Digital Experts

Book Meeting
You might also like...