# Sincronização de cadastros entre sistemas sem duplicidade

> Cliente com três cadastros no CRM, no ERP e na loja? Veja como definir o sistema dono de cada dado, sincronizar sem duplicar e limpar a base atual.

Fonte: https://pervian.tech/blog/sincronizacao-de-cadastros-entre-sistemas · Pervian Tech · publicado em 2026-10-01

O vendedor cadastra o cliente no CRM como "Mercado Bom Preço". O financeiro, quando a primeira nota sai, cria no ERP "MERCADO BOM PRECO LTDA". O suporte, que usa outra ferramenta, abre chamado para "Bom Preço - Filial Centro". São três cadastros da mesma empresa, com três telefones, dois endereços de cobrança e nenhum vínculo entre eles.

Com produto e fornecedor acontece igual. O mesmo parafuso tem um código no ERP, outro na loja virtual e um terceiro na planilha de compras. Na hora de responder perguntas simples, como quanto esse cliente comprou no ano ou quantos chamados ele abriu, alguém precisa cruzar planilhas à mão e torcer para o nome ter sido digitado igual.

A resposta curta para a sincronização de cadastros entre sistemas é esta: **para cada cadastro, escolha um único sistema dono; crie uma chave que identifique o registro em todos os sistemas; faça os demais receberem o dado em vez de criá-lo; e limpe as duplicidades antigas antes de ligar a sincronização**. O restante do texto mostra como fazer cada uma dessas etapas sem trocar uma bagunça por outra.

## Sintomas: o mesmo cliente com três cadastros

Cadastro duplicado raramente aparece como um problema único. Ele se espalha em pequenas fricções que viram rotina:

