Salesforce CPQ vs Revenue Cloud: the real differences

Salesforce CPQ and Revenue Cloud solve the same task, configure, price, quote and bill, but they are different products. CPQ and Salesforce Billing are managed packages from SteelBrick with their own objects under the SBQQ and blng namespaces. Revenue Cloud runs on standard objects, configures with a constraint engine, calculates prices with pricing procedures and manages sold products as assets. Salesforce Help says the data models “differ significantly” and that Revenue Cloud is “not just the next version of Salesforce CPQ”. For a CPQ customer that means a redesign of rules, prices and data, because there is no upgrade path.

Where do both products come from?

Salesforce bought SteelBrick in December 2015 for $360 million, according to SiliconANGLE1. SteelBrick’s quote-to-cash software already ran natively on the Salesforce platform. It became Salesforce CPQ and Salesforce Billing, both installed as managed packages. CPQ objects carry the SBQQ__ prefix, for example SBQQ__Quote__c, and the Billing developer guide2 lists its objects under blng__.

Revenue Cloud’s developer documentation goes back to Spring ’24 (API 60.0), when the product was called Revenue Lifecycle Management. It was then sold as Revenue Cloud Advanced and appears in current documentation as Revenue Management. The Winter ’27 developer guide3 is titled “Revenue Management Developer Guide” and describes standard objects and business APIs per area. Salesforce itself wrote in July 2025 that it “rebuilt its CPQ solution as the all-new Revenue Cloud”. CPQ is now end of sale, without an end-of-life date; the details are in Salesforce CPQ end of sale: what applies in October 2026.

1. Dec 2015Salesforce buys SteelBrick, which becomes Salesforce CPQ and Salesforce Billing
2. Spring '24Revenue Lifecycle Management in the developer documentation (API 60.0)
3. Jul 2025Salesforce: CPQ rebuilt as the "all-new Revenue Cloud"
4. Winter '27Developer guide titled "Revenue Management Developer Guide"

The differences at a glance

Area	Salesforce CPQ and Billing (SteelBrick)	Revenue Cloud
Technical form	Managed packages, namespaces SBQQ and blng	Standard data model of the platform, API-first quoting
Quote, order, sold products	Package objects such as SBQQ__Quote__c, subscription records on the contract	Standard objects Quote, Order, Asset
Product model	Products and bundles with features and options	Catalogs, categories, product classifications with attributes, bundles
Configuration rules	Product rules: validation, selection, filter, alert	Configuration rules and the constraint rules engine with CML
Pricing	Price rules, optional JavaScript quote calculator plugin	Pricing procedures, decision tables, context definitions, price waterfall
After the sale	Contract with subscription records	Assets with asset state periods and asset actions
Amendment and renewal	New quote and opportunity on the contract	Amendment or renewal quote, then an order
Approvals	Advanced Approvals package	Advanced Approvals as invocable actions and business APIs
Order to fulfilment	Order generated from the quote	Order, optionally through Dynamic Revenue Orchestrator (add-on)
Billing	Salesforce Billing package	Revenue Cloud Billing add-on: usage rating and digital wallet, invoicing, payments, collections, accounting subledger
Reports and dashboards	Built on package objects	Rebuilt on standard objects
Configuration storage	Mostly records	Mostly records
Status October 2026	End of sale, maintenance phase, no new features	Actively developed, sold as Growth and Advanced

Sources for the table follow in the sections below. The row on configuration storage is the one similarity that matters for operations: according to Gearset4, most configuration lives as data in both products, so deployments need data templates in both cases, just for different objects.

How do product model and configurator differ?

In CPQ a configurable product is a bundle with features and options. Product rules5 come in four types: validation rules check combinations, selection rules add, remove, hide or disable options, filter rules prefilter what can be added, and alert rules show messages. Each rule is an explicit if-then statement with its own condition and action records.

Revenue Cloud starts with the catalog. According to Trailhead6, a product classification is a template with a set of attributes. Products created from it inherit the attributes and can override some. For variant-rich machines that changes the modelling question: properties such as voltage or colour become attributes instead of separate options or products.

For the rules, Revenue Cloud offers the constraint rules engine7. It evaluates all possible combinations and removes invalid ones while the user configures. Rules are written in the Constraint Modeling Language (CML), either directly in the CML editor or generated by the no-code Visual Builder. Trailhead describes the difference itself: rule-based setups use explicit if-then logic, constraint-based setups use declarative constraints between options and need fewer rules for complex products.

My view: this is the biggest change for a manufacturer. Three hundred product rules do not translate into three hundred constraints. Someone has to understand what the rules mean technically and model them again, and that person usually sits in product management or engineering, not in the CRM team.

Pricing procedures replace price rules and the plugin

