Como comparar duas planilhas sem falsos positivos: códigos, duplicidades e valores

Comparar duas planilhas parece uma tarefa simples até a primeira divergência inexplicável. Um código aparece em uma base e “some” na outra; o valor 12,30 é tratado como diferente de 12.3; um identificador perde os zeros à esquerda; duas linhas legítimas viram uma só porque a chave escolhida não era única. O problema raramente está no botão de comparar. Ele está na preparação.

Este guia apresenta um método que pode ser auditado do início ao fim. A ideia é transformar uma comparação vaga — “veja o que mudou” — em perguntas menores e verificáveis: quais colunas identificam o registro, como os dados devem ser normalizados, o que conta como correspondência, como lidar com duplicidades e qual tolerância é aceitável para valores.

Comece definindo o que uma linha representa

Antes de abrir qualquer fórmula, escreva uma frase curta: “cada linha representa…”. Pode ser um produto em um fornecedor, uma cobrança em uma competência, uma peça em um estoque ou um atendimento em uma data. Essa frase revela a granularidade da base. Se você não consegue completá-la sem usar “depende”, provavelmente ainda não encontrou a chave correta.

Uma chave é o conjunto mínimo de campos que identifica uma ocorrência. Um código de produto pode bastar em um catálogo simples. Em uma tabela com preços por fornecedor, talvez a chave seja código + fornecedor. Se o preço varia por vigência, a data inicial também pode fazer parte da identidade. Usar somente o código nesse último cenário cria uma comparação ambígua: o sistema encontra várias linhas possíveis e escolhe uma sem que você perceba.

Faça um contrato de comparação

O contrato de comparação é uma pequena especificação escrita antes do processamento. Ele evita decisões improvisadas no meio do trabalho. Registre pelo menos:

• Base principal: qual arquivo define o universo de linhas que você espera manter.
• Chave: uma ou mais colunas usadas para localizar a linha correspondente.
• Campos comparados: preço, descrição, status, unidade, vigência ou outro atributo.
• Normalização: regras aplicadas antes da busca, como remover espaços laterais ou preservar zeros.
• Tolerância: quando duas representações numéricas devem ser consideradas equivalentes.
• Destino: o que será apenas sinalizado e o que poderá ser atualizado.

Esse documento pode ter poucas linhas, mas precisa acompanhar o resultado. Sem ele, uma marcação amarela não explica se o problema foi código diferente, ausência de chave ou alteração de preço.

Texto, número ou identificador? A escolha muda tudo

Uma coluna visualmente numérica nem sempre representa quantidade. CEP, CPF, matrícula, código de serviço e número de pedido são identificadores. Neles, o dígito zero à esquerda possui significado. O código 00127 não deve virar 127 por conveniência.

Classifique cada coluna antes de comparar. Texto deve permanecer texto; datas devem ser interpretadas com um formato conhecido; valores monetários precisam de separador decimal definido; identificadores devem ser preservados literalmente. A documentação do Power Query destaca que tipos de dados estruturam os valores de uma coluna. Na prática, isso significa que uma transformação de tipo aplicada cedo demais pode alterar o dado antes da comparação.

Campo	Tipo recomendado	Risco comum
Código 00127	Texto	Perder zeros à esquerda
Valor 1.234,56	Decimal com localidade definida	Ler como 1,23456 ou como texto
Data 03/04/2026	Data com convenção explícita	Confundir 3 de abril com 4 de março
Descrição	Texto Unicode	Espaços invisíveis e acentos corrompidos

Normalize sem destruir evidências

Normalizar não significa “limpar tudo”. Significa criar uma versão comparável preservando o valor original. Mantenha duas colunas quando necessário: codigo_original e codigo_normalizado. Assim você consegue rastrear por que duas linhas foram consideradas equivalentes.

Para textos, operações seguras incluem remover espaços no início e no fim, substituir sequências de espaços internos quando elas não forem significativas e uniformizar quebras de linha. Converter tudo para maiúsculas pode ajudar em chaves que não diferenciam caixa, mas não deve substituir o dado apresentado ao usuário.

