Power Query: como tratar tipos de dados e erros

O relatório atualiza numa máquina e quebra na outra#

Você monta a consulta, os dados carregam bonitinho, publica no Power BI e uma semana depois o relatório volta cheio de erro no refresh. Ou pior: atualiza sem reclamar, mas os números estão errados porque a data virou texto e o valor decimal foi lido como milhar. Se isso soa familiar, o problema quase sempre mora em dois lugares: como você define os tipos de dados e como você trata os erros. Dominar Power Query tratar tipos de dados e erros é o que separa uma consulta que aguenta produção de uma que depende de sorte a cada carga.

Neste artigo você vai ver, passo a passo, como definir tipos de forma explícita, o papel do Locale na conversão de número e data, a diferença entre erro de célula e erro de etapa, como remover ou substituir erros e o padrão try ... otherwise para blindar transformações. Tudo com exemplos de código M que você pode colar direto no Editor Avançado.

Definir o tipo é uma decisão, não um detalhe#

Quando o Power Query importa dados, ele tenta adivinhar o tipo de cada coluna. Essa detecção automática cria uma etapa chamada Changed Type (Tipo Alterado) logo depois da fonte. O problema é que adivinhação boa em uma fonte é adivinhação ruim em outra, e essa etapa fica gravada apontando para nomes de coluna específicos.

A forma correta de fixar tipos é a função Table.TransformColumnTypes. Ela recebe a tabela e uma lista de pares coluna/tipo:

let
    Fonte = Excel.Workbook(File.Contents("C:\dados\vendas.xlsx"), null, true),
    Tabela = Fonte{[Item="Vendas",Kind="Table"]}[Data],
    TiposDefinidos = Table.TransformColumnTypes(
        Tabela,
        {
            {"Pedido", Int64.Type},
            {"Cliente", type text},
            {"Data", type date},
            {"Valor", type number},
            {"Ativo", type logical}
        }
    )
in
    TiposDefinidos

Os tipos que você mais vai usar no dia a dia estão na tabela abaixo. Definir o tipo certo importa porque ele determina como o dado é armazenado, como o DAX o interpreta depois e quanto de memória o modelo consome.

Tipo em M	Rótulo na interface	Quando usar
Int64.Type	Número Inteiro	IDs, quantidades, chaves
type number	Número Decimal	Valores monetários, percentuais
Currency.Type	Número Decimal Fixo	Moeda com 4 casas fixas
type date	Data	Datas sem hora
type datetime	Data/Hora	Registro com carimbo de tempo
type text	Texto	Nomes, códigos com zero à esquerda
type logical	Verdadeiro/Falso	Flags booleanas

Uma boa prática de consultoria: nunca deixe uma coluna importante como type any. Coluna sem tipo definido é coluna que o Power BI vai tentar converter na hora do carregamento, e é aí que o erro aparece longe de onde você consegue enxergar.

A posição da etapa Changed Type importa#

Aqui está o erro mais comum que encontramos em auditorias de consultas. A etapa Changed Type fica na posição errada e passa a quebrar a cada atualização. O caso clássico: você define os tipos, depois renomeia uma coluna ou muda a fonte, e a etapa de tipo continua apontando para o nome antigo. No refresh, o Power Query não encontra a coluna e devolve o erro A coluna 'X' da tabela não foi encontrada.

A regra prática é simples:

1. Deixe a definição de tipos o mais perto possível do final da consulta, depois de renomear, remover e dividir colunas.
2. Evite várias etapas Changed Type espalhadas. Consolide numa única etapa de tipagem.
3. Se você mudar a fonte de dados, revise a etapa de tipos antes de publicar.
4. Colunas que ainda vão passar por transformação de texto (dividir, extrair, substituir) devem ser tipadas depois dessas operações, não antes.

O Locale decide se 1.500 é mil e quinhentos ou um vírgula cinco#

Este é o ponto que mais gera número errado silencioso. A conversão de texto para número e de texto para data depende do Locale, também chamado de Cultura. O Locale é a configuração regional que diz ao Power Query como interpretar o separador decimal, o separador de milhar e a ordem de dia e mês.

No Brasil, 1.500,75 significa mil e quinhentos e setenta e cinco centavos. Em um Locale en-US, o mesmo texto seria interpretado de outra forma, porque lá o ponto é o decimal e a vírgula é o milhar. Se o Power Query estiver rodando com uma cultura diferente da que gerou o arquivo, a conversão sai errada sem gerar nenhum erro visível.

Compare o que cada cultura faz com o mesmo texto de entrada:

