Time intelligence em DAX: o que faz e quando usar (com exemplos)

Todo relatório de vendas trava na mesma pergunta: "e comparado com o ano passado?"#

Você monta um dashboard bonito, o diretor olha por três segundos e pergunta: "isso está melhor ou pior que o mesmo período do ano anterior?". Sem uma boa base de time intelligence DAX, essa pergunta simples vira uma dor de cabeça de modelagem. É aqui que a maioria dos relatórios corporativos quebra, não na visualização, mas na lógica temporal por trás dos números.

Time intelligence é o conjunto de funções DAX que permite calcular métricas ao longo do tempo: acumulado no ano, acumulado no mês, comparação com período anterior, médias móveis e por aí vai. Parece trivial, mas é onde mora boa parte dos erros de número que fazem uma área inteira perder confiança no BI. Neste artigo eu explico o que essas funções fazem de verdade, mostro a sintaxe de YTD, MTD e ano anterior, e sou honesto sobre as armadilhas que quase ninguém conta.

Time intelligence DAX depende de uma coisa antes de tudo: a tabela calendário#

Antes de qualquer fórmula, a verdade incômoda: quase todas as funções de time intelligence exigem uma tabela de datas dedicada, contínua e marcada como tabela de datas. Sem isso, nada funciona de forma previsível.

O motivo é técnico. Funções como DATESYTD, TOTALYTD e SAMEPERIODLASTYEAR precisam de uma coluna de datas que cubra todo o intervalo sem buracos. Se o seu modelo só tem datas onde houve venda, os dias sem movimento não existem, e o cálculo de acumulado passa por cima de períodos inteiros sem perceber. O Power BI até oferece a opção de tabelas de datas automáticas, mas eu recomendo desligar isso em qualquer projeto sério. Ela cria uma tabela oculta por coluna de data, incha o modelo e você perde controle.

O jeito correto é criar sua própria tabela calendário. Uma versão mínima em DAX:

Calendario = CALENDAR(DATE(2020,1,1), DATE(2027,12,31))

Depois você enriquece com colunas de Ano, Mês, Trimestre, número do mês e nome do mês. Em seguida, no menu de ferramentas de tabela, use "Marcar como tabela de datas" apontando para a coluna de data. Isso não é enfeite: é o que garante que o contexto de filtro temporal se propague de forma correta pelo modelo. Se você trabalha com um modelo em estrela bem montado, essa tabela vira a dimensão de tempo que se relaciona com todas as tabelas de fato. Vale revisar nossos princípios de modelagem e boas práticas de DAX antes de escalar isso para produção.

Uma nota de desempenho que ajuda a entender o porquê: o motor VertiPaq, que roda por baixo do Power BI, comprime colunas por cardinalidade. Uma coluna de data pura tem cardinalidade alta, mas colunas derivadas como Ano ou Mês têm cardinalidade baixa e comprimem muito bem, o que mantém o modelo leve mesmo com uma tabela calendário grande.

O que YTD faz e como escrever#

YTD significa Year To Date, ou acumulado no ano. Ele soma uma métrica desde o primeiro dia do ano fiscal até a data do contexto atual. Se você está olhando março, o YTD de vendas soma janeiro, fevereiro e março.

Há dois caminhos principais. O atalho:

Vendas YTD = TOTALYTD([Total Vendas], Calendario[Data])

E a forma explícita, que eu prefiro por deixar a intenção clara e ser mais fácil de auditar:

Vendas YTD = CALCULATE([Total Vendas], DATESYTD(Calendario[Data]))

As duas produzem o mesmo resultado. DATESYTD devolve o conjunto de datas do início do ano até a data corrente, e CALCULATE aplica esse conjunto como filtro sobre a medida. Repare que eu sempre parto de uma medida base ([Total Vendas]) em vez de somar a coluna diretamente dentro da função. Isso é boa prática de reuso: a lógica de soma fica em um só lugar.

Se o seu ano fiscal não fecha em dezembro, o que é comum em muitas empresas brasileiras que usam anos fiscais diferentes, você informa a data de fechamento:

Vendas YTD Fiscal = TOTALYTD([Total Vendas], Calendario[Data], "06-30")

Aqui o acumulado reinicia em 1 de julho, fechando o ano fiscal em 30 de junho. Esquecer esse parâmetro é uma das causas mais comuns de números que "não batem com o financeiro".

MTD, QTD e as variações do mesmo conceito#

MTD (Month To Date) e QTD (Quarter To Date) seguem exatamente a mesma lógica do YTD, mudando só o período de reinício.

Vendas MTD = CALCULATE([Total Vendas], DATESMTD(Calendario[Data]))