Para identificadores, não remova pontuação ou zeros sem regra de negócio. Se uma base traz 000123 e outra traz 123, primeiro confirme se ambas usam o mesmo domínio e o mesmo comprimento oficial. Completar zeros apenas para “fazer bater” pode criar correspondências incorretas.

Valide a unicidade da chave antes do cruzamento

Uma chave duplicada muda a natureza da análise. Se o código 501 aparece três vezes na base A e duas vezes na base B, um PROCV tradicional retorna apenas uma ocorrência e esconde as demais. O resultado parece limpo, mas não é auditável.

Conte quantas vezes cada chave aparece em cada lado. Separe três situações:

1. 1 para 1: correspondência direta; é o cenário ideal.
2. 1 para muitos: a chave está incompleta ou existe uma relação legítima que precisa de outra dimensão.
3. Muitos para muitos: a comparação exige uma chave composta, uma regra temporal ou pareamento por sequência.

Não escolha silenciosamente a primeira linha. Leve as ocorrências para o relatório e peça uma regra. Se a data de vigência diferencia registros, ela pode entrar na chave; se o sistema permite versões, talvez seja necessário selecionar a mais recente ou a mais antiga com justificativa.

Use o tipo de junção correto

Ferramentas de dados tratam a comparação como uma junção entre tabelas. A documentação oficial do Power Query descreve que a mesclagem usa uma ou várias colunas e oferece diferentes tipos de junção. A escolha responde a perguntas distintas:

• Inner join: mostra somente chaves presentes nos dois lados.
• Left join: mantém todas as linhas da base principal e anexa o que encontrar na referência.
• Full outer join: conserva tudo dos dois lados, ideal para detectar inclusões e exclusões.
• Left anti join: mostra o que existe na base A e não existe na B.
• Right anti join: mostra o inverso.

Para uma auditoria completa, a junção externa completa costuma ser a melhor matriz. Depois você classifica o estado usando a presença da chave em cada lado.

Compare valores sem inventar precisão

Valores monetários merecem uma regra explícita. Não arredonde toda a base apenas para esconder diferenças. Guarde o valor original e crie um valor de comparação. Se a regra diz que qualquer valor positivo abaixo de R$ 0,01 deve ser considerado R$ 0,01, aplique apenas essa exceção. Fora dela, preserve as casas disponíveis.

Também decida se a comparação será absoluta ou relativa. Uma diferença de R$ 0,01 pode ser irrelevante em R$ 10.000 e importante em R$ 0,02. Em contratos e tabelas oficiais, a tolerância precisa vir da regra aplicável, não de uma preferência técnica.

Evite números de ponto flutuante quando a igualdade exata é necessária. Sistemas binários podem representar alguns decimais de forma aproximada. Em planilhas, bancos e linguagens, prefira tipos decimais adequados para dinheiro ou compare valores inteiros na menor unidade definida, como centavos, quando isso respeitar a precisão de origem.

Não confunda ausência com conflito

“Não bateu” é um diagnóstico pobre. Separe pelo menos:

• chave encontrada, valor igual;
• chave encontrada, valor diferente;
• parte da chave corresponde, outra parte diverge;
• nenhuma chave correspondente;
• chave vazia;
• chave duplicada;
• tipo ou formato inválido.

Essa taxonomia torna as cores úteis. Verde pode significar validado, amarelo conflito localizado e vermelho ausência completa. A cor nunca deve ser a única informação: inclua uma coluna textual de motivo para acessibilidade e auditoria.

Um exemplo reproduzível

Imagine duas tabelas de materiais. A base atual possui UV, TUSS e valor_atual. A base histórica possui CDSERVICO, CDSERVICO_REFER e VLCUSTO_TOTAL. O contrato determina que UV e TUSS formam a chave; somente quando ambos correspondem o valor pode ser atualizado.

