Integração CRM e ERP

Por que integrar CRM e ERP virou tema obrigatório

Por décadas, CRM e ERP foram sistemas separados, atendendo áreas separadas — CRM para vendas e marketing, ERP para finanças e operação. A integração era frequentemente manual: planilha exportada do ERP, importada no CRM, com atraso de dias. Comercial trabalhava em pipeline desconectado do faturamento; marketing acionava clientes inadimplentes sem saber; cliente único era ficção.

Quatro forças mudaram esse cenário:

Demanda por visão única do cliente. Líderes não aceitam mais que cada sistema tenha versão diferente do mesmo cliente. Diretoria pede relatório que liga oportunidade comercial a receita realizada — sem integração, impossível.

Operações de receita (RevOps) como função. Função formal que coordena marketing, vendas, sucesso do cliente e finanças exige dados integrados. Não há RevOps possível com sistemas em silos.

Pressão sobre eficiência. Mídia paga, força de vendas e atendimento custam caro. Empresas que conseguem priorizar esforço onde o ROI é maior (cliente saudável, oportunidade real, conta inadimplente) saem na frente. Priorização exige integração.

Disponibilidade de tecnologia. Plataformas de integração (iPaaS) ficaram mais acessíveis — Workato, Boomi, Zapier, Make. ERPs e CRMs expandiram catálogo de API e conectores pré-construídos. Integração que custava meses de projeto agora pode ser configurada em semanas para casos comuns.

O resultado é que integração CRM e ERP saiu da agenda de TI e virou tema de receita. Conversas envolvem CMO, CRO, CFO e CTO — não apenas arquiteto de sistemas.

Casos de uso típicos

Cinco casos de uso são padrão em operações maduras:

Cliente único. Cliente cadastrado no CRM (frequentemente como lead ou conta de oportunidade) e no ERP (como entidade faturável) é a mesma pessoa jurídica/física, identificada por CNPJ ou CPF. Quando vendedor abre oportunidade, encontra histórico de pedidos anteriores; quando faturamento processa pedido, encontra contexto comercial. Sem cliente único, divergências viram conflitos operacionais.

Pedido fechado vira oportunidade ganha. Quando o pedido é processado no ERP, a oportunidade correspondente no CRM é atualizada para "ganho" automaticamente, com valor real do pedido (que pode diferir do valor previsto). Permite comparação de previsão versus realização sem retrabalho manual.

Status financeiro acessível a vendas. Vendedor que vai prospectar conta vê no CRM se a empresa está inadimplente, em atraso ou em recuperação no ERP — evita acionar cliente em conflito financeiro. Marketing usa o mesmo sinal para suspender comunicação promocional a inadimplentes.

Contrato vigente acessível a sucesso do cliente. Sucesso do cliente vê no CRM o contrato vigente (data de início, vencimento, condições, produtos contratados) que vive no ERP. Permite planejar renovação, expansão e renegociação com base em dados reais.

Atribuição de receita. Marketing precisa saber qual fonte (canal, campanha, conteúdo) trouxe o cliente que gerou receita. Sem integração com ERP, a atribuição para em "oportunidade ganha"; com integração, vai até "receita realizada" — métrica que importa para CFO.

Dados típicos sincronizados

Integração madura sincroniza tipicamente seis categorias de dados:

Cliente. Razão social, CNPJ/CPF, endereço, contato principal. Direção: tipicamente ERP é fonte da verdade para dado fiscal/financeiro (razão social, endereço fiscal, situação cadastral); CRM é fonte da verdade para contatos individuais e enriquecimento. Sincronização bidirecional, com regra clara de prioridade em caso de divergência.

Produto. SKU, descrição, preço, categoria. Direção: ERP é fonte da verdade. CRM consome para apresentar catálogo em oportunidade e cotação. Sincronização tipicamente diária ou em mudança.

Pedido. Número, data, valor, produtos, condição comercial, status. Direção: ERP é fonte da verdade. CRM consome para fechar oportunidade e ligar a histórico.

Fatura e recebimento. Número, valor, vencimento, status (pago, em aberto, em atraso, pago parcialmente). Direção: ERP é fonte. CRM consome para informar vendas e marketing sobre saúde financeira da conta.

Contrato. Número, data de início, vencimento, produtos, condições, renovação automática. Direção: ERP é fonte (ou sistema de contratos quando separado). CRM consome para sucesso do cliente, expansão e renovação.

Oportunidade e atividade. Pipeline, etapa, valor previsto, atividade. Direção: CRM é fonte da verdade. ERP raramente precisa desse dado, exceto em previsão de receita financeira de longo prazo.

Cada categoria tem direção definida, cadência (tempo real, lote curto, diário) e granularidade. Definir isso antes de configurar evita conflitos posteriores.

Quem manda em quê: a regra crítica