Texto de entrada	Locale pt-BR	Locale en-US
1.500,75	1500,75	erro ou 1.50075
12/03/2026	12 de março	3 de dezembro
1,234	1,234 (um vírgula)	1234 (mil)
3/7/2026	3 de julho	7 de março

A solução não é confiar na configuração da máquina. É declarar a cultura na própria conversão, usando a versão da função que aceita um terceiro parâmetro de Locale:

let
    Fonte = ...,
    // Conversão de texto para data usando cultura brasileira
    ConverteData = Table.TransformColumnTypes(
        Fonte,
        {{"Data", type date}},
        "pt-BR"
    ),
    // Conversão de texto para número decimal com cultura explícita
    ConverteValor = Table.TransformColumnTypes(
        ConverteData,
        {{"Valor", type number}},
        "pt-BR"
    )
in
    ConverteValor

Você também pode converter valor a valor com Value.FromText passando a cultura, útil quando só uma coluna precisa de tratamento especial:

Table.AddColumn(
    Fonte,
    "ValorNumerico",
    each Value.FromText([ValorTexto], "pt-BR"),
    type number
)

Declarar o Locale explicitamente é o que garante que a mesma consulta produza o mesmo resultado na sua máquina, na do colega e no serviço do Power BI. Quando a origem dos dados é bagunçada, vale a pena tratar a padronização mais a fundo dentro de um processo de engenharia de dados, antes de o dado chegar ao relatório.

Erro de célula e erro de etapa não são a mesma coisa#

Quando algo dá errado na conversão, o Power Query pode falhar de duas maneiras bem diferentes, e confundir as duas leva a horas perdidas de depuração.

O erro de célula acontece quando uma linha específica não consegue ser convertida, mas o resto da coluna segue normal. A célula vira um valor especial do tipo Error. A consulta continua rodando e o erro fica ali, guardado naquela célula. Você vê algo como Error no lugar do valor, e ao clicar consegue ler a mensagem, por exemplo Não foi possível converter o valor 'abc' para o tipo Number.

O erro de etapa é mais grave. Ele interrompe a etapa inteira e derruba toda a consulta. É o caso da coluna não encontrada, da fonte inacessível ou de uma função que recebeu um argumento inválido. Nenhuma linha carrega até você corrigir.

Aspecto	Erro de célula	Erro de etapa
Alcance	Uma célula isolada	A etapa inteira
A consulta carrega?	Sim, com células Error	Não
Onde aparece	Dentro da coluna	Barra amarela no topo
Causa típica	Valor que não converte	Coluna ausente, fonte off
Como tratar	Remover, substituir, try	Corrigir a etapa ou a fonte

Entender essa diferença é o primeiro passo para escolher a ferramenta certa. Erro de célula você trata com as opções abaixo. Erro de etapa você resolve na causa: corrige o nome da coluna, restabelece a conexão ou ajusta o argumento.

Remover ou substituir erros resolve as células problemáticas#

Para os erros de célula, o Power Query oferece duas ações diretas na interface, ambas com função M por trás.

A primeira é remover as linhas com erro. Selecione a coluna, vá em Página Inicial, Remover Linhas, Remover Erros. Isso descarta qualquer linha que tenha valor Error naquela coluna. Use quando a linha problemática é lixo mesmo e não faz falta.

Table.RemoveRowsWithErrors(Fonte, {"Valor"})

A segunda é substituir os erros por um valor padrão. Clique com o botão direito na coluna, Substituir Erros, e informe o valor. Use quando você quer manter a linha, mas trocar o erro por algo controlado como zero, nulo ou um texto de marcação.

Table.ReplaceErrorValues(Fonte, {{"Valor", 0}})

A escolha entre remover e substituir é de negócio, não técnica. Remover uma linha de venda com valor inválido pode esconder um pedido real que precisava ser corrigido na origem. Substituir por zero pode distorcer uma média. A recomendação de consultor é: antes de descartar, entenda por que aquele erro existe. Muitas vezes o erro de célula é um sintoma de dado sujo na origem que merece correção lá, não maquiagem no relatório.

O padrão try otherwise blinda as transformações#

Remover e substituir resolvem erros que já aconteceram numa coluna. Mas e quando você quer controlar exatamente o que acontece em cada valor durante uma transformação, sem quebrar nada? É para isso que existe o try ... otherwise.

O try tenta avaliar uma expressão. Se der certo, devolve o resultado. Se der erro, o otherwise entrega um valor alternativo que você definiu. É o equivalente ao tratamento de exceção que existe em outras linguagens, e ele funciona valor a valor.