- **[Relatório que não fecha](https://pervian.tech/blog/qualidade-de-dados-relatorios-nao-batem).** O faturamento por cliente no ERP não bate com a carteira do CRM, porque metade das vendas está num cadastro e metade em outro.
- **Cobrança no endereço errado.** O cliente mudou de endereço, avisou o comercial, e o boleto continuou indo para o endereço antigo que estava no ERP.
- **Produto com três nomes.** O comprador pede reposição de um item que já está no estoque com outro código, e a empresa compra o que já tem.
- **Fornecedor duplicado no contas a pagar.** O mesmo fornecedor aparece com dois cadastros e dados bancários diferentes, o que abre espaço para pagamento em duplicidade.
- **Retrabalho.** Toda venda nova exige digitar o cliente duas ou três vezes.

Se dois ou três desses sinais aparecem com frequência, o problema não está nas pessoas que cadastram. Está na ausência de regra sobre quem cadastra o quê, e onde.

## Por que acontece quando a empresa cresce

Na empresa pequena, existe um sistema e uma pessoa que cadastra. Conforme a operação cresce, cada área adota a sua ferramenta: CRM no comercial, ERP no fiscal e financeiro, plataforma de loja no e-commerce (como [Shopify, Nuvemshop ou VTEX](https://pervian.tech/blog/shopify-nuvemshop-ou-vtex)), sistema de chamados no suporte. Cada uma tem sua tela de cadastro e funciona bem sozinha. O problema nasce no encaixe:

- **Cada sistema exige campos diferentes.** O CRM aceita cliente só com nome e telefone; o ERP exige CNPJ, inscrição estadual e endereço completo. O comercial cria rápido no CRM, o financeiro cria de novo no ERP.
- **Integrações feitas aos pedaços.** Uma integração copia clientes do CRM para o ERP, outra copia do ERP para a loja, e nenhuma verifica se o registro já existe do outro lado.
- **Sem chave comum.** Cada sistema identifica o registro pelo seu código interno. Sem um identificador compartilhado, a única forma de cruzar é por nome, e nome escrito à mão nunca é igual.
- **Importações em massa.** Uma planilha de clientes de uma feira é carregada inteira, sem checar o que já existia.

Nenhum desses pontos se resolve trocando de ferramenta. Resolve-se com desenho.

## Sistema dono do dado: quem manda em cada cadastro

O passo mais importante, e o mais adiado, é decidir por escrito **qual sistema é a fonte da verdade de cada cadastro e, às vezes, de cada grupo de campos**. Sem essa decisão, dois sistemas editam o mesmo dado e a sincronização vira cabo de guerra: um sobrescreve o outro e ninguém sabe qual versão ficou.

Um mapa típico, como ponto de partida para uma empresa com ERP, CRM e loja virtual:

| Cadastro ou grupo de campos | Sistema dono típico | Quem recebe | Observação |
|---|---|---|---|
| Cliente: dados fiscais (CNPJ ou CPF, razão social, inscrição estadual, endereço de faturamento) | ERP | CRM, loja, suporte | Quem emite a nota precisa garantir o dado fiscal |
| Cliente: relacionamento (contatos, responsável comercial, estágio, origem) | CRM | ERP, quando necessário | O comercial mantém o que conhece melhor |
| Produto: dados técnicos e fiscais (código, NCM, unidade, peso) | ERP | Loja, CRM, aplicativo de campo | Um único código de produto em todos os sistemas |
| Produto: conteúdo de vitrine (fotos, descrição comercial) | Plataforma da loja | Fica na loja | Não deve ser sobrescrito pelo ERP |
| Fornecedor: dados cadastrais e bancários | ERP ou sistema financeiro | Compras, [portal de fornecedores](https://pervian.tech/blog/portal-do-fornecedor) | Alteração bancária com aprovação |
| Tabela de preço | ERP | Loja, CRM, portal de pedidos | Mudança registrada com autor e data |

Três decisões costumam gerar discussão e merecem atenção:

**O dono pode ser por campo, não por registro inteiro.** O cliente nasce no CRM quando ainda é oportunidade, mas os dados fiscais passam a ser do ERP quando a primeira venda é faturada. Isso é legítimo, desde que cada campo tenha um único dono em cada momento.

**Quem não é dono não edita.** No sistema que apenas recebe, o campo fica somente leitura, ou a alteração vira uma solicitação para o dono. Deixar editável "só por precaução" é o que recria a duplicidade.

**Cadastro novo nasce num lugar só.** Se o vendedor cadastra o cliente no CRM, o ERP recebe esse cliente pela integração em vez de o financeiro criar outro.

Quando o CRM atual não comporta essas regras, ou quando ele é exatamente a fonte da bagunça, vale ler [quando um CRM sob medida vale a pena](https://pervian.tech/blog/crm-sob-medida-quando-vale-a-pena).

## Sincronização em tempo real ou em lotes

Definido o dono, falta decidir **como e quando** o dado anda. Não existe uma resposta única; existe a frequência que o processo exige.

| Forma | Como funciona | Quando faz sentido | Cuidado |
|---|---|---|---|
| Evento (quase em tempo real) | Cada alteração no sistema dono dispara uma mensagem para os demais | Cliente criado no CRM que precisa faturar no mesmo dia; preço e produto na loja | Precisa de fila e reprocessamento quando o destino está fora do ar |
| Lote incremental | De tempos em tempos, o sistema busca só o que mudou desde a última leitura | Sistemas que não emitem eventos; volume alto com tolerância a atraso | O intervalo define quanto tempo o dado fica velho |
| Carga completa | Todo o cadastro é reenviado periodicamente | Conciliação noturna; tabelas pequenas | Não deve ser o mecanismo principal em cadastro grande |

Na prática, o desenho mais robusto combina os dois: **eventos para manter o dado atualizado e uma conciliação periódica para pegar o que escapou**. A conciliação compara os cadastros dos dois lados e aponta divergências, em vez de sobrescrever tudo às cegas.

Em qualquer forma, três regras valem: receber a mesma mensagem duas vezes não pode criar dois clientes (idempotência); uma alteração antiga que chega atrasada precisa ser descartada; e cliente sem CNPJ válido ou produto sem NCM vai para uma fila de exceções que a operação corrige e reprocessa. Os princípios gerais, como API oficial, filas e monitoramento, estão em [como integrar seu sistema com o ERP sem dor de cabeça](https://pervian.tech/blog/como-integrar-seu-sistema-com-o-erp).

## Chaves, de-para e identificação de duplicados

Sincronizar exige que cada sistema saiba que o "cliente 4512" do ERP é o mesmo que o "contato 98" do CRM. Há duas formas de garantir isso.

### Chave natural

É um dado do mundo real que identifica o registro: **CNPJ ou CPF** para clientes e fornecedores, **código de barras (GTIN)** para produtos que o têm. Funciona bem quando o dado é obrigatório e validado na entrada. Tem limites:

- Um mesmo CNPJ raiz pode ter [várias filiais](https://pervian.tech/blog/sistema-multiempresa-e-multifilial), e a empresa precisa decidir se cada filial é um cadastro ou um endereço do mesmo cliente.
- Pessoa física às vezes é cadastrada sem CPF numa etapa inicial de venda.
- Produto fabricado ou montado internamente não tem GTIN.
- O formato do campo precisa acompanhar mudanças de regra. O CNPJ, por exemplo, passa a admitir letras em novas inscrições; vale confirmar com o contador e o fornecedor do ERP que os sistemas aceitam o novo formato.

### Chave própria e tabela de de-para

Quando a chave natural não basta, cria-se um **identificador único do cadastro**, gerado pelo sistema dono, e uma **tabela de de-para** que guarda, para cada registro, o código correspondente em cada sistema. É essa tabela que permite atualizar o cliente certo no CRM quando o ERP altera o endereço.

| Identificador mestre | Código no ERP | Código no CRM | Código na loja |
|---|---|---|---|
| CLI-000731 | 4512 | 98 | 30177 |

A tabela de de-para é parte da integração, não uma planilha à parte, e precisa de uma tela para a operação corrigir vínculos.

### Como encontrar duplicados

Para os cadastros que já existem, a identificação combina regras exatas e aproximadas:

- **Mesma chave natural** (mesmo CNPJ completo, mesmo GTIN): duplicado certo.
- **Nome normalizado** (sem acento, sem "LTDA" e "ME", sem pontuação e espaços extras) igual ou muito parecido, combinado com mesmo CEP, telefone ou e-mail: duplicado provável.
- **Apenas nome parecido**: candidato, que precisa de revisão humana.

A regra prática é **fundir automaticamente só o que é certo** e mandar o provável para revisão. Fusão agressiva junta empresas diferentes com nomes parecidos, e desfazer isso custa mais trabalho do que revisar.

## Limpeza inicial dos cadastros existentes

Ligar a sincronização sobre uma base suja só espalha a sujeira mais rápido. A limpeza vem antes, e segue um roteiro:

1. **Extraia os cadastros de todos os sistemas** para um ambiente separado, sem mexer na produção.
2. **Padronize formatos**: documentos, CEP, telefone, nomes e unidades de medida no mesmo padrão.
3. **Valide o que dá para validar**: dígito verificador de CNPJ e CPF, CEP existente, e-mail bem formado.
4. **Agrupe duplicados** com as regras de chave e semelhança, separando os certos dos prováveis.
5. **Escolha o registro sobrevivente** de cada grupo e defina, campo a campo, de onde vem o valor final: endereço fiscal do ERP, contato do CRM, o telefone mais recente.
6. **Revise os casos prováveis** com quem conhece os clientes e produtos, em lotes curtos e com prazo.
7. **Preserve o histórico.** Pedidos, notas e chamados ligados aos cadastros eliminados precisam apontar para o sobrevivente. No ERP, registros com movimento fiscal em geral não são apagados: ficam inativos e vinculados ao cadastro que permanece.
8. **Monte a tabela de de-para inicial** com o resultado e só então ligue a sincronização.

Contatos e clientes pessoa física são dados pessoais, e a LGPD (Lei 13.709/2018) vale para a limpeza: a cópia de trabalho precisa de acesso restrito e prazo para ser descartada. Retenção e base legal devem ser validadas com o jurídico.

O prazo varia com o volume e com quantos casos pedem revisão humana; em geral é uma fase de semanas, não de dias, e merece responsável e data. Comece por um cadastro só, geralmente cliente ou produto: entrega resultado mais cedo e ensina as regras que vão valer para os outros.

## Regras para não voltar à bagunça

Base limpa sem regra volta a sujar. O que mantém os cadastros em ordem:

- **Ponto único de criação.** Cada cadastro nasce no sistema dono. Nos demais, o botão "novo cliente" some ou leva ao fluxo do dono.
- **Busca antes de criar.** A tela de cadastro procura pelo documento e por nome parecido antes de permitir um registro novo, e mostra o que já existe.
- **Validação na entrada.** Documento com dígito verificador, CEP consultado, campos obrigatórios coerentes com o que o ERP exige para faturar.
- **[Alteração sensível com aprovação](https://pervian.tech/blog/workflow-de-aprovacao-por-alcada).** Troca de dados bancários de fornecedor e mudança de razão social passam por uma segunda pessoa e ficam registradas.
- **Importação em massa pelo mesmo crivo.** Planilha de feira ou de parceiro passa pela deduplicação antes de entrar.
- **Indicadores de qualidade.** Duplicados suspeitos, cadastros incompletos e tamanho da fila de exceções. Se sobem, alguma regra está sendo contornada.
- **Responsável pelo dado.** Cada cadastro tem uma área responsável pela qualidade, com autoridade para corrigir e para dizer não.

Para quem vende online, o cadastro de produto tem particularidades próprias de estoque, preço e conteúdo de vitrine, tratadas em [integração entre ERP e e-commerce sem planilha no meio](https://pervian.tech/blog/integracao-erp-e-commerce).

## Perguntas frequentes

### O que são dados mestres?

Dados mestres são os cadastros que vários sistemas da empresa compartilham, como clientes, produtos, fornecedores e tabelas de preço. Eles diferem das transações, como pedidos e notas, que se apoiam neles. A gestão de dados mestres define qual sistema é dono de cada cadastro, como os demais recebem o dado e como evitar duplicidades.

### Dá para usar o CNPJ como chave do cliente em todos os sistemas?

Em parte. O CNPJ funciona bem como chave natural quando é obrigatório e validado na entrada, mas tem limites: filiais compartilham o mesmo CNPJ raiz, pessoa física às vezes é cadastrada sem CPF e o CNPJ passa a admitir letras em novas inscrições. Por isso, muitas empresas usam também um identificador próprio com tabela de de-para.

### Como juntar cadastros duplicados sem perder o histórico?

Escolhendo um registro sobrevivente em cada grupo de duplicados e apontando para ele os pedidos, notas e chamados dos cadastros eliminados. No ERP, registros com movimento fiscal em geral não são apagados: ficam inativos e vinculados ao cadastro que permanece. A fusão automática deve se limitar aos duplicados certos, com revisão humana nos prováveis.

### Quanto tempo leva a limpeza de uma base de cadastros?

Depende do volume de registros e de quantos casos pedem revisão humana. Em geral, a limpeza de uma base de cadastros é uma fase de semanas, não de dias, e merece responsável e data. Começar por um único cadastro, geralmente cliente ou produto, entrega resultado mais cedo e define as regras que valerão para os demais.

## Como a Pervian Tech trabalha dados mestres

Na Pervian Tech, começamos pelo diagnóstico: quais sistemas guardam cada cadastro, o que cada um expõe por API e onde as duplicidades aparecem hoje. O diagnóstico inicial é gratuito e termina com o mapa de sistema dono, chaves e fluxos, que serve de base para qualquer caminho que a empresa escolha.

A partir daí, desenhamos a solução sob medida: limpeza da base atual com revisão da sua equipe nos casos duvidosos, tabela de de-para, sincronização por eventos com fila, reprocessamento e conciliação, e telas para a operação tratar exceções sem depender de desenvolvedor. Quando os sistemas atuais atendem, integramos o que já existe; quando não, construímos só a camada que falta. Esse desenho é trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software), e as entregas típicas estão na página de [integração de sistemas](https://pervian.tech/solucoes/integracao-de-sistemas). Outros textos sobre o tema estão na categoria [integrações](https://pervian.tech/blog/categoria/integracoes).

O cronograma é definido em fases depois do diagnóstico, e o investimento é sob consulta, porque depende do número de sistemas, do volume de cadastros e do estado da base. Se a sua empresa ainda discute qual planilha tem o cliente certo, [conte como seus cadastros funcionam hoje](https://pervian.tech/#contato).