Seu Número Não Bate Com o do BI… Quem Está Errado?

Essa situação acontece mais do que deveria.

Você faz sua análise. Roda sua query. Chega em um número.

Aí alguém abre o dashboard e diz:

“Aqui está diferente.”

E pronto.

Agora não é mais só SQL.

👉 É confiança.

O pior cenário não é o erro

O pior cenário é esse:

• os dois números parecem corretos
• ninguém sabe explicar a diferença
• cada área defende o seu

👉 E a decisão trava.

Antes de procurar erro, entenda o contexto

A primeira coisa que você precisa fazer não é abrir o SQL.

É perguntar:

• Estamos olhando o mesmo período?
• A definição de métrica é a mesma?
• O BI usa dado bruto ou transformado?
• Existe atualização em tempo real ou batch?

👉 Muitas divergências não são erro.

👉 São definição diferente.

Etapa 1 — Garantir que a base é a mesma

Você começa verificando:

• mesma tabela
• mesmo filtro de data
• mesmo critério de exclusão (cancelado, teste, etc.)

Exemplo:

SELECT
COUNT(*) AS QTD_PEDIDOS,
SUM(VALOR_TOTAL) AS FATURAMENTO
FROM pedido
WHERE DATA_PEDIDO >= '2024-01-01'
AND DATA_PEDIDO < '2024-02-01';

👉 Se isso já não bate com o BI, o problema pode estar no filtro.

Etapa 2 — Ver granularidade

Essa é a principal causa de divergência.

Pergunta-chave:

O BI está olhando em que nível?

• pedido?
• item?
• cliente?
• sessão?

Se você compara:

• query por pedido com
• dashboard por item

👉 o número nunca vai bater.

Etapa 3 — Ver JOINs (o erro mais comum)

Aqui mora o clássico:

👉 duplicação silenciosa

Exemplo:

SELECT
SUM(i.VALOR_ITEM) AS FATURAMENTO
FROM pedido p
JOIN item_pedido i
ON i.ID_PEDIDO = p.ID_PEDIDO;

Se você não controla:

• cardinalidade
• multiplicação de linhas

👉 o número cresce sem você perceber.

Etapa 4 — Ver transformação do BI

Muita gente esquece disso.

O BI pode estar:

• aplicando filtro automático
• excluindo cancelados
• usando tabela agregada
• usando snapshot
• aplicando cálculo customizado

👉 Ou seja:

O BI nem sempre mostra o dado bruto.

Etapa 5 — Reduzir até ficar óbvio

Se não bate, simplifique.

• 1 cliente
• 1 dia
• 1 produto

SELECT * FROM pedido
WHERE ID_CLIENTE = 123;

👉 Se você não consegue explicar um caso pequeno, não vai explicar o todo.

O erro que destrói confiança

Muita gente faz isso:

• vê diferença
• ajusta query até “bater”
• entrega

👉 sem entender o motivo

Isso resolve o número… mas destrói confiança.

O que profissional faz diferente

Ele não pergunta:

“Como faço bater?”

Ele pergunta:

“Por que está diferente?”

Ordem correta de investigação

1. Confirmar definição
2. Validar base
3. Conferir granularidade
4. Revisar JOIN
5. Checar transformação
6. Testar caso simples

O que esse case realmente ensina

SQL não é sobre:

• escrever query
• rodar comando
• entregar número

É sobre:

👉 confiar no que você está entregando

Próximo passo natural

Se você quer desenvolver esse tipo de segurança:

🎯 A Arte da Query te coloca exatamente nesses cenários reais onde você precisa justificar, não só rodar

E para praticar com dados reais:

📚 Baseoteca SQL

Tags: Banco de Dados | Case | SQL