Guia BA

Dois Sistemas Mostram Números Diferentes

Um guia prático de BA para investigar divergências de dados.

Surya · 8 de agosto de 2026 · 4 min de leitura · 14 práticas

Dados

Para Business Analysts investigando divergências de dados, BAs apoiando funções de reconciliação ou controle, Qualquer um que recebeu "qual número está certo" sem mais nenhum contexto e Product Owners triando um ticket de qualidade de dados.

Sistema A: 1.248 operações. Sistema B: 1.231 operações. Alguém joga os dois prints no Teams e pergunta: "qual dos dois está errado?" Talvez nenhum. Números diferentes costumam vir de definições, tempos, populações, filtros ou estados de processamento diferentes — não de um dos sistemas estar quebrado. O primeiro trabalho não é achar o número errado. O primeiro trabalho é garantir que você está realmente comparando a mesma coisa.

01

Passo 01

Confirme a métrica

"Operações" sozinho ainda não é uma definição compartilhada.

Resumo

Operação?
Ordem?
Execução?
Registro?
Bruto ou líquido?

Por que isso ajuda

Dois times podem estar certos e mesmo assim discordar, se um está contando ordens e o outro está contando execuções.

02

Passo 02

Confirme a janela de tempo

O mesmo dia pode significar três coisas diferentes para três sistemas diferentes.

Resumo

Data de negócio, ou data de calendário?
Qual fuso horário?
Qual é o corte?
A que horas o batch realmente roda?

Por que isso ajuda

Uma operação registrada às 23h58 pode cair em "hoje" ou "amanhã" dependendo de qual dessas quatro respostas o sistema usa.

03

Passo 03

Confirme a população

Antes de comparar contagens, confirme que os dois lados estão contando a mesma fatia do mundo.

Resumo

Mercado?
Região?
Cliente?
Produto?
Praça?
Status?

Por que isso ajuda

Um sistema restrito a EMEA e outro global nunca vão bater, e nenhum dos dois está com defeito.

04

Passo 04

Confirme a origem

Nem todo número vem do mesmo lugar, mesmo quando a tela parece igual.

Um relatório em cache que fica atrasado em relação ao banco de produção, por definição do sistema, não é um bug. Vale a pena saber disso antes de alguém passar a tarde perseguindo isso como se fosse um.

Resumo

Banco de dados em produção?
API?
Relatório agendado?
Cache?
Data warehouse?

Por que isso ajuda

A origem diz o quão atualizado o número tem permissão para estar — o que às vezes já explica toda a diferença sozinho.

05

Passo 05

Compare definições, não só contagens

Os dois sistemas podem estar corretos e mesmo assim nunca concordar.

Comparação

Sistema A

Conta uma operação alterada como uma única operação — só a versão mais recente.

Sistema B

Conta cada versão da operação separadamente, incluindo as alterações.

Por que isso ajuda

Os dois podem estar se comportando exatamente como foram desenhados. A divergência é uma lacuna de definição, não um defeito em nenhum dos dois.

06

Passo 06

Compare estados de processamento

Uma contagem feita no meio do pipeline nunca vai bater com uma contagem feita no final dele.

O fluxo

RecebidaValidadaRegistradaCasadaLiquidadaRejeitada

Por que isso ajuda

Se o Sistema A conta qualquer coisa depois de "Recebida" e o Sistema B só conta "Liquidada", a diferença já está explicada antes de você olhar uma única linha.

07

Passo 07

Verifique os filtros

Alguém, em algum momento, provavelmente aplicou um filtro e esqueceu dele.

Resumo

Um filtro de tela deixado ligado
Padrões de relatório que ninguém lembra de ter configurado
Condições WHERE de SQL embutidas na query
Status excluídos por padrão

Por que isso ajuda

Esse único passo resolve mais divergências do que qualquer um dos outros e é o mais fácil de pular porque parece simples demais para ser a resposta.

08

Passo 08

Verifique se há duplicatas

Às vezes o número maior é o errado, não o menor.

