Google Sheets QUERY GROUP BY: erro cannot group without agg

Por que o erro acontece

A função QUERY do Google roda sobre a linguagem de consulta da Google Visualization API (documentação oficial, revisão de maio de 2026), que segue regras rígidas no estilo SQL. A documentação é clara: "Ao usar GROUP BY, cada coluna na cláusula SELECT deve estar listada na cláusula GROUP BY ou usar uma função de agregação."

Sem ambiguidade, sem exceções. Cada coluna é ou uma dimensão (listada no GROUP BY) ou uma medida (envolvida por uma agregação). No momento em que você mistura esses papéis, o QUERY para com cannot group without agg.

A documentação de referência da função QUERY no Google Sheets (Google Workspace, acesso em 13 de junho de 2026) reforça a mesma regra e lista as funções de agregação aceitas: SUM, AVG, COUNT, MAX e MIN. Qualquer tentativa de referenciar uma coluna não agregada fora do GROUP BY resulta no mesmo erro, independentemente da complexidade da consulta.

Veja um exemplo concreto. Você tem uma aba Receita com as colunas: Data (A), Região (B), SKU (C), Receita (D), CMV (E). Você quer a receita por região:

=QUERY('Receita'!A:E, "SELECT B, C, SUM(D) GROUP BY B", 1)

Isso retorna o erro porque a coluna C (SKU) aparece no SELECT, mas não está no GROUP BY e também não foi agregada. Duas correções válidas:

Opção 1 - Adicionar SKU ao GROUP BY (retorna uma linha por par região-SKU):

=QUERY('Receita'!A:E, "SELECT B, C, SUM(D) GROUP BY B, C", 1)

Opção 2 - Remover SKU do SELECT (retorna uma linha por região):

=QUERY('Receita'!A:E, "SELECT B, SUM(D) GROUP BY B", 1)

A correção certa depende do resultado que você precisa, não da sintaxe do QUERY. Se você quer receita por região apenas, remova C. Se quer receita por região e SKU, mantenha C e adicione-o ao GROUP BY.

O padrão de auditoria de colunas

Para uma consulta com 6 ou mais colunas, audite cada coluna do SELECT antes de executar. Veja um exemplo de extração de resultados do segundo trimestre que agrupa corretamente:

=QUERY(
  'Receita'!A:F,
  "SELECT B, SUM(D), SUM(E), SUM(D)-SUM(E)
   WHERE A >= date '2026-04-01' AND A <= date '2026-06-30'
   GROUP BY B
   LABEL SUM(D) 'Receita', SUM(E) 'CMV', SUM(D)-SUM(E) 'Lucro Bruto'",
  1
)

Região (B) é a dimensão e vai no GROUP BY. Receita, CMV e Lucro Bruto são medidas: cada uma está envolvida em SUM() ou expressa como combinação de agregações. A expressão SUM(D)-SUM(E) funciona exatamente porque ambos os componentes são agregados. O resultado por grupo é um único valor, que é tudo o que o QUERY exige.

QUERY GROUP BY versus SUMIFS: escolhendo a ferramenta certa

O GROUP BY do QUERY é limpo para agregações em uma única aba. Para modelos financeiros com múltiplas abas, o SUMIFS costuma ganhar. Veja a comparação honesta:

Se o seu relatório trimestral busca realizados com o intervalo de datas na aba Premissas!$B$3:$B$4 e a receita em 'DRE'!C:C, o SUMIFS resolve sem as gambiarras de concatenação do QUERY:

=SUMIFS(
  'DRE'!C:C,
  'DRE'!B:B, ">=" & Premissas!$B$3,
  'DRE'!B:B, "<=" & Premissas!$B$4,
  'DRE'!D:D, Receitas!$A2
)

O QUERY não consegue referenciar Premissas!$B$3 diretamente dentro da string de consulta. Você precisaria concatenar o valor como texto, o que quebra na formatação de datas e gera erros que parecem não ter relação com o problema original. O SUMIFS aceita a referência de célula de forma nativa.

Quando o QUERY GROUP BY vale a pena

O QUERY se destaca quando você não conhece de antemão os valores distintos da dimensão. Se você tem 14 SKUs ativos e precisa da margem de contribuição por SKU para uma análise de margem bruta (meta de 38,5%, blended atual em 34,1%), o QUERY retorna todas as 14 linhas sem nenhuma hardcode:

