Adobe Commerce vs CWS Platform: Do Returned Orders Count Toward Licensing?
A comparison from the CFO point of view: what counts as an order in the license measurement and where commercial policy is maintained.
Editorial note: an architecture comparison between Adobe Commerce and CWS Platform, written for those who answer as CFO. Every fact about Adobe Commerce comes from its public documentation, with the address next to it.
When the CFO evaluates a B2B commerce platform, the license amount in the first year says little. What defines the three-year budget is the measurement rule: what counts as an order, what happens when volume grows, and whether a returned order leaves the count. It is a contract question, not a technology one, and it is worth asking before comparing features.
This comparison looks at Adobe Commerce and CWS Platform from that angle. On one side, a license with levels defined by the volume transacted. On the other, a platform license that does not depend on what is sold through it.
What Adobe Commerce solves well
Adobe Commerce structures its transactional approach on a native corporate hierarchy for B2B self-service. The platform operates on company accounts that group multiple buyers, allowing the administrator of the customer organization to create divisions, subdivisions, and internal users, with roles and specific authorization limits for quoting, purchasing, and access to corporate credit.
To serve recurring commercial negotiations, the solution allows shared catalogs with custom price tables to be associated by buyer company or customer groups in different storefronts. In addition, authorized buyers can start quote requests directly from the shopping cart, opening a formal negotiation channel in which buyers and sellers exchange messages, adjust discounts, and update quantities in the administrative grid.
In the management of internal approvals, activating purchasing rules turns transactions into formal purchase orders, subject to multiple approval rules according to the profile of the corporate employee. The suite supports deployments as a multi-tenant cloud service, dedicated cloud infrastructure, or decoupled models with catalog and merchandising services, as detailed in the solution's deployment model.
Where the architecture diverges
The divergence that matters to the budget is how the order enters the license measurement.
Adobe's own product description records how the order is counted:
- limitation recorded in the vendor's documentation on April 30, 2026: every accepted order counts as a transaction, even if it is later refunded, returned, or charged back ("even if such order is later subject to a refund, return, chargeback", https://helpx.adobe.com/legal/product-descriptions/adobe-commerce-on-cloud.html).
On CWS Platform, billing is a platform and integration license, with no percentage on sales or on GMV. The volume sold is not a calculation base. In marketplace operations, the percentage that appears in the payment split is the marketplace owner's commission; CWS charges only the platform license.
The other divergence is where commercial policy is maintained. In Adobe Commerce, it is organized in company accounts and shared catalogs configured in the administration panel. On CWS Platform, it sits in parameters of the Commerce Rules Engine (CDL Workspace), and price follows the hierarchy of contract, rule, and table.
| decision | Adobe Commerce, per the documented mechanism | CWS Platform |
|---|---|---|
| How the order enters the license measurement | Every accepted order counts as a transaction, even if it is later refunded, returned, or charged back. | The volume sold is not a calculation base for the license. |
| Where commercial policy is expressed | Organized in corporate accounts with divisions and shared catalogs configured in the administration panel. | Parameters in the Commerce Rules Engine (CDL Workspace), with price in the hierarchy of contract, rule, and table. |
| Extension and integration path | Exposes GraphQL and REST APIs for integrating back-office services, catalog, and third-party modules. | Integrates with the ERP and the other systems through REST APIs and webhooks. |
The financial decision is knowing which business number will move the software line: the volume transacted or the scope of the platform.
What changes in the operation, through the CFO lens
In a B2B operation, returns, cancellations, and chargebacks are part of the routine, and that is why the counting rule matters. If the order counts even after being reversed, the measurement base is gross volume, and the cost projection needs to use that number, not the channel's net revenue.
Before signing, it is worth asking the vendor for three answers in writing: what counts as an order or as a transaction; whether returns and cancellations leave the measurement; and what happens when volume goes past the contracted level.
On CWS Platform, the software line does not depend on the channel's revenue. The rules that form the price of each order sit in parameters: tables, rules, and contracts are configured on the platform and can come from the ERP, the CRM, or another system through an API. Tax per item is calculated by the customer's ERP tax API, and the credit limit works as a current account for the customer on the platform.
Where the pains of this scenario come from, and how the architecture resolves them:
| pain | why it happens | how the architecture resolves it |
|---|---|---|
| "Every simple change takes six months of IT" | The commercial rule depends on customization, and each change goes through development. | Commercial policy is parameterized in the Commerce Rules Engine (CDL Workspace) and changed by configuration. |
| "Each customer's negotiated price does not fit in the portal" | Static catalogs do not represent contract tables that vary by buyer, volume, and branch. | Price follows the hierarchy of contract, rule, and table, with rules eligible by the customer's profile and by the origin and destination state. |
When to choose Adobe Commerce
The Adobe Commerce architecture shows a clear fit for operations that demand specific corporate structures and advanced storefront management:
Purchasing structures with deep corporate hierarchy. Choose this architecture when the operation requires the customer company itself to manage multiple levels of buyers, defining divisions, subdivisions, and internal requisition approval levels in self-service. The mechanism of company accounts and buyer roles natively resolves the delegation of purchasing governance to the corporate customer.
Bilateral processes of formal quote negotiation. Choose this architecture when the commercial journey depends on formally sending quotes between the shopping cart and the administrative panel, with a documented history of message exchanges and proposal review before conversion into an order. The tool provides quote negotiation in the admin and storefront designed for this bilateral document flow.
Global ecosystems with multiple sites and currencies. Choose this architecture when the business strategy demands consolidating dozens of stores, catalogs, and international brands under a single technical instance. The native hierarchical structure of website, store, and store view allows domains, currencies, and languages to be segregated while keeping administration centralized.
When CWS Platform is the right choice in this scenario
Choose CWS Platform when the priority is a predictable software line and a commercial policy maintained by configuration.
A license that does not follow the volume sold. Choose this architecture when the budget needs a software line that does not vary with the volume transacted. Billing is a platform and integration license, with no percentage on sales or GMV.
One version for all customers. Choose this architecture when the company does not want to budget for an upgrade project. All customers run the same version of the platform, with no framework change on the customer side.
Credit and price in parameters. Choose this architecture when the credit limit and commercial terms need to be changed by the business area. The limit works as a current account for the customer, granted in CDL Workspace or through an API, and tables, rules, and contracts are configured on the platform.
ERP as the source of tax. Choose this architecture when the tax calculation must remain in the ERP. Tax per item comes from the customer's ERP tax API, and the platform integrates through REST APIs and webhooks.
Where to go from here
If your question is still which architecture fits your operation, and not which vendor to choose, the path is the seven questions that separate B2B commerce architectures.
If what is blocking you today is the pain behind this scenario, the pages When Integration Blocks Everything and When Selling More Does Not Mean Earning More cover it in depth, without talking about any vendor.
Read also
"responsive, technically engaged, and willing to work through complex commercial rules (negotiated pricing, credit, customer-specific conditions) rather than pushing generic answers"
Want to see this in your operation?
Real B2B operations already run on it.