1. Importe todos os códigos como texto.
2. Crie colunas normalizadas sem apagar as originais.
3. Conte ocorrências da chave composta em cada base.
4. Separe duplicidades antes da junção.
5. Faça uma junção externa completa por UV + TUSS.
6. Classifique presença e conflitos de chave.
7. Somente para correspondências 1 para 1, aplique a regra de valor.
8. Gere um relatório com estado, motivo, valor anterior e valor proposto.

O processo evita que um TUSS correto ligado ao UV errado atualize a linha indevida. Também impede que uma ausência completa seja apresentada como simples mudança de preço.

Quando usar Excel, Power Query ou uma ferramenta dedicada

Excel funciona bem para conferências pequenas e transparentes, especialmente quando outra pessoa precisa revisar as fórmulas. Power Query é superior quando a preparação deve ser repetida: ele registra passos, tipos e junções. Para arquivos maiores ou rotinas recorrentes, uma ferramenta dedicada reduz o risco de fórmulas quebradas ao inserir linhas.

No Comparador de Planilhas do IATechNerds, use o mesmo raciocínio: escolha as chaves, defina campos de comparação e examine duplicidades antes de aceitar resultados. A ferramenta acelera o trabalho; o contrato de comparação continua sendo sua defesa contra decisões erradas.

Como documentar a comparação para auditoria

Um resultado confiável precisa vir acompanhado de contexto suficiente para ser repetido. Salve um pequeno manifesto com o nome dos arquivos, data da execução, quantidade de linhas de entrada, colunas usadas como chave, transformações aplicadas e versão da regra de negócio. Se os arquivos forem sensíveis, o manifesto pode registrar apenas identificadores internos e hashes, sem copiar os dados.

Inclua também três contagens de controle: chaves únicas em cada origem, chaves duplicadas e linhas sem correspondência. Em seguida, registre quantas linhas foram classificadas como iguais, alteradas, incluídas, removidas ou bloqueadas por ambiguidade. Essas somas funcionam como uma prova de sanidade: se não fecharem com o universo esperado, a análise ainda não terminou.

Para mudanças de valor, separe recomendação de aplicação. O relatório pode sugerir um novo valor, mas a coluna aplicar deve depender de condições explícitas, como chave única, tipo válido e diferença dentro de um limite aprovado. Isso impede que uma regra de preenchimento transforme uma correspondência duvidosa em atualização automática.

Por fim, guarde uma amostra de evidências. Selecione casos de cada estado e inclua a chave original, os campos comparados e o motivo da classificação. Não é necessário exportar todas as colunas da base; escolha as que permitem revisar a decisão. Uma segunda pessoa deve conseguir abrir o relatório, localizar a linha na origem e confirmar o raciocínio sem depender de explicações verbais.

Nomeie o arquivo final de forma inequívoca e não sobrescreva a base recebida. Uma convenção com projeto, data e versão evita que alguém use uma prévia como resultado aprovado. Quando houver correção, anexe o motivo e repita as contagens de controle.

Checklist antes de entregar

• A granularidade de cada base foi descrita?
• A chave é realmente única nos dois lados?
• Identificadores foram mantidos como texto?
• A localidade de datas e decimais está definida?
• As regras de normalização estão registradas?
• Ausências e conflitos possuem estados diferentes?
• O relatório preserva valores originais?
• Existe uma coluna de motivo além das cores?
• Uma amostra foi conferida manualmente?
• O arquivo original permanece intacto?

Conclusão

A melhor comparação não é a que encontra mais diferenças. É a que consegue explicar cada diferença sem adivinhação. Defina a linha, construa a chave, preserve os tipos, isole duplicidades, escolha a junção adequada e aplique regras de valor somente depois de confirmar a identidade.

Esse método demora alguns minutos a mais no início e economiza horas de revisão no final. Mais importante: produz um resultado que outra pessoa pode repetir e chegar à mesma conclusão.

Fontes e documentação

• Microsoft Learn — visão geral da mesclagem de consultas no Power Query
• Microsoft Learn — tipos de dados no Power Query