Sep 3, 2026 | 6 minute read
Enterprise CPQ complaints usually trace back to a source-of-truth mismatch: CRM processes often originate from the quote, while commerce platforms originate from the cart. That mismatch, combined with pricing complexity, wide variance in quoting requirements across accounts, and region-specific business rules, means generic CPQ tooling structurally can't fit every business well. The fix is a data model flexible enough for each business to model their quoting as it actually works.
written by Bryan House
If you talk to enough enterprise commerce teams about quoting, you’ll find that nobody describes their configure-price-quote (CPQ) pain points as a software problem. They describe it as a series of workarounds — a manual process here, a custom sync job there, a rule nobody remembers the reason for. Ask five different B2B manufacturers and distributors what "our CPQ problem" means and you'll get five different answers.
That's not a coincidence, and often, it's not really a CPQ problem. It's a data model problem. Quote data and commerce data are frequently built on different assumptions about what the "source of truth" object is, and every one of those workarounds is glue code compensating for the gap. Once you see it that way, the individual complaints — slow APIs, quotes that won't version, discounts that show up in the wrong place — stop looking like unrelated bugs and start looking like symptoms of the same underlying issue.
Here's what that looks like across a handful of real company patterns, and what it suggests about the commerce platform architecture needed to close the gap.
One software company ran quoting through Salesforce CPQ, layered with value-added resellers and manual steps for anything outside standard pricing. Their pricing wasn't simple seat-based SaaS pricing; the price recalculated as customers scaled the number of managed devices or retail locations under contract, rather than staying fixed to a flat per-seat rate. On top of that, pricing shifted with customer tenure and routed through resellers for certain deals.
Worth noting: even the incumbent most enterprises standardized on for this is now in flux. Salesforce announced Salesforce CPQ was entering "end of sale" in March 2025 — no new licenses for customers and no new feature development . That timing makes the underlying architecture question harder to defer.
That's exactly the kind of complexity that breaks CPQ tools built around linear pricing models. Direct API calls into the CPQ system were reported as slow, erroring, and timing out under this load. The fallback was a person manually entering data into Salesforce to produce a quote — a process that stretched turnaround to weeks, sometimes a month, for what should have been a same-day transaction.
This type of failure is a performance and pricing-logic ceiling, not a data model problem on its own. It matters here mainly as scene-setting — it's the kind of pain that pushes teams to start asking harder questions about their quoting architecture, which is where the more structural issues appear.
One enterprise equipment manufacturer expressed that their Salesforce-based process treats every opportunity as originating from a quote. Quotes are versionable and amendable; that's the object everything else revolves around.
Most commerce platforms, including cart-based systems, don't work that way. The cart is the point of origination, not the quote. So instead of one quote getting versioned as terms change, new carts proliferate into separate quotes. The manufacturer’s preference is to pull up any approved quote, internal or external, and convert it directly into a cart to check out through either their public storefront or their procurement/punch-out flow. However, this process wasn't something their CPQ architecture supported. Each quote required custom work on both sides just to keep the commerce and CPQ systems roughly in sync, adding real overhead to every upgrade cycle.
This is the actual architectural mismatch underneath a lot of "CPQ is broken" complaints: two systems disagree about what the canonical object is, and nobody has built (or should have to keep rebuilding) the translation layer between them.
This is precisely the problem a native extensibility layer is built to solve. It reduces the need for the sync by changing the system of record: the commerce platform becomes the source of truth for the quote, so quote and cart live in one model instead of two systems syncing. Model the quote as a native, versionable object in the commerce platform and the proliferation problem goes away — one quote versions as terms change, instead of new carts spawning new quotes to reconcile.
Here's the part that's easy to miss if you only look at one CPQ issue at a time: even the internal teams responsible for quoting acknowledge that requirements differ wildly from customer to customer. Approval-based quoting, price-list quoting, procurement punch-out quoting, and quote-to-cart conversion are all different builds with the same "quoting" label. That's a big part of why quoting stays a recurring, frequently requested item in product backlogs without ever becoming a single committed release — there isn't a single feature that would satisfy all of it.
That variance is itself evidence that off-the-shelf CPQ, built around one workflow assumption, will always feel like it's failing someone. A bigger, more configurable CPQ module trying to anticipate every variant in advance won’t work. Most organizations need a data model flexible enough that each account can define the shape of quoting that matches their business — without waiting on a platform vendor's roadmap to add their specific variant as a supported configuration.
Elastic Path Commerce Extensions is designed for exactly this: the data model adapts to whichever quoting workflow a business runs.
One distribution company had a different kind of constraint. Quoting is business-critical in their market; as one contact put it, everybody requests a quote before buying. But local tax rules forbid discounts from appearing on the quote itself; discounts can only be applied at delivery or order time.
In this case, generic discounting logic — which assumes discounts belong wherever the price is first shown — becomes a compliance risk. A common data model gives you a place to model account- or region-specific attributes (tax treatment, discount eligibility, delivery-time pricing rules) as structured, queryable data instead of another one-off exception buried in code. The model doesn't enforce the rule for you. The business logic for when a discount applies still lives in your application layer — the data model just gives that logic something reliable and queryable to read from, instead of a scattered set of conditionals.
The pattern across these companies is that quote-centric CRM workflows and cart-centric commerce platforms are frequently built on incompatible assumptions about the source of truth. Most teams are left compensating with custom fields, sprawling microservices, external databases, or manual glue code to keep the two in sync.
Elastic Path Commerce Extensions is built for this specific problem: a native extensibility layer for custom resource types, structured attributes on existing resources like carts and orders, explicit relationships between custom and native objects, and event-driven triggers tied to commerce lifecycle events — all hosted, secured, and scaled inside the platform rather than as separate infrastructure you have to run yourself.
Schedule a demo to see how Elastic Path delivers unified commerce for leading global brands.