🎯 Situación

Durante una reunión de consejo, el CFO de un cliente presentó ingresos de $1.1M para el trimestre. El director de ventas tenía un número diferente — $1.2M — en su presentación. El CEO le pidió a IT que sacara el número "real". IT regresó con $1.15M.

Tres números diferentes. Una sola empresa. Un solo trimestre. Los tres equipos estaban seguros de tener razón.

👉 Todos tenían razón — y ese era exactamente el problema. Cada equipo medía los ingresos de forma diferente, extrayendo de sistemas distintos, aplicando filtros diferentes. Nadie estaba equivocado. Pero nadie coincidía. Y las decisiones se tomaban en la brecha entre esos números.

Este es uno de los problemas de datos más frecuentes y más costosos en empresas en crecimiento. Y SQL es una de las formas más limpias de resolverlo.

⚠️ El reto

Cuando diferentes equipos calculan el mismo KPI de forma independiente, no obtienes una respuesta incorrecta — obtienes varias respuestas defendibles. Cada una tiene su lógica. Ninguna coincide.

📈 Ingresos de ventas ($1.2M)

  • Extraído del CRM: todos los negocios marcados como "Cerrado Ganado"
  • Incluye negocios facturados en T1 pero pagados en T2
  • Usa valor del contrato, no pago recibido
  • Excluye reembolsos procesados después del cierre mensual

📊 Ingresos de finanzas ($1.1M)

  • Extraído del ERP: facturas con pago confirmado
  • Solo efectivo recibido durante el trimestre
  • Incluye reembolsos y notas de crédito
  • Excluye ingresos de contratos diferidos

Ninguna definición es incorrecta. Pero responden preguntas diferentes. El problema no son los datos — es la ausencia de una definición acordada almacenada en un solo lugar del que cada reporte pueda extraer.

🔍 Cómo SQL resuelve esto

Las vistas SQL son la solución estándar a este problema. Una vista es una consulta guardada — un cálculo con nombre que vive en la base de datos y puede ser referenciado por cualquier herramienta que se conecte a ella.

En lugar de que cada equipo escriba su propia versión de "ingresos" en su propia hoja de cálculo o herramienta de BI, se escribe una vez en SQL, se almacena como una vista, y cada dashboard, cada reporte y cada analista usa esa única definición:

CREATE VIEW vw_ingresos_trimestral AS
SELECT
    DATE_TRUNC('quarter', fecha_factura)  AS trimestre,
    SUM(monto_factura)                    AS ingresos_brutos,
    SUM(monto_reembolso)                  AS total_reembolsos,
    SUM(monto_factura - monto_reembolso)  AS ingresos_netos
FROM facturas
WHERE estado_pago = 'confirmado'
  AND fecha_factura >= '2026-01-01'
GROUP BY DATE_TRUNC('quarter', fecha_factura);

Ahora la definición está documentada, versionada y compartida. Ventas, finanzas e IT consultan todos vw_ingresos_trimestral. Si la definición necesita cambiar — digamos que la empresa decide pasar de efectivo a devengo — se actualiza en un solo lugar. Todos los reportes se actualizan automáticamente.

La vista no solo corrige el número — fuerza la conversación de negocio que debería haber ocurrido primero: ¿qué significa exactamente "ingresos" para nosotros? Una vez que esa conversación ocurre y la respuesta está escrita en SQL, el debate se detiene.

✓️ Buena práctica: una capa de KPIs en SQL

El enfoque más robusto es construir una capa de KPIs dedicada en tu base de datos central — un conjunto de vistas que definen cada métrica de negocio en un solo lugar:

  • Una vista por KPI — vw_ingresos, vw_tasa_churn, vw_valor_promedio_pedido, vw_margen_por_producto
  • Nomenclatura consistente — prefijar todas las vistas de KPI con vw_kpi_ para que los analistas sepan exactamente dónde buscar
  • Comentarios en el SQL — documentar la definición de negocio directamente en la consulta usando -- comentarios: qué se incluye, qué se excluye y por qué
  • Power BI se conecta a las vistas — no a las tablas crudas. La capa de BI se mantiene limpia; la lógica vive en SQL

Cuando un nuevo analista se une al equipo, no necesita preguntar "¿cómo calculamos el churn?" — lee vw_kpi_tasa_churn y la respuesta está ahí, con la lógica de negocio documentada en línea.

💡 Síntesis

KPIs diferentes entre equipos no es un problema de calidad de datos — es un problema de definición. Los datos generalmente son correctos. Las definiciones simplemente no están alineadas.

SQL lo resuelve haciendo que la definición sea parte de la infraestructura:

  • Escribir la definición del KPI una sola vez — como una vista SQL en tu base de datos central
  • Tener la conversación de negocio primero — ¿qué significa exactamente "ingresos" para nosotros? Lograr que todos estén de acuerdo antes de escribir una sola línea de código
  • Conectar todos los reportes a la vista — Power BI, Excel, cualquier herramienta que consulte la base usa la misma fuente
  • Versionarla y documentarla — si la definición cambia, actualizar la vista y documentar por qué

El debate en la reunión de consejo sobre los ingresos no es un problema tecnológico. Es un problema de gobernanza que la tecnología puede hacer cumplir una vez que la empresa ha decidido cuál debe ser la respuesta.

👉 Cuando dos personas miran los mismos datos y ven números diferentes, el problema no son los datos.

Es la ausencia de una definición compartida. SQL es donde la escribes.