Por que isso ajuda

Uma requisição reenviada, um batch executado de novo, ou um join que se multiplica inesperadamente podem inflar uma contagem silenciosamente.

09

Passo 09

Verifique se há registros faltando

E às vezes é o número menor que está incompleto de verdade.

Por que isso ajuda

Uma carga que falhou, um filtro que descarta nulos silenciosamente, ou um join que descarta linhas sem correspondência podem encolher uma contagem silenciosamente.

10

Passo 10

Compare identificadores

Casar pela chave errada pode parecer exatamente uma divergência de dados.

Resumo

ID da Operação
ID da Ordem
ID da Transação
ID Externo

Por que isso ajuda

Se o Sistema A usa um ID de operação interno como chave e o Sistema B usa uma referência externa, registros que na verdade batem vão parecer sem correspondência até o mapeamento ser corrigido.

11

Passo 11

Pegue uma amostra pequena antes de mexer na população inteira

Não comece pelas 100.000 linhas.

Por que isso ajuda

Escolha de 5 a 10 divergências individuais e rastreie cada uma manualmente. O padrão que explica todas elas geralmente aparece depois da terceira ou quarta.

Dica — Se a mesma explicação der conta das suas primeiras cinco divergências, é bem provável que ela explique o resto também — confirme isso antes de assumir o contrário.

12

Passo 12

Separe o que você encontrar em categorias de reconciliação

Nem toda divergência é o mesmo tipo de divergência. Separe-as antes de explicá-las.

O fluxo

Só em ASó em BNos dois, valores diferemNos dois, bate

Por que isso ajuda

"Só em A" aponta para um problema de registro faltante. "Nos dois, valores diferem" aponta para um problema de definição ou tempo. Elas precisam de investigações diferentes, não de uma explicação em comum.

13

Passo 13

Classifique a causa raiz

Toda divergência remete a uma de um pequeno número de causas.

Resumo

Dado — algo está faltando ou duplicado
Definição — os dois lados querem dizer coisas diferentes
Tempo — os dois lados foram medidos em momentos diferentes
Processamento — os dois lados estão em estágios diferentes do pipeline
Relatório — a camada de relatório, não o dado subjacente, está errada
Requisito — ninguém realmente especificou qual desses estava correto

Por que isso ajuda

Nomear a categoria já é a maior parte da correção. "É um problema de tempo" já diz a todos que tipo de conversa vem a seguir.

14

Passo 14

Documente a causa real, não só que foi resolvido

"Resolvido" não é um achado. É a ausência de um.

The shift

Divergência de dados resolvida.

O Sistema B exclui operações em status PENDING_ALLOCATION enquanto o Sistema A as inclui. Decisão de negócio: a definição do Sistema A está correta; o filtro do relatório do Sistema B foi atualizado para bater com ela.

Por que isso ajuda

A próxima pessoa que se deparar com uma divergência parecida — e vai ter uma próxima pessoa — precisa da causa real, não de uma atualização de status.

Nenhum dos números estava "errado".

Eles nunca estiveram contando a mesma coisa.

A maioria das divergências de dados se resolve numa resposta de uma frase assim que alguém rastreia um punhado de registros em vez de discutir sobre os totais. Os totais são um sintoma. A lacuna de definição, tempo ou status por baixo deles é o achado de verdade.

Leve isso com você

Checklist de Investigação de Divergência de Dados

CHECKLIST DE INVESTIGAÇÃO DE DIVERGÊNCIA DE DADOS

[ ] Mesma métrica
[ ] Mesma definição de negócio
[ ] Mesma data
[ ] Mesmo fuso horário
[ ] Mesma população
[ ] Mesmos filtros
[ ] Mesmo status
[ ] Mesma origem
[ ] Mesmos identificadores
[ ] Checagem de duplicatas feita
[ ] Checagem de registros faltantes feita
[ ] Amostra pequena reconciliada
[ ] Causa raiz classificada
[ ] Decisão de negócio registrada

Receba novos guias em primeira mão.