=QUERY(
  'Vendas'!A:G,
  "SELECT C, SUM(D), SUM(E), (SUM(D)-SUM(E))/SUM(D)
   GROUP BY C
   ORDER BY (SUM(D)-SUM(E))/SUM(D) DESC
   LABEL C 'SKU', SUM(D) 'Receita', SUM(E) 'CMV'",
  1
)

A expressão de margem (SUM(D)-SUM(E))/SUM(D) não dispara erro de agrupamento porque todos os componentes são agregados. Um valor por grupo, sempre. O SUMIFS exigiria uma linha fixa por SKU, o que quebra no momento em que um novo SKU aparece na base.

Os casos de borda que pegam de surpresa

Labels: A cláusula LABEL por si só não causa erros de agrupamento, mas renomear uma coluna já problemática no SELECT desloca a mensagem de erro de um jeito que parece problema de label. Sempre audite SELECT e GROUP BY antes de mexer em LABEL.

COUNT() vs. COUNT(coluna): COUNT(D) conta os valores não nulos na coluna D. COUNT() sem argumento não é válido na implementação do Google. Em junho de 2026, isso às vezes aparece como cannot group without agg em vez de uma mensagem mais específica, o que desperdiça tempo de depuração. Se você está vendo o erro e o agrupamento parece correto, verifique a sintaxe do COUNT.

Expressões entre grupos: SUM(D)/COUNT(D) é válido (ambos os componentes são agregados). SUM(D)/D não é (D no denominador não está agregado). A regra se aplica a cada termo de qualquer expressão, não apenas a referências de coluna isoladas.

O ModelMonkey identifica esse tipo de erro do QUERY antes de gravar na planilha e sugere a fórmula corrigida diretamente na barra lateral. Isso é especialmente útil quando você está 6 níveis dentro de um modelo com múltiplas abas e a mensagem de erro sozinha não indica qual coluna é a responsável.

Perguntas frequentes

O erro cannot group without agg aparece só com GROUP BY? Sim. Ele é exclusivo de consultas que usam GROUP BY. Se a sua consulta não tem GROUP BY, o QUERY não exige agregação e a mensagem não aparece. O erro é sempre sinal de que há pelo menos uma coluna no SELECT que não é dimensão nem medida dentro do contexto da agregação definida.

Posso usar mais de uma função de agregação na mesma consulta? Sim, e é o uso mais comum. SELECT B, SUM(D), AVG(D), MAX(D) GROUP BY B é perfeitamente válido. Cada coluna numérica pode receber funções de agregação diferentes na mesma instrução SELECT, desde que a dimensão (B) apareça no GROUP BY.

Por que o QUERY não aceita referências a outras abas dentro da string de consulta? A linguagem de consulta da Google Visualization API opera sobre o intervalo de dados declarado no primeiro argumento da função. Ela não enxerga células fora desse intervalo. Para filtros com valores dinâmicos de outras abas (como datas de uma aba de premissas), use SUMIFS, SUMPRODUCT ou concatene o valor na string de consulta, lembrando que datas exigem formatação cuidadosa nesse caso.

A cláusula LABEL interfere no agrupamento? Não diretamente. O LABEL apenas renomeia colunas no cabeçalho do resultado e é processado depois do agrupamento. O problema é que, quando há um erro de agrupamento em uma coluna também referenciada no LABEL, a mensagem de erro pode parecer vir do LABEL, dificultando a depuração. A ordem de auditoria correta é sempre: SELECT, GROUP BY, WHERE, ORDER BY e, por último, LABEL.

Qual é a diferença entre cannot group without agg e #VALUE! no QUERY? cannot group without agg é específico de violações da regra GROUP BY. #VALUE! costuma indicar incompatibilidade de tipo de dados (por exemplo, tentar somar uma coluna de texto) ou sintaxe malformada na string de consulta. Se você ver #VALUE!, verifique tipos de coluna e aspas na string antes de suspeitar do GROUP BY.

Resumindo

O erro cannot group without agg significa que uma ou mais colunas do SELECT não estão agregadas e não estão no GROUP BY. Audite cada coluna: dimensões vão no GROUP BY, medidas recebem SUM, AVG, COUNT, MAX ou MIN. Para trabalho entre abas ou intervalos de datas dinâmicos vindos de uma aba de premissas, o SUMIFS resolve o que o QUERY não consegue. Para conjuntos de dimensões dinâmicos, onde você não conhece os valores com antecedência, o GROUP BY do QUERY é a escolha mais limpa.