Función QUERY en Excel: FILTER, UNIQUE y SORTBY

Vale la pena aclarar un contexto antes de entrar al detalle técnico: muchos analistas no migran definitivamente de Sheets a Excel, sino que viven en los dos entornos según el cliente. El modelo base va a Excel para la presentación formal al banco, pero los dashboards operativos y las extracciones diarias corren en Sheets con QUERY. Este artículo no asume una migración definitiva. Lo que sí asume es que en algún punto tienes fórmulas QUERY de Sheets que necesitas replicar en Excel, o que quieres construir en Excel patrones con la misma flexibilidad que QUERY ofrece en Sheets.

Los 4 patrones de QUERY que los analistas de FP&A usan con mayor frecuencia son WHERE, ORDER BY, SELECT DISTINCT y GROUP BY. Excel maneja 3 de ellos de forma limpia y uno requiere una solución alternativa con una pieza de verificación obligatoria. Esto es lo que luce cada reemplazo cuando los datos son reales.

QUERY vs. Excel: tabla de referencia rápida

Según el Google Visualization API Reference, QUERY usa "un lenguaje de consulta similar a SQL" con 12 cláusulas soportadas. La arquitectura de matrices dinámicas de Excel cubre 8 de ellas de forma confiable a partir de julio de 2026.

Restricción de versión: lee esto antes de construir cualquier cosa

FILTER, SORT, SORTBY y UNIQUE requieren Excel 365 o Excel 2021. No están disponibles en Excel 2019 ni en versiones anteriores. Según Microsoft Support: Dynamic array formulas in Excel, estas funciones se introdujeron en Excel 365 a partir de 2019 y las licencias perpetuas de Excel 2021 las incorporaron en octubre de ese año.

Si construyes un modelo con FILTER y lo abres en una instalación de Excel 2019, cada fórmula de matriz dinámica aparece como #NAME?. No hay advertencia, no hay degradación parcial: simplemente todo falla.

Antes de diseñar la arquitectura del modelo, confirma en qué versión va a vivir el archivo. Si el receptor (banco, firma de auditoría, corporativo con TI conservadora) está en 2019 o anterior, ve directamente a la sección "La restricción de versión" al final de este artículo. Los patrones de esta sección son para Excel 365 y 2021. La única excepción es SUMIFS, que funciona de forma idéntica en todas las versiones desde Excel 2007 y es la base segura para cualquier agregación en modelos que viajan a entornos con versiones antiguas.

La pestaña Supuestos: el punto de control del modelo

Antes de entrar a cada patrón, conviene mostrar la estructura que hace que todo funcione en conjunto. La mayoría de los ejemplos de este artículo hacen referencia a tres celdas en una pestaña llamada Supuestos. Esa pestaña no es opcional: es lo que convierte un conjunto de fórmulas independientes en un modelo donde cambiar la entidad o el período actualiza todo de una sola vez.

La estructura mínima de Supuestos para que los patrones de este artículo funcionen:

Tres celdas con entrada libre. Agregar validación de lista en B4 con los nombres exactos de entidad que aparecen en el libro mayor evita errores de tipeo que son difíciles de detectar: si el nombre en B4 no coincide exactamente con el que está en la columna de entidad del libro mayor, el FILTER devuelve cero filas sin ningún mensaje de error.

Para que los nombres de celda sean legibles en las fórmulas, define nombres de rango en Fórmulas > Administrador de nombres:

• Entidad apuntando a Supuestos!$B$4
• Inicio_Periodo apuntando a Supuestos!$C$3
• Fin_Periodo apuntando a Supuestos!$D$3

Con esos nombres definidos, cada FILTER del modelo se escribe así:

=FILTER(
  rango_datos,
  (columna_entidad = Entidad) *
  (columna_fecha >= Inicio_Periodo) *
  (columna_fecha <= Fin_Periodo)
)

En lugar de llenar las fórmulas con referencias cruzadas como Supuestos!$B$4 en cada argumento. La lectura mejora y el riesgo de anclar mal una referencia baja considerablemente.

