Quando Vender Mais Não Significa Ganhar Mais · 09 de outubro de 2026 · 7 min

Adobe Commerce ou CWS Platform: o pedido devolvido entra na conta da licença?

Um comparativo pela ótica do CFO: o que conta como pedido na medição da licença e onde a política comercial é mantida.

Homem de suéter cinza em pé ao lado de uma mesa de reunião, com uma colega sentada ao fundo, perto da janela.

Nota editorial: comparativo de arquitetura entre Adobe Commerce e a CWS Platform, escrito para quem responde como CFO. Todo fato sobre Adobe Commerce vem da documentação pública dele, com o endereço ao lado.

Quando o CFO avalia uma plataforma de comércio B2B, o valor da licença no primeiro ano diz pouco. O que define o orçamento de três anos é a regra de medição: o que conta como pedido, o que acontece quando o volume cresce e se um pedido devolvido sai da conta. É uma pergunta de contrato, não de tecnologia, e vale fazê-la antes de comparar funcionalidades.

Este comparativo olha para Adobe Commerce e CWS Platform por esse ângulo. De um lado, uma licença com níveis definidos pelo volume transacionado. Do outro, uma licença de plataforma que não depende do que é vendido por ela.

O que o Adobe Commerce resolve bem

O Adobe Commerce estrutura sua abordagem transacional a partir de uma hierarquia corporativa nativa de autoatendimento B2B. A plataforma opera sobre contas de empresa que agrupam múltiplos compradores, permitindo que o administrador da organização cliente crie divisões, subdivisões e usuários internos, com distribuição de papéis e limites de autorização específicos para cotação, compra e acesso a crédito corporativo.

Para atender negociações comerciais recorrentes, a solução permite associar catálogos compartilhados com tabelas de preços customizadas por empresa compradora ou grupos de clientes em diferentes vitrines. Além disso, compradores autorizados podem iniciar pedidos de cotação diretamente pelo carrinho de compras, abrindo um canal formal de negociação no qual compradores e vendedores trocam mensagens, ajustam descontos e atualizam quantidades no grid administrativo.

Na gestão de aprovações internas, a ativação de regras de compra transforma transações em pedidos de compra formais (Purchase Orders), sujeitos a múltiplas regras de aprovação conforme o perfil funcional do colaborador corporativo. A suíte suporta implantações sob as modalidades de serviço em nuvem multi-tenant, infraestrutura dedicada em nuvem ou modelos desacoplados com serviços de catálogo e merchandising, conforme detalhado no modelo de implantação da solução.

Onde a arquitetura diverge

A divergência que interessa ao orçamento está em como o pedido entra na medição da licença.

Comparação em dois painéis: à esquerda, medição pelo volume bruto, que inclui pedido devolvido; à direita, licença de plataforma que não depende das vendas.

A descrição de produto da própria Adobe registra como o pedido é contado:

