Debugging en Power BI: La guía completa

TL;DR

80% de los “bugs” son filtros olvidados, no errores de DAX
Checklist de 2 minutos: filtros de visual → página → informe → slicers → bookmarks
Si los filtros están bien: compara dashboard vs query directa vs origen
La discrepancia suele estar en ETL o definiciones, no en Power BI

La situación

Recibes un mensaje del cliente:

Los números del dashboard no coinciden con el sistema. Estamos viendo 3.039 pedidos pero en el ERP hay 3.134.

Tu primer instinto: revisar la medida DAX.

Para. Respira. No toques nada todavía.

Parte 1: La regla del 80%

El 80% de los “bugs” que me reportan no son bugs. Son filtros olvidados.

El checklist de 2 minutos

Antes de abrir DAX Studio, antes de cuestionar tu modelo:

1. Filtros de visual

Selecciona el visual problemático. Panel de filtros. ¿Hay algo ahí que no debería estar?

2. Filtros de página

Revisa la sección de página en el panel de filtros. ¿Alguien añadió un filtro global a esa página?

3. Filtros de informe

Arriba del todo en el panel de filtros. Afectan a TODO el informe. Son los más traicioneros porque no se ven a simple vista.

4. Slicers

¿Hay slicers con selecciones activas? ¿Hay slicers ocultos? Sí, existen, y sí, alguien los usa.

5. Bookmarks

¿El visual está asociado a un bookmark que tiene filtros guardados? Los bookmarks pueden guardar estado de filtros y activarlo sin que te des cuenta.

Caso real: El filtro fantasma

El gráfico no muestra datos de 2024.

Reviso la medida. Perfecta. Reviso el modelo. Correcto. Reviso los filtros de página. Encuentro:

Filtro de página:
Año is not 2024

Alguien había añadido ese filtro para una demo y lo dejó ahí. Cinco segundos de limpieza, una hora de debugging ahorrada.

La regla: Dedica 2 minutos a revisar filtros antes de dedicar 2 horas a revisar DAX.

Parte 2: Dashboard vs DB vs Origen

Si los filtros están bien, el siguiente paso es localizar DÓNDE está el problema:

Dashboard	Base de Datos	Sistema Origen	El problema está en…
❌	❌	✅	ETL (datos no llegan de origen a DB)
❌	✅	✅	Power BI (medida o modelo incorrecto)
❌	❌	❌	Varios sitios, buena suerte

Paso 1: Query directa a la base de datos

Replica la lógica de tu medida en SQL y ejecútala directamente:

SELECT COUNT(DISTINCT pedido_id) as total
FROM pedidos
WHERE sede = 'SEDE_X'
  AND YEAR(fecha) = 2025
  AND estado = 'COMPLETADO'

Compara el resultado con lo que muestra el dashboard.

Paso 2: Interpretar resultados

Ejemplo típico:

Dashboard mostraba: 3.039
Query directa a DB: 3.089
ERP según cliente: 3.134

Tras actualizar el dashboard: 3.089 = DB. Cero diferencia entre Power BI y la base de datos.

La discrepancia no era Power BI. Era que faltaban registros en la sincronización del ERP a la base de datos.

Paso 3: Investigar el gap

Al analizar los datos del ERP, resultó que había registros con campos nulos que el sistema origen contaba pero que semánticamente no eran “pedidos completados”. No eran errores de ETL, era una diferencia de definición.

Resumen: El flujo de debugging

1. ¿Hay filtros activos?
   → Sí → Revisar si son correctos
   → No ↓

2. ¿Dashboard = Query directa a DB?
   → Sí → El problema está en ETL o en el origen
   → No → El problema está en Power BI (medida o modelo)

3. ¿DB = Sistema Origen?
   → Sí → Diferencia de definiciones o timing
   → No → Problema de sincronización

Las causas más comunes

El 80% de las discrepancias que te reportan NO son problema de Power BI. Son:

Filtros olvidados (el 80% del 80%)
Datos que no han llegado a la DB todavía
Filtros diferentes entre el ERP y tu query
Timing de sincronización (el cliente mira en tiempo real, tú miras un snapshot)
Definiciones distintas de lo que “cuenta” como completado

Antes de tocar DAX, verifica con el checklist de filtros y una query directa. Te ahorrarás horas de debugging innecesario y evitarás “arreglar” algo que no estaba roto.

Si el problema es el modelo y no las medidas, revisa cómo VertiPaq comprime tus datos. Y si después de todo el debugging nadie mira tu dashboard, quizás el problema no era técnico.