Un detalle que genera errores silenciosos: si Entidad contiene espacios al final (algo que ocurre cuando el valor viene de un sistema ERP como SAP y se pegó sin limpiar), la comparación = Entidad falla sin avisar. Agrega una celda de verificación en Supuestos que muestre =LARGO(B4) junto a la celda de entidad. Si el largo no corresponde al nombre esperado, hay un espacio oculto. Es un problema que parece trivial hasta que pasas 40 minutos revisando por qué el FILTER devuelve cero filas con un nombre que visualmente "se ve igual" al de los datos.

WHERE → FILTER (con selección de columnas)

FILTER devuelve filas completas. QUERY te permite especificar columnas directamente: SELECT B, D, F WHERE.... FILTER no lo hace.

La solución es CHOOSE con una constante de matriz para seleccionar columnas específicas antes o después de que FILTER evalúe. Para un detalle de ingresos que filtra contratos ARR superiores a $500,000 USD:

=FILTER(
  CHOOSE({1,2,3},
    'Detalle Ingresos'!B2:B5000,
    'Detalle Ingresos'!D2:D5000,
    'Detalle Ingresos'!F2:F5000),
  ('Detalle Ingresos'!C2:C5000 = Entidad) *
  ('Detalle Ingresos'!F2:F5000 >= 500000)
)

El operador * aplica lógica AND. El + aplica lógica OR. Para filtros con múltiples condiciones que cruzan pestañas hacia Supuestos:

=FILTER(
  CHOOSE({1,2,3,4},
    'Libro Mayor'!A2:A10000,
    'Libro Mayor'!C2:C10000,
    'Libro Mayor'!D2:D10000,
    'Libro Mayor'!F2:F10000),
  ('Libro Mayor'!B2:B10000 = Entidad) *
  ('Libro Mayor'!E2:E10000 >= Inicio_Periodo) *
  ('Libro Mayor'!E2:E10000 <= Fin_Periodo)
)

Con los nombres de rango definidos, la intención de cada condición es legible sin necesidad de navegar a la pestaña Supuestos para entender qué hace cada referencia. Este es el tipo de legibilidad que importa cuando un auditor revisa el modelo a las 11 de la noche antes del cierre.

FILTER con referencias cruzadas entre Estado de Resultados, Balance y Flujo de Efectivo

Los ejemplos de una sola pestaña son el caso fácil. La complejidad real aparece cuando FILTER necesita consolidar datos de tres pestañas con distinto layout y lógica de fecha diferente en cada una. El patrón es VSTACK para apilar los tres resultados antes de presentarlos, manteniendo el mismo filtro de entidad y período en las tres fuentes.

Para un reporte de varianza Q2 que cruza P&L, Balance General y Flujo de Efectivo:

=VSTACK(
  IFERROR(
    FILTER(
      CHOOSE({1,2,3,4},
        'P&L'!A2:A3000, 'P&L'!B2:B3000,
        'P&L'!D2:D3000, 'P&L'!E2:E3000),
      ('P&L'!C2:C3000 = Entidad) *
      ('P&L'!B2:B3000 >= Inicio_Periodo) *
      ('P&L'!B2:B3000 <= Fin_Periodo)
    ),
    CHOOSE({1,2,3,4}, "", "", "", "")
  ),
  IFERROR(
    FILTER(
      CHOOSE({1,2,3,4},
        'Balance'!A2:A2000, 'Balance'!B2:B2000,
        'Balance'!D2:D2000, 'Balance'!E2:E2000),
      ('Balance'!C2:C2000 = Entidad) *
      ('Balance'!B2:B2000 >= Inicio_Periodo) *
      ('Balance'!B2:B2000 <= Fin_Periodo)
    ),
    CHOOSE({1,2,3,4}, "", "", "", "")
  ),
  IFERROR(
    FILTER(
      CHOOSE({1,2,3,4},
        'Flujo Efectivo'!A2:A2000, 'Flujo Efectivo'!B2:B2000,
        'Flujo Efectivo'!D2:D2000, 'Flujo Efectivo'!E2:E2000),
      ('Flujo Efectivo'!C2:C2000 = Entidad) *
      ('Flujo Efectivo'!B2:B2000 >= Inicio_Periodo) *
      ('Flujo Efectivo'!B2:B2000 <= Fin_Periodo)
    ),
    CHOOSE({1,2,3,4}, "", "", "", "")
  )
)