Vendas QTD = CALCULATE([Total Vendas], DATESQTD(Calendario[Data]))

A tabela abaixo resume as principais funções de acumulado e o que cada uma reinicia:

Função	Sigla	Reinicia em	Uso típico
DATESYTD / TOTALYTD	YTD	Início do ano	Acompanhar meta anual
DATESQTD / TOTALQTD	QTD	Início do trimestre	Fechamento trimestral
DATESMTD / TOTALMTD	MTD	Início do mês	Ritmo do mês corrente

Um detalhe que confunde muita gente: esses acumulados respeitam o contexto de filtro do visual. Se você colocar a medida YTD numa tabela com linhas por mês, cada linha mostra o acumulado até aquele mês, não o ano inteiro. Isso é o comportamento correto, mas surpreende quem espera ver o mesmo número repetido.

Comparar com o ano anterior: SAMEPERIODLASTYEAR e DATEADD#

Aqui está a função que responde a pergunta do diretor. SAMEPERIODLASTYEAR desloca o contexto de datas exatamente um ano para trás:

Vendas Ano Anterior = CALCULATE([Total Vendas], SAMEPERIODLASTYEAR(Calendario[Data]))

Com essa medida pronta, o crescimento ano contra ano fica direto:

Crescimento YoY % = DIVIDE([Total Vendas] - [Vendas Ano Anterior], [Vendas Ano Anterior])

Note o uso de DIVIDE em vez do operador de divisão. DIVIDE trata a divisão por zero sem gerar erro, devolvendo em branco quando não há base de comparação. É a diferença entre um relatório limpo e um cheio de mensagens de erro no primeiro mês sem histórico.

Uma alternativa mais flexível é DATEADD, que permite deslocar por qualquer intervalo:

Vendas Ano Anterior = CALCULATE([Total Vendas], DATEADD(Calendario[Data], -1, YEAR))

Vendas Mês Anterior = CALCULATE([Total Vendas], DATEADD(Calendario[Data], -1, MONTH))

DATEADD aceita DAY, MONTH, QUARTER e YEAR, e o número pode ser positivo para ir ao futuro. Quando você precisa comparar o acumulado do ano atual com o acumulado do ano anterior no mesmo ponto, combina as duas ideias:

Vendas YTD Ano Anterior = CALCULATE([Vendas YTD], SAMEPERIODLASTYEAR(Calendario[Data]))

A tabela a seguir compara as funções de comparação de período mais usadas:

Função	O que faz	Quando usar
SAMEPERIODLASTYEAR	Desloca exatamente 1 ano para trás	Comparação anual direta
DATEADD	Desloca por dia, mês, trimestre ou ano	Qualquer comparação flexível
PARALLELPERIOD	Retorna o período inteiro paralelo	Comparar mês/trimestre completo
PREVIOUSMONTH	Mês calendário anterior completo	Variação mês a mês

As armadilhas que quebram os números#

Aqui é onde eu sou honesto, porque essas armadilhas custam horas de retrabalho e, pior, custam a confiança da liderança nos dados.

Datas incompletas na tabela calendário. Se a tabela não cobre todo o intervalo dos dados, ou tem buracos, o acumulado ignora silenciosamente os períodos ausentes. Não dá erro, só dá número errado. Sempre gere a tabela com CALENDAR ou CALENDARAUTO para garantir continuidade.

Relacionamento com a tabela de datas errada ou ausente. As funções de time intelligence propagam filtro pelo relacionamento ativo entre a dimensão de tempo e o fato. Se você tem duas datas na tabela de fato, por exemplo data do pedido e data de entrega, só uma pode ter o relacionamento ativo. Para usar a outra, você precisa de USERELATIONSHIP dentro do CALCULATE. Ignorar isso faz o número refletir a data errada.

Confiar na data automática do Power BI. Ela funciona em protótipos, mas em modelos reais infla o tamanho, dificulta a manutenção e às vezes conflita com sua tabela calendário própria. Desligue e assuma o controle.

Usar a coluna de data em vez de uma medida base. Escrever SUM da coluna dentro de cada função de time intelligence espalha a lógica e dificulta manutenção. Centralize na medida base e reutilize.

Ano fiscal esquecido. Já mencionei, mas repito porque é frequente: se a empresa fecha o ano em junho e você usa o YTD padrão, tudo fica deslocado seis meses. Sempre confirme o calendário fiscal com a área financeira.

Meses futuros mostrando zero em vez de vazio. Ao comparar com ano anterior, meses que ainda não aconteceram podem aparecer com zero e distorcer gráficos e totais. Trate isso com lógica condicional para retornar em branco quando não há dados reais no período.