A pergunta de "quem é fonte da verdade para cada dado" é a discussão mais importante de qualquer projeto de integração. Sem essa definição, o sistema vira loop infinito de sobrescrita — CRM atualiza, ERP sobrescreve, CRM atualiza de novo.

Regra prática:

• Dado fiscal/financeiro: ERP. Razão social oficial, endereço fiscal, situação cadastral, faturamento, recebimento, contrato — tudo gerenciado no ERP. CRM lê, não escreve.
• Pipeline comercial: CRM. Oportunidade, etapa, valor previsto, atividade do vendedor, próxima ação — tudo gerenciado no CRM. ERP raramente precisa dessas informações.
• Catálogo de produto: ERP. SKU, descrição oficial, preço de tabela, estoque. CRM consome.
• Contato (pessoa física dentro de empresa): CRM. Nome, cargo, telefone direto, e-mail, histórico de interação. ERP raramente precisa.
• Cliente (entidade): Híbrido. Criação inicial pode acontecer no CRM (lead vira conta) e migrar para ERP no fechamento; ou criação direta no ERP em B2B com longo ciclo. Regra deve ser definida e respeitada.

Em caso de conflito, prevalece a fonte definida — outro sistema é atualizado para refletir, não o contrário. Implementação de "quem ganhou último" (last write wins) sem regra clara é fonte de problema garantido.

Arquiteturas de integração

Quatro arquiteturas dominam o cenário, em ordem crescente de complexidade e capacidade:

Ponto-a-ponto (point-to-point). Cada sistema conecta diretamente com cada outro sistema. Simples para integração inicial entre dois sistemas. Vira pesadelo quando há 5+ sistemas — combinações crescem exponencialmente, manutenção fica inviável.

Hub-and-spoke (iPaaS). Plataforma central de integração (Workato, Boomi, MuleSoft, Zapier Plus, Make) recebe e distribui dados entre sistemas. Cada sistema conecta apenas com o iPaaS. Manutenção concentrada, escalável, recomendada para média empresa. Custos típicos: R$ 3.000-20.000/mês conforme volume.

Barramento (Enterprise Service Bus — ESB). Arquitetura corporativa onde todos os sistemas se comunicam por mensagens via barramento. Maior controle, governança, monitoramento. Comum em grandes empresas com TI corporativo robusto. Custo alto, complexidade alta.

Arquitetura baseada em eventos (event-driven). Sistemas publicam eventos (pedido fechado, cliente atualizado, fatura paga) em fila/streaming (Kafka, RabbitMQ, AWS EventBridge). Outros sistemas consomem eventos relevantes. Permite tempo real verdadeiro, escala alta, desacoplamento. Padrão moderno para arquiteturas em nuvem nativas.

A escolha não é apenas técnica — depende de volume de dados, número de sistemas, maturidade de TI, orçamento e cultura. Pequenas operações se viram com ponto-a-ponto ou aplicativo nativo; médias empresas tipicamente vão para iPaaS; grandes empresas combinam barramento ou eventos com governança formal.

ERPs comuns no mercado brasileiro

O cenário de ERPs no Brasil é diverso, com diferenças importantes em integração:

SAP. Líder em grande empresa global. Possui ecossistema robusto de integração — APIs SOAP e REST, conectores via SAP Cloud Platform Integration, ecossistema de parceiros. Salesforce + SAP é integração clássica em grande empresa.

Oracle (incluindo NetSuite). Forte em grande empresa global e em médio-alto porte. NetSuite é versão em nuvem multitenant com API REST e SuiteScript. Integração nativa com Salesforce via conectores. Oracle Cloud com Oracle CX (CRM próprio) tem integração nativa.

TOTVS (Protheus, RM, Datasul, Fluig). Líder em médio porte e grande empresa brasileira. TOTVS Connect e parceiros oferecem integração com Salesforce, Dynamics, HubSpot. Particularidades fiscais brasileiras são bem cobertas.

Sankhya. Forte em médio porte brasileiro. API moderna, conectores prontos para principais CRMs.

Senior. Médio porte, especialmente em RH e folha. Integração com CRM via API.

Omie, ContaAzul, Bling. Líderes em pequeno porte brasileiro. Aplicativos nativos prontos para principais CRMs brasileiros (RD Station, Pipedrive, HubSpot).

Combinações típicas:

• SAP + Salesforce (grande empresa global)
• TOTVS + Salesforce ou HubSpot (médio e grande porte brasileiro)
• NetSuite + Salesforce ou HubSpot (médio-alto porte com operação internacional)
• Omie + Pipedrive ou RD Station (pequeno e médio porte brasileiro)
• Bling + RD Station (pequeno porte brasileiro)
• Conta Azul + Pipedrive (pequeno porte)

CNPJ/CPF como chave: cuidados de formatação

