La fórmula QUERY es lo más parecido a SQL que tiene Google Sheets - y para trabajo de FP&A, eso importa más de lo que la mayoría de los analistas reconoce. Un solo =QUERY() puede reemplazar una pila de SUMIFS anidados, devolver una vista filtrada de P&L sobre 10,000 filas y ordenarla, todo desde una sola celda. La sintaxis corresponde al dialecto SQL de la Google Visualization API, no SQL estándar, pero una vez que entendés las diferencias es más rápido de escribir que casi cualquier alternativa con fórmulas.
Esto no es un repaso de sintaxis. Es sobre dónde QUERY realmente se gana su lugar en un modelo financiero, dónde falla y cuándo conviene usar otra herramienta.
Lo que QUERY hace y SUMIFS no puede
SUMIFS agrega. QUERY devuelve filas. Esa es la diferencia central, y determina qué herramienta corresponde a cada situación.
Cuando estás armando una vista de margen de contribución por línea de producto para el reporte de directorio, SUMIFS te obliga a escribir una fórmula por métrica por fila. QUERY te permite devolver el segmento completo de una sola vez: todas las filas donde linea_producto = "Empresarial", ordenadas por ingreso descendente, con una fila de encabezado. El resultado se despliega automáticamente, lo que significa que se actualiza cada vez que cambia la fuente de datos.
Según la documentación oficial de la Google Visualization API Query Language, QUERY ejecuta "una consulta sobre los datos usando el lenguaje de consulta de la Google Visualization API." Ese lenguaje soporta SELECT, WHERE, GROUP BY, ORDER BY, LIMIT y LABEL - aproximadamente el 80% de lo que necesitarías en una consulta de reporte.
Sintaxis multipestaña para modelos complejos
La parte que la mayoría de los tutoriales omite: referenciar otra pestaña. La sintaxis requiere envolver el rango dentro del llamado a la función:
=QUERY('P&L'!A:H, "SELECT A, B, C, SUM(F) WHERE B = 'Empresarial' GROUP BY A, B, C LABEL SUM(F) 'Ingresos'", 1)
El tercer argumento (1) le indica a QUERY cuántas filas de encabezado tiene la fuente. Si lo omitís, los resultados incluyen el encabezado como fila de datos, lo que rompe las agregaciones.
Para un modelo donde los Supuestos manejan todo, un filtro de fecha dinámico se ve así:
=QUERY('P&L'!A:H, "SELECT A, B, SUM(F) WHERE A >= date '"&TEXT(Supuestos!$B$3,"yyyy-mm-dd")&"' GROUP BY A, B", 1)
El formato de fecha es crítico aquí. Los literales de fecha en QUERY necesitan yyyy-mm-dd entre comillas simples dentro del string SQL. Un formato incorrecto devuelve un error de parseo que parece un problema de datos hasta que te ponés a depurarlo.
Cláusulas WHERE para filtrado dinámico
La cláusula WHERE soporta AND, OR y NOT. Para un análisis de variación donde querés reales vs. presupuesto del Q1 2026 filtrado a un centro de costos específico:
=QUERY('Detalle GL'!A:J, "SELECT B, D, SUM(G), SUM(H) WHERE C = 'CC-412' AND A >= date '2026-01-01' AND A <= date '2026-03-31' GROUP BY B, D ORDER BY SUM(G) DESC", 1)
Esto devuelve departamento, cuenta, real y presupuesto para un centro de costos durante el Q1 - ordenado por gasto real para que las mayores variaciones aparezcan primero. El equivalente en SUMIFS serían 4 fórmulas por fila, replicadas en cada código contable que te interese.
Una restricción no tan obvia: QUERY no puede referenciar rangos con nombre dentro del string SQL. La referencia a columnas debe ser una letra (A, B, C) o la notación Col1, Col2. Los rangos con nombre funcionan como argumento de fuente de datos, pero no dentro del string de consulta. Esto atrapa a mucha gente cuando intentan algo como WHERE cuenta = RangoNombrado - falla silenciosamente y devuelve todo.
Agregaciones y GROUP BY
El GROUP BY de QUERY reemplaza las tablas dinámicas para salida programática. La regla: toda columna en SELECT que no sea una función de agregación debe aparecer en GROUP BY. Si la violás, obtenés un error del tipo "La columna X no puede estar agregada y no agregada al mismo tiempo."
Funciones de agregación disponibles: SUM, COUNT, AVG, MAX, MIN. Sin MEDIAN, sin STDEV, sin funciones de percentil - ese es el límite. Para cualquier cálculo más allá de estas cinco, tendrás que post-procesar la salida de QUERY con fórmulas adicionales o usar ARRAYFORMULA con funciones más granulares.
A abril de 2026, Google no ha extendido el conjunto de funciones de agregación de QUERY desde 2018. Si necesitás la mediana del EBITDA por trimestre, usá QUERY para extraer y ordenar las filas, y luego aplicá MEDIAN al rango resultante con una fórmula auxiliar.
LABEL, FORMAT y control de salida
Dos cláusulas que rara vez aparecen en tutoriales pero que importan cuando el output va directo a una presentación para directorio o un reporte para inversionistas:
LABEL renombra los encabezados de columna en el resultado. Sin ella, las columnas agregadas heredan nombres como SUM Revenue o avg(E), aceptable para trabajo interno y poco presentable en un PDF exportado para un pitch deck.
=QUERY('Ingresos'!A:F, "SELECT A, B, SUM(C) GROUP BY A, B LABEL A 'Período', B 'Segmento', SUM(C) 'Ingresos Netos ($000s)'", 1)
FORMAT aplica un formato de visualización a la salida, usando los mismos strings de formato que TEXT(). Para columnas de valores en un reporte financiero:
"... LABEL SUM(C) 'Ingresos Netos' FORMAT SUM(C) '$#,##0'"
Esto mantiene el número subyacente como valor numérico - las fórmulas en otras partes del modelo aún pueden referenciarlo - mientras se muestra con formato limpio.
Dónde QUERY falla en la práctica
Tres modos de falla que vale conocer antes de que te sorprendan en un modelo en producción:
Tipos mixtos en una columna. QUERY evalúa el tipo de columna según la mayoría de los valores. Si la columna B es 95% texto pero tiene 5 celdas numéricas, QUERY la trata como texto y omite silenciosamente los números en las comparaciones WHERE. Limpiá los datos fuente o agregá una columna auxiliar que fuerce tipos consistentes.
Celdas en blanco en columnas de fecha. Una celda vacía en una columna de fecha hace que QUERY devuelva un error cuando filtrás por rango de fechas. La solución es filtrar los vacíos con WHERE A IS NOT NULL AND A >= date '...' o asegurarte de que el rango fuente no tenga celdas vacías al final.
Referencias dinámicas a pestañas. No podés referenciar dinámicamente el nombre de una pestaña dentro de QUERY como lo harías con INDIRECT. =QUERY(INDIRECT("'"&A1&"'!A:H"), ...) funciona para el rango, pero el string de consulta aún necesita letras de columna fijas. Para modelos donde la estructura de pestañas cambia, esto hace que QUERY se vuelva frágil de maneras que SUMIFS no lo es.
QUERY vs. SUMIFS: regla de decisión
| Criterio | QUERY | SUMIFS |
|---|---|---|
| Tipo de salida | Múltiples filas y columnas | Un solo valor agregado |
| Ordenamiento de resultados | ORDER BY nativo | Requiere tabla auxiliar |
| Filtros combinados | AND / OR / NOT en un string | Argumentos encadenados, verboso |
| Referencias cruzadas a otras fórmulas | Rango de salida variable | Celda fija, referenciable directamente |
| Rendimiento en rangos grandes | Más lento en hojas con muchos recálculos | Más eficiente por celda individual |
| Actualización automática | Sí, junto con la fuente | Sí, junto con la fuente |
Usá QUERY cuando necesitás filas de vuelta: listas filtradas, cortes dinámicos de reportes, salida ordenada. Usá SUMIFS cuando necesitás un único valor agregado en una celda fija que otras fórmulas referencian. El error clásico es usar SUMIFS para construir lo que en realidad es una tabla filtrada, lo que te obliga a replicar la fórmula hacia abajo por cada fila y a lo largo de cada columna manualmente.
Un modelo de tres estados con una pestaña dedicada Reportes que extrae del Detalle GL es un caso natural para QUERY. La pestaña de reportes se mantiene actualizada automáticamente, LABEL maneja el nombre de columnas y ORDER BY muestra los datos que el CFO realmente quiere ver sin ordenamiento manual.
Si ya estás usando automatización con IA en tu flujo de trabajo de Google Sheets, QUERY combina bien: la IA puede generar o modificar el string SQL mientras deja intacta la estructura de tus fórmulas.
En resumen
La fórmula QUERY maneja salida de filas filtradas, ordenadas y agregadas en una sola expresión. Las referencias entre pestañas funcionan con la sintaxis estándar 'NombrePestaña'!Rango y un argumento de encabezado. Los filtros de fecha requieren formato de string yyyy-mm-dd. Las agregaciones soportan cinco funciones (SUM, COUNT, AVG, MAX, MIN) - nada más allá de eso. Las cláusulas WHERE soportan AND/OR/NOT con IS NULL para manejo de celdas vacías. En modelos de FP&A, QUERY pertenece a las pestañas de reporte y salida; SUMIFS pertenece al motor de cálculo donde valores individuales alimentan fórmulas subsecuentes.
ModelMonkey puede generar e iterar sobre fórmulas QUERY de manera conversacional - útil cuando estás construyendo una vista de reporte nueva y no querés depurar sintaxis de strings SQL a mano. Elige un plan de ModelMonkey - funciona tanto en Google Sheets como en Excel.
Preguntas frecuentes
¿Puedo usar QUERY con datos de múltiples pestañas a la vez?
No directamente. QUERY acepta un único rango como fuente de datos. Para combinar varias pestañas, primero consolidá los datos en una pestaña auxiliar con {Hoja1!A:H; Hoja2!A:H} como array vertical, y luego aplicá QUERY sobre ese rango consolidado.
¿Por qué QUERY devuelve resultados vacíos aunque el rango tenga datos?
Las causas más comunes son: tipos mixtos en columnas (texto mezclado con números), formato de fecha incorrecto en la cláusula WHERE (debe ser yyyy-mm-dd), o el argumento de encabezado incorrecto que hace que QUERY interprete la primera fila de datos como encabezado y la excluya del resultado.
¿QUERY funciona con rangos de columna completos como A:A? Sí, y es la práctica recomendada para modelos que crecen en filas. El rendimiento puede degradarse en hojas con más de 50,000 filas; en ese caso, acotá el rango a las filas efectivamente usadas o considerá importar los datos a BigQuery para análisis a mayor escala.
¿Cuál es la diferencia entre QUERY y FILTER en Google Sheets? FILTER devuelve filas que cumplen una condición booleana, pero no permite ordenar, agregar ni renombrar columnas. QUERY hace todo eso en un solo string SQL. Para filtrado simple sin transformaciones, FILTER es más legible; para reportes que combinan filtrado, agregación y formato, QUERY es más eficiente.
¿Puedo anidar QUERY dentro de otras funciones?
Sí. Un patrón útil en FP&A es =SUM(QUERY(...)) para sumar el total de una columna en los resultados filtrados, o =COUNTA(QUERY(...)) para contar registros que cumplen múltiples condiciones sin escribir COUNTIFS complejos.