Muitos desses problemas aparecem justamente quando o modelo cresce e vira responsabilidade de mais de uma pessoa. É quando um trabalho estruturado de sustentação de BI e de governança de dados passa a fazer diferença real, com padrões documentados de medidas e revisão de modelo.

Boas práticas que separam o relatório amador do profissional#

Depois de anos montando e corrigindo modelos de clientes, alguns hábitos se repetem entre os projetos que dão certo.

Crie uma tabela de medidas separada, sem colunas, só para organizar suas medidas de time intelligence em um lugar. Use nomes explícitos e consistentes, como "Vendas YTD" e "Vendas Ano Anterior", em vez de abreviações que ninguém entende três meses depois. Sempre construa medidas em camadas: uma medida base para a soma, uma para o acumulado, outra para a comparação, outra para o percentual. Isso torna cada peça testável e reutilizável.

Documente qual é o calendário fiscal e qual coluna de data está marcada como tabela de datas. Parece burocracia, mas evita que o próximo analista refaça tudo do zero. E teste seus acumulados manualmente no começo: pegue três meses, some na mão, confira. Confiança em BI se constrói com números que batem.

Se o volume de dados é grande e você está avaliando arquiteturas modernas, vale entender como o Microsoft Fabric e o modo Direct Lake, que lê direto do OneLake, mudam a forma de servir esses modelos. A lógica de time intelligence continua a mesma, mas o motor por trás e o dimensionamento de capacidade, medido em Capacity Units nas SKUs que vão de F2 a F2048, entram na conversa quando o modelo cresce. Para projetos que precisam de estrutura de dados por trás, nosso time de engenharia de dados costuma resolver a origem antes de o DAX virar problema.

Perguntas frequentes#

Preciso mesmo de uma tabela calendário separada para usar time intelligence?

Sim, na prática você precisa. As funções de time intelligence dependem de uma coluna de datas contínua e, idealmente, de uma tabela marcada como tabela de datas. Usar a coluna de data da própria tabela de fato funciona em casos muito simples, mas quebra assim que você tem mais de uma data ou períodos sem movimento. Investir na tabela calendário é o passo que evita a maioria dos erros.

Qual a diferença entre TOTALYTD e DATESYTD?

TOTALYTD é um atalho que já embute o CALCULATE, enquanto DATESYTD devolve apenas o conjunto de datas e precisa ser usado dentro de um CALCULATE. O resultado é idêntico. Eu prefiro a forma explícita com DATESYTD porque deixa a lógica mais transparente e mais fácil de estender depois, mas as duas estão corretas.

Por que meu cálculo de ano anterior mostra zero em meses futuros?

Porque a comparação encontra datas válidas no ano anterior mesmo para meses que ainda não aconteceram no ano atual. A solução é adicionar lógica condicional que retorna em branco quando não há dados reais no período corrente, tipicamente comparando a data máxima com dados reais contra a data do contexto. Isso limpa gráficos e evita totais distorcidos.

SAMEPERIODLASTYEAR ou DATEADD, qual devo usar?

Para uma comparação anual simples e direta, SAMEPERIODLASTYEAR é mais legível. Quando você precisa de flexibilidade, por exemplo comparar com dois anos atrás, com o mês anterior ou com o trimestre anterior, DATEADD cobre todos os casos com o mesmo padrão. Muitos modelos usam as duas, cada uma onde faz mais sentido.

A data automática do Power BI atrapalha esses cálculos?

Pode atrapalhar. Ela cria tabelas de datas ocultas para cada coluna de data, aumenta o tamanho do modelo e pode conflitar com sua tabela calendário própria. Em projetos sérios eu recomendo desligar a opção e assumir o controle com uma tabela calendário explícita, o que também facilita governança e desempenho.

Time intelligence funciona igual no Microsoft Fabric?

A linguagem DAX e as funções de time intelligence são as mesmas, porque o modelo semântico continua sendo o mesmo motor. O que muda no Fabric é a arquitetura de armazenamento e o modo de leitura, como o Direct Lake sobre o OneLake, além do dimensionamento por Capacity Units. Sua lógica de YTD, MTD e ano anterior continua válida sem reescrita.

Fechando#

Time intelligence não é a parte glamourosa do Power BI, mas é a que decide se a liderança confia ou não nos seus números. Comece pela tabela calendário, construa medidas em camadas, trate as armadilhas de datas incompletas e ano fiscal, e teste os acumulados na mão até ter certeza. O resto é repetição de padrão. Se a sua empresa está estruturando ou corrigindo modelos de dados e quer fazer isso com método, fale com a gente e a gente ajuda a montar um BI que responde a pergunta do ano anterior sem hesitar.