Em operação brasileira, CNPJ (B2B) ou CPF (B2C) é a chave natural de matching entre sistemas. Mas formatação inconsistente causa problemas reais:

Com ou sem máscara. CRM pode armazenar "12.345.678/0001-95"; ERP pode armazenar "12345678000195". Sem normalização (remover pontos, traços e barra), são tratados como CNPJs diferentes — cliente vira duplicado.

Espaços extras. Espaço antes ou depois do número quebra matching. Boa prática: aplicar trim em todos os dados antes de comparar.

Zeros à esquerda. Sistemas que tratam CNPJ/CPF como número podem perder zeros à esquerda. CNPJ "00.123.456/0001-90" pode virar "12345600019". Boa prática: armazenar como string, nunca como número.

CNPJ inválido ou inexistente. Validação de dígito verificador antes de salvar evita registros lixo. Verificação na Receita Federal (Receita WS, Speedio, outras) confirma situação cadastral.

Pessoa física sem CPF. Em B2C, cliente pode comprar sem informar CPF. Identidade alternativa (e-mail, telefone) precisa ser definida e respeitada.

Operações maduras aplicam normalização e validação na entrada — antes do dado entrar em qualquer sistema. Tentar corrigir depois é custo alto.

Cliente bloqueado e inadimplente: como vendas e marketing veem

Caso de uso clássico onde integração CRM-ERP rende muito retorno: bloqueio comercial por inadimplência.

Cliente em atraso financeiro no ERP recebe status que sincroniza para o CRM. Casos típicos:

Atraso curto (1-15 dias). Sinal de alerta visível ao vendedor. Marketing pode pausar campanha promocional. Sucesso do cliente é avisado.

Atraso médio (16-60 dias). Vendedor não pode abrir nova oportunidade sem autorização. Marketing suspende automação ativa. Cobrança aciona.

Atraso longo (60+ dias). Bloqueio comercial total. Cliente em recuperação ou em renegociação. Apenas área financeira/jurídica interage.

Sem integração, vendedor liga para cliente inadimplente, marketing dispara campanha promocional, sucesso oferece expansão — tudo sem saber que o cliente está em conflito financeiro. Resultado: irritação do cliente, conflito interno entre áreas, dano à relação.

Com integração, sinal de status circula entre áreas em horas — todos veem a mesma realidade.

Tempo real versus lote: o trade-off

Nem todo dado precisa de tempo real. Decisão entre frequência depende do caso de uso:

Tempo real (segundos). Casos que exigem reação imediata: pedido fechado no ERP, pagamento confirmado, status de inadimplência mudou, contrato cancelado. Custa mais em infraestrutura e complexidade, mas é essencial onde aplicável.

Tempo quase real (minutos). Casos com tolerância pequena: nova fatura emitida, ajuste de valor, mudança de endereço. iPaaS típico opera nessa faixa.

Lote curto (1-4 horas). Casos com tolerância moderada: atualização de catálogo, sincronização de cliente, snapshot de pipeline.

Lote diário. Casos com baixa volatilidade: relatório histórico, snapshot para BI, arquivamento.

Tentar fazer tudo em tempo real aumenta custo desproporcionalmente. Definir o que cada caso exige — e respeitar — mantém arquitetura sustentável.

Erros comuns

Integração que duplica cliente. Falta de regra de matching por CNPJ/CPF (ou matching com formatação inconsistente) cria duas entidades para o mesmo cliente. Vira problema crescente — relatórios distorcidos, comunicação fragmentada, vendedor confuso.

Pedido sem ligação à oportunidade. Pedido fechado no ERP sem referência à oportunidade no CRM que o originou. Atribuição de receita fica impossível, análise de previsão versus realização vira manual.

Sobrescrita em loop. CRM atualiza dado, ERP sobrescreve, CRM atualiza de novo, ERP sobrescreve. Acontece quando regra de fonte da verdade não foi definida ou não é respeitada. Em casos graves, sistema entra em loop infinito.

Cliente criado no ERP sem chegar ao CRM. Faturamento cria cliente direto no ERP (sem passar pelo CRM). Vendedor não vê histórico, marketing não tem o contato em nenhuma campanha. Resolve com sincronização ERP-para-CRM como regra.

Marketing acionando inadimplente. Campanha promocional disparada para cliente em atraso financeiro grave. Constrangimento. Resolve com sincronização de status financeiro e regra de supressão automática.

Integração configurada uma vez, esquecida. Após implementação, ninguém monitora — falhas silenciosas acumulam, dados ficam desatualizados. Resolve com monitoramento de saúde da integração (alertas para falhas, dashboard de volume sincronizado).

Quantidade excessiva de campos sincronizados. "Para garantir, sincroniza tudo". Resultado: 80% dos campos nunca são consumidos, mas custam ciclo de processamento e complexidade de manutenção. Resolve com definição de quais campos cada caso de uso realmente precisa.