In CPQ, price rules5 automate calculations and update quote line fields. Where they were not enough, many orgs added the JavaScript quote calculator plugin8, custom JavaScript stored as custom scripts that changes how the quote line editor calculates.

Revenue Cloud calculates with Salesforce Pricing9. A context definition passes product data from the quote to a pricing procedure. The procedure runs its pricing elements in sequence, decision tables fetch the pricing data, and the result goes back to the quote. A price waterfall shows every step from list price to net price. For finance and audits that waterfall is a real improvement, because the question “why this price?” gets an answer on screen.

A quote calculator plugin has no direct counterpart. Its logic has to be split into procedure elements, decision tables or an external call. In a worked example with assumed numbers, a component maker has 40 price rules and a plugin with a few hundred lines of JavaScript for dealer discounts. Each rule and each branch of the plugin becomes a design decision: is it still needed, does it belong in a procedure, or should the price come from SAP?

How do contracts, amendments and renewals differ?

In CPQ the sale ends in a contract. According to Trailhead10, the contract holds subscription records for subscription products. An amendment creates a new quote and opportunity, priced for the remaining term, and CPQ can create renewal opportunities and quotes automatically.

Revenue Cloud keeps the installed base as assets. Trailhead11 describes that every change is processed as a quote and completed through an order. Asset state periods record the quantity over time, asset actions log each change such as an upsell, and the quote shows start quantity, change and end quantity.

For manufacturers with service contracts and subscriptions this is the second big change. Open CPQ subscriptions have to become assets with a correct history, which Salesforce Help covers under asset data in its migration guide.

Billing and approvals are separate products too

The Salesforce Billing package and Revenue Cloud Billing are also separate products. According to Salesforce12, Revenue Cloud Billing includes usage rating with a digital wallet, an invoicing engine with document production, payments, collections, tax through external engines and an accounting subledger that syncs journal entries to the ERP. What a move means for open invoices and payment history is covered in from Salesforce Billing to Revenue Cloud Billing.

Approvals have the same name in both worlds, which causes confusion. In CPQ, Advanced Approvals is a package of its own13. In Revenue Cloud, Advanced Approvals14 consists of invocable actions, business APIs and fields on standard objects. Approval chains have to be rebuilt.

Why is the move no upgrade?

Salesforce says so itself. The Help page Migrate to Revenue Management15 states that the data models “differ significantly”, that the move “requires updates to the system architecture”, that reports and dashboards are rebuilt on the standard objects, and that “tools don’t replace human design decisions, particularly for custom logic and integration remapping”. It describes three phases that are completed in sequence and no fixed timeframe.

From this I draw three conclusions for a manufacturer:

1. Budget it like a new implementation. Migration tools move data, but rules, prices and approvals are redesigned. Salesforce names three to six months as typical, which I would only plan for a clean org.
2. Clean up first. Every unused product rule, price rule and plugin branch you delete before the migration is one less design decision. An org assessment shows what is actually used.
3. Plan deployments for data. Catalog, pricing and configuration are records in Revenue Cloud too. The DevOps chapter on data and configuration covers how such data moves through the pipeline.

Whether the move pays off at all is a separate question, which I answer in keep Salesforce CPQ or move to Revenue Cloud?.

Count rules, plugin lines and integrations

Count what you have: product rules, price rules, lines in the quote calculator plugin, quote templates, approval chains, open subscriptions and integrations that write to SBQQ objects. That list is the scope of the redesign. How the migration then runs in phases is described in CPQ to Revenue Cloud migration and in the masterclass chapter from CPQ to Revenue Cloud.

Sources15

1. 1SiliconANGLE (opens in a new tab)siliconangle.com
2. 2Billing developer guide (opens in a new tab)developer.salesforce.com
3. 3Winter ’27 developer guide (opens in a new tab)developer.salesforce.com
4. 4Gearset (opens in a new tab)docs.gearset.com
5. 5Product rules (opens in a new tab)trailhead.salesforce.com
6. 6Trailhead (opens in a new tab)trailhead.salesforce.com
7. 7constraint rules engine (opens in a new tab)trailhead.salesforce.com
8. 8JavaScript quote calculator plugin (opens in a new tab)developer.salesforce.com
9. 9Salesforce Pricing (opens in a new tab)trailhead.salesforce.com
10. 10Trailhead (opens in a new tab)trailhead.salesforce.com
11. 11Trailhead (opens in a new tab)trailhead.salesforce.com
12. 12Salesforce (opens in a new tab)salesforce.com
13. 13package of its own (opens in a new tab)trailhead.salesforce.com
14. 14Advanced Approvals (opens in a new tab)developer.salesforce.com
15. 15Migrate to Revenue Management (opens in a new tab)help.salesforce.com