# CRM e ERP em vendas complexas: quem é dono de cada dado, da proposta ao faturamento

> CRM e ERP em vendas complexas: defina quem é dono de cada dado, da proposta ao faturamento, onde a integração quebra e o que perguntar ao fornecedor.

- Tipo: Artigo
- Autor: Dionatha Rodrigues
- Publicado em: 2026-11-01 · Atualizado em: 2026-10-30
- URL: https://clubmartech.com.br/blog/crm-e-erp-vendas-complexas/

A venda foi marcada como ganha no CRM numa quinta-feira. Na segunda, o financeiro avisa que não encontra o pedido. O vendedor garante que fechou, o ERP não mostra nada com aquele cliente e alguém gasta a tarde procurando a empresa certa, que está escrita de um jeito num sistema e de outro no outro. O problema raramente é de um dos dois softwares e quase sempre aparece na passagem entre **CRM e ERP**, onde ninguém combinou quem manda em cada informação.

Pense na comanda de um restaurante. O garçom anota “sem cebola, mesa 12” do jeito que entende; a cozinha lê do jeito que precisa; o caixa cobra pelo que está no sistema. Enquanto a comanda é copiada à mão, cada cópia é uma chance de a cebola voltar ao prato. Numa venda complexa, o CRM é o bloco do garçom, o ERP é a cozinha e o caixa, e a proposta é a comanda que precisa chegar inteira.