Table.AddColumn(
    Fonte,
    "ValorSeguro",
    each try Value.FromText([ValorTexto], "pt-BR") otherwise 0,
    type number
)

No exemplo, cada linha tenta converter o texto para número na cultura brasileira. A que conseguir, converte. A que falhar, recebe zero em vez de virar uma célula Error. A consulta nunca quebra por causa desse campo.

Quando você precisa saber se houve erro e por quê, use o try sozinho. Ele devolve um registro com o campo HasError e, quando há falha, os detalhes:

Table.AddColumn(
    Fonte,
    "Diagnostico",
    each
        let
            Resultado = try Number.FromText([Codigo])
        in
            if Resultado[HasError]
            then "Falhou: " & Resultado[Error][Message]
            else "OK",
    type text
)

Esse padrão é ótimo para auditar cargas: você cria uma coluna de diagnóstico, filtra o que falhou, entende a causa e só então decide se corrige na origem ou trata na consulta. É exatamente o tipo de rigor que sustenta um projeto de Power BI confiável no longo prazo e evita retrabalho na sustentação de BI.

Power Query tratar tipos de dados e erros num fluxo único#

Junte tudo numa sequência que funciona na maioria dos casos:

1. Importe a fonte e remova a etapa Changed Type automática se ela vier logo no início.
2. Faça as transformações de estrutura: remover, renomear, dividir e extrair colunas.
3. Trate valores textuais problemáticos com try ... otherwise onde a conversão é arriscada.
4. Aplique Table.TransformColumnTypes com o Locale explícito, próximo ao fim.
5. Decida por remover ou substituir os erros de célula que sobraram, com critério de negócio.
6. Documente a decisão num comentário no código M para o próximo que abrir a consulta.

Perguntas frequentes#

Por que meus números decimais viram inteiros gigantes ou dão erro na conversão?

Quase sempre é conflito de Locale. O separador decimal do texto não bate com a cultura que o Power Query está usando. A vírgula que deveria ser decimal é lida como milhar, ou vice-versa. Declare a cultura no terceiro parâmetro de Table.TransformColumnTypes ou use Value.FromText com o Locale correto, em vez de confiar na configuração da máquina.

Qual a diferença entre remover erros e substituir erros?

Remover descarta a linha inteira que contém o erro naquela coluna, com Table.RemoveRowsWithErrors. Substituir mantém a linha e troca o valor de erro por outro que você define, com Table.ReplaceErrorValues. Use remover quando a linha é descartável e substituir quando você precisa preservar a linha com um valor padrão como zero ou nulo.

O try otherwise deixa a consulta mais lenta?

Ele adiciona uma avaliação por valor, então há um custo, mas geralmente pequeno perto do benefício de não quebrar a carga. O ponto de atenção é usar try apenas onde a falha é realmente possível. Envolver toda a consulta em try sem critério esconde problemas que você deveria estar vendo e corrigindo.

Por que a etapa Changed Type quebra depois que eu mudo a fonte?

Porque ela grava os nomes das colunas de forma fixa. Se a fonte muda e uma coluna some ou é renomeada, a etapa procura um nome que não existe mais e gera erro de etapa. Mantenha a tipagem numa única etapa próxima ao fim da consulta e revise-a sempre que alterar a origem.

Devo sempre corrigir o erro na consulta ou na origem dos dados?

Depende da causa, mas a regra de ouro é: erro recorrente e sistêmico deve ser corrigido na origem. Tratar tudo dentro do Power Query transforma a consulta num remendo cada vez mais frágil. Trate na consulta o que é pontual e inevitável, e leve para a origem o que é padrão de dado sujo. Isso costuma exigir olhar o pipeline com uma abordagem de analytics avançado.

Preciso definir tipo em todas as colunas mesmo?

Em todas as colunas que vão para o modelo, sim. Coluna sem tipo definido fica como type any e obriga o Power BI a inferir o tipo no carregamento, o que gera erro difícil de rastrear e piora o desempenho. Colunas que você vai remover antes de carregar não precisam de tipo.

Fechamento#

Tratar tipos de dados e erros no Power Query não é burocracia, é o que faz seu relatório atualizar sem susto toda segunda-feira de manhã. Defina tipos de forma explícita e no lugar certo, declare o Locale em toda conversão de número e data, saiba distinguir erro de célula de erro de etapa e use try ... otherwise para blindar as transformações arriscadas. Com esse conjunto, você troca a sorte por método.

Se a sua base é grande, a origem é bagunçada ou você quer padronizar essas práticas no time inteiro, fale com a gente. A Fynx ajuda a estruturar consultas robustas que não quebram em produção.