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; 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 explica por que texto, número e campo vazio quebram integrações, e o de migração de CRM 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, 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 trata do trecho da proposta ao recebimento, e o de lead to cash, 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 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:
- 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 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 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
- 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.
- 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.
- Grave o identificador cruzado: cada oportunidade com o número do pedido no ERP, e cada pedido com o código da oportunidade.
- Escreva a regra de alçada de desconto e diga onde o registro da aprovação fica.
- 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.