Este artigo trata desse trecho: quem é dono de cada dado entre a oportunidade e o faturamento, onde ele quebra, como viaja e o que perguntar antes de integrar. A escolha do sistema está em [sistema CRM para empresas brasileiras](https://clubmartech.com.br/blog/sistema-crm-empresas-brasileiras/); aqui o recorte é o campo de dados.

## Por que a venda complexa quebra entre CRM e ERP

Numa venda simples, o preço é o da tabela, o item é um só e o pagamento é à vista. Na venda complexa, entram vários itens, condição negociada, impostos, aprovação interna e mais de uma versão da proposta. Cada informação nasce no CRM ou no ERP e é exigida no outro.

O CRM ajuda o vendedor a avançar o negócio. O ERP ajuda a empresa a cumprir o pedido: controlar estoque, faturar, cobrar. São lógicas diferentes. O erro comum é tratar a integração entre CRM e ERP como “ligar os dois” quando a pergunta real é qual dos dois manda em cada campo. Sem essa resposta, a integração copia o engano nos dois sentidos, e mais depressa.

O texto sobre [tipos de dados em automações](https://clubmartech.com.br/blog/tipos-dados-automacoes/) explica por que texto, número e campo vazio quebram integrações, e o de [migração de CRM](https://clubmartech.com.br/blog/migracao-crm-continuidade-operacao/) trata da troca de sistema. Para testar a sua integração de CRM e ERP, pergunte ao financeiro: *“Das últimas dez vendas ganhas, em quantas o pedido apareceu no ERP sem ninguém ter de procurar?”*

## Onde o dado muda de dono, campo por campo

Em CRM e ERP, a pergunta que organiza o desenho é a da fonte da verdade. O [artigo do blog da Ploomes](https://blog.ploomes.com/crm-para-empresas-com-erp/), fornecedora de CRM, publicado em 24/09/2026, define o termo como o sistema oficialmente responsável por cada tipo de dado. No texto, produtos, estoque, tabelas de preço e status financeiro ficam com o ERP; propostas ficam com o CRM, que as envia ao ERP como pedido; clientes são criados no CRM e validados pelo ERP. Se CRM e ERP podem alterar o mesmo campo, o artigo pede regra de precedência.

A tabela abaixo é leitura do Club Martech para um caso típico; o seu desenho pode inverter linhas.

| Dado | Onde nasce | Quem deveria ser o dono depois do pedido | O que quebra se ninguém decidir |
| --- | --- | --- | --- |
| Cliente (razão social, CNPJ, endereço de cobrança) | CRM | ERP, que valida o cadastro fiscal | Dois cadastros do mesmo cliente, um por nome fantasia e outro por razão social |
| Produto e código | ERP | ERP | Proposta com item que não existe no cadastro do ERP |
| Tabela de preço e condição | ERP | ERP para a tabela, CRM para a proposta | Proposta montada com preço antigo |
| Desconto | CRM | Quem aprova pela regra de alçada | Pedido entra com desconto que ninguém autorizou |
| Pedido | CRM, depois ERP | ERP | Pedido sem vínculo com a oportunidade de origem |
| Faturamento e status financeiro | ERP | ERP | O CRM mostra “ganho” sem informar se houve fatura |

> A única recomendação de fornecedor nesta seção vem do blog da Ploomes, empresa que vende CRM com integração a ERP, e é uma sugestão de desenho, não um padrão de mercado. As colunas do meio e da direita são do Club Martech. Há empresas em que a tabela de preço nasce na área comercial, e aí a linha muda.

Na reunião em que o desenho for discutido, faça esta pergunta a cada linha: *“Se este campo estiver diferente nos dois sistemas na segunda de manhã, qual vale, e quem corrige?”*

## Cinco pontos de quebra e o sintoma de cada um

**Cadastro duplicado.** O mesmo cliente aparece com dois cadastros e o histórico de compras fica dividido entre eles, por falta de uma chave única combinada entre os sistemas. A documentação pública da integração Ploomes e Omie diz que a duplicidade de cliente é verificada por CPF ou CNPJ, ou pelo ID do Omie quando preenchido. O blog da Ploomes acrescenta suportar matriz e filiais, para o limite de crédito ser calculado no nível certo, e padronizar estado e moeda, porque “SP” e “São Paulo” são valores diferentes para uma integração.

**Tabela de preço desatualizada.** O cliente aprova a proposta, e o ERP a recusa ou a aceita com valor diferente do combinado, em geral por causa de uma cópia da tabela que ficou para trás. Ou o preço é consultado na hora da proposta, ou há cópia atualizada com frequência combinada.

**Desconto fora de alçada.** O financeiro recebe um pedido já assinado com margem abaixo do aceitável, porque a regra de aprovação existe só na cabeça do gerente.

**Pedido sem vínculo com a oportunidade.** É o sintoma da abertura: a venda ganha que ninguém acha. Falta gravar, em cada sistema, o identificador do registro do outro. Há uma variante pior: segundo a documentação do Omie com o Ploomes, o cancelamento feito no Omie não é refletido automaticamente no Ploomes. O pedido morreu no ERP e o CRM segue mostrando venda ganha.

**Receita diferente do previsto.** A previsão do CRM soma um valor e o resultado do mês mostra outro. O valor da proposta não é, por si, a receita do período: quando a venda vira receita é regra contábil, decidida com o contador. O texto sobre [quote-to-cash](https://clubmartech.com.br/blog/quote-cash-pratica-previsivel/) trata do trecho da proposta ao recebimento, e o de [lead to cash](https://clubmartech.com.br/blog/lead-to-cash-revops/), da distância até o dinheiro.

## Como o dado viaja: digitação, planilha, conector ou API

Com o dono de cada campo definido, falta decidir como CRM e ERP trocam dados. As formas mais comuns são digitar de novo, exportar e importar planilha, usar um conector pronto do fornecedor, ou ligar CRM e ERP por iPaaS ou pela API de cada sistema, em projeto próprio.

Digitação e planilha dependem de uma pessoa e podem deixar rastros incompletos quando não há registro das alterações. Conector pronto e iPaaS reduzem o trabalho manual, e o risco passa a ser a cobertura menor que a prometida e a falha silenciosa. Duas escolhas valem mais que a ferramenta. A primeira é o sentido: um dado pode ir só do ERP para o CRM, só no outro sentido ou nos dois. A documentação do Omie com o Ploomes mostra os dois casos: clientes e vendas nos dois sentidos, produtos só do Omie para o Ploomes. A segunda é o ritmo. Segundo o blog da Ploomes, limite de crédito e criação de pedido pedem baixa latência; catálogo, tabelas e status de faturamento podem ir em lote. É sugestão do fornecedor; o seu ERP pode não aceitar esse ritmo.

O [guia de ferramentas de automação de vendas](https://clubmartech.com.br/blog/ferramentas-automacao-vendas-roi/) ajuda a comparar custo e esforço. Antes, responda: *“Se a integração entre CRM e ERP parar na sexta à noite, quem percebe, em quanto tempo e com que aviso?”*

## O que o fornecedor declara e o que você confere sozinho

Vale separar duas pilhas: o que você verifica em minutos, em documentação pública, e o que o fornecedor afirma e você só confirma testando. A Ploomes serve de exemplo porque publica as duas.

**O que você confere sozinho**, na [documentação da integração Ploomes e Omie](https://suporte.ploomes.com/pt-BR/articles/5452457-documentacao-da-integracao-ploomes-omie):

- clientes e vendas sincronizam nos dois sentidos, e produtos e serviços vão só do Omie para o Ploomes;
- a duplicidade de cliente é verificada por CPF ou CNPJ, ou pelo ID do Omie;
- propostas não fazem parte da integração: os preços são configurados no Ploomes, e do Omie vem a consulta de estoque;
- o cancelamento de venda feito no Omie não é refletido automaticamente no Ploomes;
- ao ativar, dados de clientes que já existem no Ploomes podem sobrescrever os do Omie, porque o Ploomes é tratado como fonte primária.

**O que o fornecedor afirma**, na [página de integração com ERP](https://www.ploomes.com/en/product/erp-integration) e no site principal:

- que a integração entre CRM e ERP permite “sincronizar todos os dados da sua operação” e minimizar erros;
- que propostas, orçamentos e pedidos são replicados quando criados ou atualizados, em cópia única ou dupla;
- que há um módulo de CPQ, descrito como “Configure, precifique, cote e venda”;
- que a API REST e os webhooks permitem construir integrações de forma independente.

A página geral fala de replicar propostas e pedidos. A documentação do Omie diz que propostas não são integradas. Não é contradição: a cobertura varia por ERP e por entidade, e a página de ERP lista logotipos sem dizer quais integrações são prontas e quais são projeto. A pergunta útil é por entidade e por ERP: *“Para o meu ERP, o que sincroniza, em que sentido e com que chave?”*

> Li essas páginas públicas em 26/10/2026, sem testar o produto nem uma integração entre CRM e ERP real, e documentação muda. A Ploomes é exemplo porque publica a documentação por ERP, não por ser a mais adequada; a conferência vale para qualquer fornecedor.

## Aprovação de desconto: a regra precisa existir antes do pedido

Em venda complexa, o desconto é decisão de margem. O blog da Ploomes recomenda que a proposta passe por aprovação de margem antes de virar pedido no ERP, e que financeiro e vendas dividam a responsabilidade pelas regras de preço. Na página inicial da Ploomes que li, não encontrei menção a aprovação de desconto; vale perguntar ao fornecedor como isso funciona no plano contratado.

A regra de aprovação precisa viver no sistema, e a aprovação no chat não conta como registro. Se o gerente aprovou numa conversa, o ERP não sabe, e o financeiro só descobre quando fatura. Defina por escrito até que percentual cada cargo decide sozinho, quem aprova o que passa disso e onde o registro fica. É o cuidado de [higiene de pipeline](https://clubmartech.com.br/blog/higiene-de-pipeline-leads-zumbis/) aplicado ao preço. Pergunte: *“Este desconto, neste prazo, para este cliente, foi aprovado por quem, e onde isso está registrado?”*

## O que perguntar ao fornecedor do CRM e ao time do ERP

O mesmo blog traz um roteiro técnico para a TI avaliar o CRM antes de contratar. Os itens que mais importam aqui:

- o CRM tem API pública e documentada, com limite de chamadas informado?
- ele envia webhooks quando um negócio é ganho?
- a API evita registro duplicado se a mesma requisição for reenviada, o que se chama idempotência?
- existe painel de erros de integração, para ver o que falhou e por quê?
- há ambiente isolado de testes?

Para o time do ERP, as perguntas são outras:

- qual campo do cadastro de cliente é a chave, e o que acontece se o CRM enviar um CNPJ já existente?
- o que o ERP rejeita (cadastro incompleto, item sem código fiscal, vendedor inativo) e para onde vai a mensagem de erro?
- cancelamentos feitos no ERP voltam para o CRM, e como?

Uma resposta pode mudar o desenho inteiro. Segundo a documentação do Omie com o Ploomes, mapear qualquer campo de imposto faz o ERP deixar de calcular impostos, decisão que cabe ao time fiscal.

> O checklist técnico vem do blog de um fornecedor de CRM e ajuda a formular perguntas, mas não é critério independente: um fornecedor que atende todos os itens ainda pode falhar no seu ERP. O que decide é um teste com os seus dados, em ambiente separado, e a opinião de quem opera o ERP.

## Próximos passos para alinhar o CRM e o ERP

1. **Separe as dez últimas vendas ganhas** e, para cada uma, anote se o pedido apareceu no ERP sem ninguém procurar. Use identificadores internos, sem nome nem documento do cliente.
2. **Refaça a tabela de campos** com a sua realidade e escreva o dono de cada um. Procure os campos sem dono, ou com dois: é por eles que a integração entre CRM e ERP falha.
3. **Grave o identificador cruzado:** cada oportunidade com o número do pedido no ERP, e cada pedido com o código da oportunidade.
4. **Escreva a regra de alçada de desconto** e diga onde o registro da aprovação fica.
5. **Leve as perguntas da seção anterior** ao fornecedor do CRM e ao time do ERP, por escrito.

Comece pelo primeiro passo: dez vendas e uma coluna “apareceu no ERP?” já mostram onde a integração entre CRM e ERP atrasa.