Cambias Entidad, Inicio_Periodo o Fin_Periodo en Supuestos y los tres bloques se actualizan simultáneamente. Ese es el reporte que el CFO pide volver a correr para otra filial 20 minutos antes de la junta: con esta estructura, son 3 segundos de trabajo y ninguna posibilidad de olvidar actualizar uno de los tres bloques por separado.

Dos puntos críticos para que esto no falle. Primero: los tres CHOOSE deben devolver exactamente el mismo número de columnas o VSTACK arroja #VALUE!. Si el layout de Balance tiene columnas de apertura adicionales que no están en P&L, hay que homologar los CHOOSE manualmente antes de apilar. Segundo: si alguna de las tres pestañas devuelve cero filas (por ejemplo, Flujo de Efectivo aún no tiene datos del trimestre), VSTACK sin IFERROR falla completamente. Por eso cada bloque lleva su propio IFERROR con un CHOOSE de celdas vacías como fallback, que mantiene la estructura de columnas intacta aunque no haya datos.

ORDER BY → SORTBY

SORT maneja orden ascendente o descendente por una sola columna. SORTBY es lo que necesitas cuando la clave de orden no aparece en tu salida, algo que ocurre constantemente en tablas de margen de contribución, rankings de oportunidades comerciales y resúmenes de rendimiento por SKU.

Para ordenar SKUs activos por margen bruto descendente y mostrar solo nombre e ingresos:

=SORTBY(
  FILTER(
    CHOOSE({1,2}, 'Detalle SKU'!A2:A500, 'Detalle SKU'!C2:C500),
    'Detalle SKU'!E2:E500 = "Activo"
  ),
  FILTER('Detalle SKU'!D2:D500, 'Detalle SKU'!E2:E500 = "Activo"),
  -1
)

El arreglo de orden debe coincidir fila por fila con el arreglo de salida. El FILTER interno sobre la clave de orden tiene que usar exactamente la misma condición que el externo, o recibirás un error #VALUE!. Ese es el principal punto de falla aquí: si agregas una condición al FILTER exterior y olvidas replicarla en el FILTER de la clave de orden, los resultados se ordenan con el valor equivocado.

SELECT DISTINCT → UNIQUE

El SELECT DISTINCT de QUERY es UNIQUE en Excel, y se combina de forma más limpia.

Una lista dinámica de dimensiones para un reporte de varianzas por centro de costo, ordenada alfabéticamente:

=SORT(UNIQUE('Libro Mayor'!D2:D10000))

Dos funciones. En QUERY escribirías SELECT DISTINCT D ORDER BY D y aun así tendrías que manejar la fila de encabezado por separado.

Donde UNIQUE demuestra su valor en un modelo real es al generar las etiquetas de fila para una tabla resumen que se expande automáticamente cuando aparecen nuevos centros de costo en el libro mayor. Sin necesidad de actualizar una tabla dinámica, sin listas codificadas a mano, sin referencias rotas cuando finanzas agrega un nuevo departamento a mitad del año.

GROUP BY: el patrón más frágil (y cómo protegerlo)

Aquí es donde la analogía con QUERY se rompe de forma importante. El GROUP BY con agregación de QUERY es una sola fórmula atómica: si hay un error, hay un error. El equivalente en Excel son dos fórmulas independientes que deben mantenerse sincronizadas. Esa diferencia no es solo estética: es un riesgo real en un modelo con 8 pestañas vinculadas donde el auditor va a rastrear cada línea de EBITDA por unidad de negocio cruzando contra el balance.