limitação registrada na documentação do fornecedor em 30/04/2026: todo pedido aceito conta como transação, mesmo que depois seja reembolsado, devolvido ou estornado ("even if such order is later subject to a refund, return, chargeback", https://helpx.adobe.com/legal/product-descriptions/adobe-commerce-on-cloud.html).

Na CWS Platform, a cobrança é de licença de plataforma e de integração, sem percentual sobre vendas nem sobre GMV. O volume vendido não é base de cálculo. Em operações de marketplace, o percentual que aparece na divisão do pagamento é a comissão do dono do marketplace; a CWS cobra só a licença da plataforma.

A outra divergência é onde a política comercial é mantida. No Adobe Commerce, ela se organiza em contas de empresa e catálogos compartilhados configurados no painel de administração. Na CWS Platform, ela fica em parâmetros do Commerce Rules Engine (CDL Workspace), e o preço segue a hierarquia contrato, regra e tabela.

decisão	Adobe Commerce, pelo mecanismo documentado	CWS Platform
Como o pedido entra na medição da licença	Todo pedido aceito conta como transação, mesmo que depois seja reembolsado, devolvido ou estornado.	O volume vendido não é base de cálculo da licença.
Onde a política comercial é expressa	Organiza-se em contas corporativas com divisões e catálogos compartilhados configurados no painel de administração.	Parâmetros no Commerce Rules Engine (CDL Workspace), com o preço na hierarquia contrato, regra e tabela.
Caminho de extensão e integração	Expõe APIs GraphQL e REST para integração de serviços de back-office, catálogo e módulos de terceiros.	Integra-se ao ERP e aos demais sistemas por APIs REST e webhooks.

A decisão financeira é saber qual número do negócio vai mover a linha de software: o volume transacionado ou o escopo da plataforma.

O que muda na operação, pela lente de CFO

Em uma operação B2B, devolução, cancelamento e estorno fazem parte da rotina, e por isso a regra de contagem importa. Se o pedido conta mesmo depois de revertido, a base de medição é o volume bruto, e a projeção de custo precisa usar esse número, não a receita líquida do canal.

Diagrama de camadas da política comercial em três níveis sobrepostos, partindo da tabela base até o contrato específico do cliente.

Antes de assinar, vale pedir ao fornecedor três respostas por escrito: o que conta como pedido ou como transação; se devolução e cancelamento saem da medição; e o que acontece quando o volume passa do nível contratado.

Na CWS Platform, a linha de software não depende do faturamento do canal. As regras que formam o preço de cada pedido ficam em parâmetros: tabelas, regras e contratos são configurados na plataforma e podem vir do ERP, do CRM ou de outro sistema por API. O imposto por item é calculado pela API de tributos do ERP do cliente, e o limite de crédito funciona como conta corrente do cliente na plataforma.

Onde nascem as dores deste cenário, e como a arquitetura as resolve:

dor	por que acontece	como a arquitetura resolve
“Cada mudança simples exige seis meses de TI”	A regra comercial depende de customização, e cada alteração passa por desenvolvimento.	A política comercial é parametrizada no Commerce Rules Engine (CDL Workspace) e alterada por configuração.
“O preço negociado de cada cliente não cabe no portal”	Catálogos estáticos não representam tabelas contratuais que variam por comprador, volume e filial.	O preço segue a hierarquia contrato, regra e tabela, com regras elegíveis pelo perfil do cliente e pela UF de origem e de destino.

Quando escolher o Adobe Commerce

A arquitetura do Adobe Commerce demonstra adequação clara para operações que demandam estruturas corporativas específicas e gestão avançada de vitrines:

Estruturas de compra com hierarquia corporativa profunda. Escolha essa arquitetura quando a operação exigir que a própria empresa cliente administre múltiplos níveis de compradores, definindo divisões, subdivisões e alçadas de requisição interna em autosserviço. O mecanismo de contas de empresa e papéis de compradores resolve nativamente a delegação da governança de compras para o cliente corporativo.

Processos bilaterais de negociação formal de cotações. Escolha essa arquitetura quando a jornada comercial depender de envio formal de cotações entre o carrinho de compras e o painel administrativo, com histórico documental de trocas de mensagens e revisão de propostas antes da conversão em pedido. A ferramenta disponibiliza negociação por cotação no admin e vitrine desenhada para esse fluxo documental bilateral.

Ecossistemas globais com múltiplos sites e moedas. Escolha essa arquitetura quando a estratégia de negócios demandar a consolidação de dezenas de lojas, catálogos e marcas internacionais sob uma única instância técnica. A estrutura hierárquica nativa de website, store e store view permite segregar domínios, moedas e idiomas mantendo a administração centralizada.

Quando a CWS Platform é a escolha certa neste cenário

Escolha a CWS Platform quando a prioridade for uma linha de software previsível e uma política comercial mantida por configuração.

Licença que não acompanha o volume vendido. Escolha essa arquitetura quando o orçamento precisa de uma linha de software que não varie com o volume transacionado. A cobrança é de licença de plataforma e de integração, sem percentual sobre vendas ou GMV.

Uma versão para todos os clientes. Escolha essa arquitetura quando a empresa não quer orçar projeto de upgrade. Todos os clientes rodam a mesma versão da plataforma, sem troca de framework do lado do cliente.

Crédito e preço em parâmetros. Escolha essa arquitetura quando o limite de crédito e as condições comerciais precisam ser alterados pela área de negócio. O limite funciona como conta corrente do cliente, concedido no CDL Workspace ou por API, e tabelas, regras e contratos são configurados na plataforma.

ERP como fonte do imposto. Escolha essa arquitetura quando o cálculo tributário deve continuar no ERP. O imposto por item vem da API de tributos do ERP do cliente, e a plataforma se integra por APIs REST e webhooks.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se o que trava hoje é a dor por trás deste cenário, as páginas Quando a Integração Trava Tudo e Quando Vender Mais Não Significa Ganhar Mais tratam disso em profundidade, sem falar de fornecedor nenhum.