El patrón: UNIQUE genera la lista de dimensiones y SUMIFS con una referencia de desbordamiento hace la agregación.

En la columna A (etiquetas de dimensión, se despliegan automáticamente hacia abajo):

=SORT(UNIQUE('Libro Mayor'!B2:B3000))

En la columna B (EBITDA agregado, una sola fórmula que cubre toda la columna):

=SUMIFS('Libro Mayor'!F2:F3000, 'Libro Mayor'!B2:B3000, A2#)

La referencia de desbordamiento A2# es la clave. SUMIFS evalúa contra cada valor del rango de desbordamiento y devuelve un arreglo con un resultado por unidad de negocio. Esto replica SELECT B, SUM(F) GROUP BY B ORDER BY B con 2 fórmulas en lugar de 1.

La advertencia que el patrón requiere: desincronización silenciosa

Si modificas el rango del UNIQUE (por ejemplo, extiendes de B2:B3000 a B2:B5000 porque el libro mayor creció) y olvidas actualizar el rango de 'Libro Mayor'!F2:F3000 y 'Libro Mayor'!B2:B3000 en el SUMIFS, las dos fórmulas quedan apuntando a rangos de distinto tamaño. El SUMIFS no arroja ningún error: sigue calculando, pero sobre un subconjunto de los datos. El resultado es un descuadre silencioso que solo detectas si los totales no cierran.

A diferencia de un FILTER con condición incorrecta (que devuelve cero filas y es obvio), este tipo de error produce números que parecen razonables. Eso lo hace especialmente peligroso en un modelo de múltiples pestañas.

La solución es agregar una celda de verificación en la pestaña Supuestos que compare el total del GROUP BY contra una suma directa con las mismas condiciones:

-- Celda de verificación en Supuestos (por ejemplo, F10):
=SI(
  SUMA('Resumen EBITDA'!B2#) =
  SUMIFS(
    'Libro Mayor'!F2:F3000,
    'Libro Mayor'!E2:E3000, ">=" & Inicio_Periodo,
    'Libro Mayor'!E2:E3000, "<=" & Fin_Periodo
  ),
  "GROUP BY OK",
  "DESCUADRE: verificar rangos de UNIQUE y SUMIFS"
)

La lógica es simple: si la suma de todos los valores agrupados no coincide con la suma directa del mismo campo con las mismas condiciones de período, algo está mal. Esta verificación tarda microsegundos en recalcular y hace que el descuadre sea visible antes de que el modelo salga del equipo.

Coloca esta celda en un lugar visible de Supuestos, con formato condicional que la pinte en rojo cuando el valor sea diferente de "GROUP BY OK". Si el modelo va a due diligence o a revisión de auditoría, ese semáforo en Supuestos es la primera cosa que demuestra que el modelo tiene controles internos, no solo fórmulas.

Para un GROUP BY con múltiples condiciones (por ejemplo, EBITDA por entidad y categoría de costo extrayendo cifras reales de una pestaña de P&L con más de 5,000 filas):

=SUMIFS(
  'P&L'!D2:D5000,
  'P&L'!B2:B5000, Dimensiones!A2#,
  'P&L'!C2:C5000, ">=" & Inicio_Periodo,
  'P&L'!C2:C5000, "<=" & Fin_Periodo,
  'P&L'!E2:E5000, "Gasto Operativo"
)

Es más verbosa que QUERY, pero más auditable: cada condición es visible y tu revisor puede rastrear cada argumento sin ejecutar la fórmula en un entorno de prueba. Para equipos donde el CFO o los auditores conocen SUMIFS pero no la sintaxis de QUERY, esa diferencia importa en una revisión de cierre. Lo que no es negociable es agregar la celda de verificación descrita arriba cada vez que uses este patrón en un modelo que va a manos de terceros.

Rendimiento: la pregunta que tu jefe va a hacer

Cuando alguien en finanzas ve una fórmula matricial sobre 10,000 filas, la primera pregunta no es sobre la lógica: es sobre cuánto tarda en recalcular. La respuesta honesta depende del patrón que estés usando.

SUMIFS es rápido. Excel tiene SUMIFS indexado internamente. Sobre 50,000 filas con 4 condiciones, el tiempo de recálculo en un equipo corporativo promedio ronda los 20-50 milisegundos. Para modelos donde todas las agregaciones usan SUMIFS, el recálculo del libro completo es prácticamente imperceptible.

FILTER sobre rangos grandes es lento. FILTER tiene que evaluar cada fila del rango en cada recálculo. Un FILTER sobre 50,000 filas tarda aproximadamente 200-400 milisegundos en un equipo típico. Parece poco, pero con 15 FILTERs en un modelo de 10 pestañas que recalcula automáticamente ante cualquier cambio, el tiempo de espera acumulado se vuelve frustrante en sesiones de trabajo largas.

El VSTACK con tres FILTERs aplicado sobre rangos de 3,000-5,000 filas por fuente produce tiempos de recálculo de 1 a 3 segundos en hardware corporativo estándar. Para un reporte que se corre una vez por trimestre para presentarlo al consejo, ese tiempo es irrelevante. Para un dashboard que alguien actualiza 40 veces al día, no lo es.

Recomendaciones prácticas:

• Usa SUMIFS/COUNTIFS/AVERAGEIFS para todas las agregaciones. Reserva FILTER para cuando realmente necesitas los registros individuales completos, no solo totales.
• Evita colocar funciones volátiles (INDIRECTO, DESREF, HOY()) dentro del argumento de condición de un FILTER. Eso fuerza el recálculo completo de toda la fórmula ante cualquier cambio en el libro, no solo ante cambios en los datos relevantes.
• Limita los rangos de FILTER al tamaño real de los datos más un margen razonable. B2:B5000 sobre una tabla que nunca va a superar 3,000 filas es mejor que B:B sobre toda la columna. La diferencia en velocidad es significativa y escala mal.
• Para modelos que se van a distribuir y donde otros trabajarán durante sesiones largas, considera cambiar el modo de cálculo a manual en Fórmulas > Opciones de cálculo > Manual. Documenta que el atajo para recalcular es Ctrl+Alt+F9. Es incómodo explicarlo la primera vez, pero evita conversaciones sobre por qué el archivo "está lento".

La restricción de versión (y por qué la alternativa de Excel 2019 no es realmente equivalente)

Para entornos donde el modelo debe abrirse en Excel 2019 o anterior (algo común en banca donde la política de TI puede estar 3 o más años detrás de la versión actual), el patrón alternativo con columna auxiliar, SMALL e INDEX existe y es técnicamente correcto:

-- Columna auxiliar oculta (col. Z): marca las filas que cumplen las 3 condiciones
=SI(('Libro Mayor'!B2 = Entidad) *
    ('Libro Mayor'!E2 >= Inicio_Periodo) *
    ('Libro Mayor'!E2 <= Fin_Periodo), FILA(A2), "")

-- Tabla de salida (requiere Ctrl+Shift+Enter como fórmula matricial):
=SIERROR(INDICE('Libro Mayor'!A:A,
  K.ESIMO.MENOR(SI('Libro Mayor'!Z$2:Z$10000<>"",
    'Libro Mayor'!Z$2:Z$10000), FILA(A1))), "")

Pero hay que ser directo sobre sus limitaciones reales, porque presentarlo como una alternativa casi equivalente es incorrecto.

Es 3 veces más lenta en recálculo sobre 50,000 filas. El patrón SMALL+INDEX no está optimizado internamente como FILTER. En archivos con muchas filas, el tiempo de recálculo es notablemente mayor y el problema se multiplica con cada tabla adicional.

Se rompe si alguien inserta una fila en el medio del rango. La columna auxiliar usa FILA() para marcar posiciones. Si alguien inserta una fila entre la fila 500 y 501, los números de FILA() de todas las filas siguientes cambian y los resultados en la tabla de salida dejan de coincidir con los datos originales. El error es silencioso: la fórmula no arroja #VALUE!, simplemente muestra datos incorrectos.

Requiere Ctrl+Shift+Enter para cada celda de la tabla de salida. En un modelo que va a due diligence donde alguien más va a editarlo, es fácil olvidar este requisito al modificar una fórmula, lo que produce un resultado incorrecto sin ninguna advertencia visible.

Para modelos que van a un consorcio bancario o a un proceso de due diligence con una institución cuya TI está en 2018-2019, la recomendación correcta no es SMALL+INDEX. La recomendación es Power Query. Power Query está disponible desde Excel 2016, es robusto con 50,000 filas, no se rompe ante inserciones de filas y produce resultados que cualquier auditor puede rastrear paso a paso en el editor de consultas. La curva de aprendizaje es mayor, pero para un modelo que va a manos de terceros en un proceso formal, es la herramienta adecuada.

La única restricción de compatibilidad que sí vale tolerar en Excel 2019 es para agregaciones GROUP BY: SUMIFS funciona de forma idéntica en todas las versiones desde Excel 2007 y no tiene ninguno de los problemas mencionados.

Lo que QUERY hace y Excel todavía no replica bien

Dos patrones no se traducen fácilmente:

Columnas calculadas en línea. QUERY permite SELECT A, B*C AS margen_bruto WHERE... y devuelve la columna calculada en la salida. FILTER solo devuelve valores almacenados. Necesitas una columna auxiliar, o bien BYROW/LAMBDA, que funciona en Excel 365 pero no es práctica estándar en la mayoría de los modelos de FP&A a mediados de 2026.

La cláusula PIVOT. QUERY puede transponer valores de fila a encabezados de columna de forma dinámica. No hay equivalente en Excel sin recurrir a VBA o Power Query. Si tu QUERY hacía pivote cruzado en línea, ese es el caso de uso que genuinamente no tiene un reemplazo limpio con fórmulas estándar de Excel. Las alternativas con fórmulas puras implican siempre algún compromiso: o pierdes la actualización dinámica, o necesitas una macro, o dependes de Power Query. No existe una cuarta opción.

Cómo migrar fórmulas QUERY a Excel (o mantener los dos entornos)

Si trabajas en los dos entornos según el cliente, el patrón más común no es una migración única sino una traducción caso por caso: el modelo base vive en Excel para la presentación formal, y los dashboards operativos o las extracciones diarias corren en Sheets con QUERY. En ese flujo, lo que necesitas es poder replicar rápidamente en Excel la lógica que ya construiste en Sheets, sin dedicar horas a reescribir fórmulas manualmente.

Si estás migrando un modelo de Sheets con 15 a 20 fórmulas QUERY a Excel, el trabajo de traducción es mecánico pero tedioso. Cada fórmula debe descomponerse en operaciones individuales, las selecciones de columnas reescribirse con arreglos CHOOSE y la lógica de GROUP BY dividirse en pares UNIQUE + SUMIFS (con su celda de verificación correspondiente). En modelos de múltiples pestañas, también hay que decidir si consolidar con VSTACK o mantener FILTERs independientes por pestaña, según si el layout de columnas es homogéneo entre fuentes.

Para una migración completa que a un analista senior le tomaría entre 2 y 3 horas hacer con cuidado, puedes describir el QUERY que tenías en Sheets y obtener el equivalente con FILTER/SORT/UNIQUE ajustado a tu estructura de datos y pestañas en minutos, sin salir de la hoja de cálculo. Elige un plan de ModelMonkey: funciona tanto en Google Sheets como en Excel.

Preguntas frecuentes sobre la función QUERY en Excel

¿Puede Excel reemplazar completamente la función QUERY de Google Sheets?

Parcialmente. Excel 365 replica de forma confiable las cláusulas WHERE (con FILTER), ORDER BY (con SORTBY), SELECT DISTINCT (con UNIQUE) y GROUP BY con agregación (con UNIQUE + SUMIFS). Las dos cláusulas que no tienen equivalente directo en fórmulas estándar son PIVOT, que en Excel requiere VBA o Power Query, y las columnas calculadas en línea como SELECT A, B*C AS margen WHERE..., que en Excel 365 necesitan BYROW o LAMBDA pero no son práctica común en modelos de FP&A. Para el 80% de los casos de uso de analistas financieros, la combinación FILTER/SORTBY/UNIQUE/SUMIFS cubre el trabajo.

¿Qué versión de Excel necesito para usar FILTER, UNIQUE y SORTBY en lugar de QUERY?

Necesitas Excel 365 (cualquier plan activo de Microsoft 365) o Excel 2021 con licencia perpetua. Estas funciones de matrices dinámicas no están disponibles en Excel 2019, Excel 2016 ni versiones anteriores. Si tu modelo debe abrirse en entornos con versiones antiguas (común en banca, sector público o corporativos con políticas de TI conservadoras), la alternativa más robusta es Power Query para filtrado dinámico de filas, y SUMIFS para agregaciones. El patrón SMALL+INDEX con columna auxiliar funciona técnicamente pero es significativamente más lento, se rompe ante inserciones de filas y no es adecuado para modelos que van a manos de terceros.

¿Cómo reemplazar el GROUP BY de QUERY en Excel?

Con dos fórmulas que deben mantenerse sincronizadas, más una celda de verificación obligatoria. Primero, UNIQUE genera la lista de valores únicos de la dimensión que usarías en GROUP BY. Segundo, SUMIFS apunta a esa lista con una referencia de desbordamiento para calcular el agregado por cada valor. Ejemplo: si UNIQUE en A2 devuelve la lista de unidades de negocio, entonces =SUMIFS(F:F, B:B, A2#) en B2 calcula la suma de F para cada unidad automáticamente. La referencia A2# hace que SUMIFS evalúe contra todo el rango de desbordamiento de UNIQUE. El riesgo principal es que si modificas el rango en alguna de las dos fórmulas y olvidas actualizar la otra, obtienes un descuadre silencioso. Agrega siempre una celda de verificación que compare el total del GROUP BY contra una suma directa con las mismas condiciones.

¿Qué hago si mi modelo de Excel debe abrirse en versiones anteriores a Excel 2021?

Para agregaciones, SUMIFS es la base: funciona igual en todas las versiones desde Excel 2007 y es rápido. Para filtrado dinámico donde necesitas extraer filas completas, Power Query es el reemplazo más robusto en entornos corporativos con versiones antiguas: está disponible desde Excel 2016, no se rompe ante inserciones de filas y es auditable paso a paso. El patrón de SMALL+INDEX con columna auxiliar es un recurso de último recurso: funciona en Excel 2019, pero es 3 veces más lento en recálculo con 50,000 filas, se rompe si alguien inserta una fila en el rango de datos y requiere Ctrl+Shift+Enter en cada celda de salida, un requisito fácil de perder al editar. No es una opción adecuada para un modelo que va a due diligence o a manos de terceros.

¿Cómo afectan las fórmulas matriciales al rendimiento del modelo?

SUMIFS sobre 50,000 filas recalcula en 20-50 milisegundos en hardware corporativo promedio. FILTER sobre el mismo rango tarda 200-400 milisegundos. La diferencia parece pequeña, pero con 15 FILTERs en un modelo de 10 pestañas, el tiempo de espera acumulado en sesiones de trabajo largas es perceptible. Usa FILTER solo cuando necesitas los registros individuales completos; para agregaciones, SUMIFS/COUNTIFS son siempre la opción más rápida. Evita funciones volátiles (INDIRECTO, DESREF, HOY()) dentro de los argumentos de FILTER porque fuerzan recálculo completo ante cualquier cambio en el libro. Si el modelo es muy pesado, el modo de cálculo manual con Ctrl+Alt+F9 para recalcular a demanda es una solución práctica que vale documentar en la hoja de instrucciones del archivo.