Dirección comercial ve pedidos por un importe; tesorería muestra cobros por otro; el informe financiero presenta ingresos distintos. La diferencia puede ser correcta: cada vista mide un hecho y utiliza una fecha propios.
El problema de Business Intelligence aparece cuando esas métricas comparten una etiqueta ambigua, como “ventas”, o se mezclan en una tabla sin conservar el origen de cada importe. Antes de intentar igualarlas, define qué representa cada una.
Tres preguntas para tres hechos diferentes
Un pedido aceptado informa de una decisión comercial dentro del alcance que haya definido la empresa. Un cobro informa de una entrada de fondos y de su asignación. El ingreso reconocido se obtiene del criterio y de los registros que valida el área financiera.
La fecha del pedido, la fecha del movimiento de cobro y el periodo contable no tienen por qué coincidir. Tampoco la emisión de una factura permite deducir automáticamente las otras dos medidas.
Como referencia conceptual, IFRS 15 relaciona el reconocimiento de ingresos con la satisfacción de las obligaciones de desempeño. El modelo de BI debe utilizar el criterio contable aplicable que haya validado la organización; no decidirlo a partir del nombre de un campo del ERP.
El mismo pedido visto durante varios meses
Utilicemos un ejemplo construido con importes en una unidad monetaria común. No incluye impuestos, diferencias de cambio ni modificaciones contractuales. Las cifras de ingresos se consideran ya validadas en la fuente financiera del ejemplo; no se calculan desde el pedido.
En enero se acepta un pedido de 1.000 y se recibe un cobro de 300. La fuente financiera registra ingresos de 600 en febrero y 400 en marzo. En marzo llega el cobro restante de 700.
| Periodo | Pedidos aceptados | Ingresos registrados | Cobros recibidos |
|---|---|---|---|
| Enero | 1.000 | 0 | 300 |
| Febrero | 0 | 600 | 0 |
| Marzo | 0 | 400 | 700 |
| Total del ejemplo | 1.000 | 1.000 | 1.000 |
Que los totales coincidan al final no significa que las tres medidas sean intercambiables. En enero, sustituir ingresos por pedidos adelantaría una cifra que no aparece en la fuente financiera del ejemplo. Sustituir cobros por ingresos describiría un movimiento de fondos inexistente en febrero.
Tampoco debes concluir que los totales siempre acabarán siendo iguales. Cancelaciones, devoluciones, impagos, modificaciones y diferencias de alcance pueden cambiar esa relación.
Conserva el grano de cada conjunto
El modelo puede necesitar hechos separados para líneas de pedido, registros de ingreso y movimientos o asignaciones de cobro. Cada conjunto debe tener su clave, fecha y reglas de agregación.
Un pedido puede tener varias líneas y varios cobros. Si unes ambas colecciones directamente por el identificador del pedido, puedes multiplicar filas: cada línea encuentra cada cobro. Sumar después los importes de las dos tablas puede duplicarlos.
Mantén las relaciones y las asignaciones necesarias según el grano real. En determinados modelos será útil una tabla de asignación entre cobros y documentos; en otros bastará con comparar agregados compatibles. La elección debe permitir explicar cómo se vincula una cantidad, no solo hacer que una visualización devuelva un número.
Un modelo en estrella ayuda a ordenar hechos y dimensiones, siempre que no se fuerce a hechos distintos a compartir el mismo grano.
Una fecha visible para cada métrica
Un filtro de “enero” resulta ambiguo si cada tarjeta aplica una fecha distinta sin indicarlo. Puedes mostrar las tres perspectivas juntas, pero sus etiquetas deben dejar claro si se trata de pedidos aceptados, ingresos del periodo o cobros recibidos.
Define qué ocurre cuando se analiza la cohorte de pedidos de enero. Esa pregunta es diferente de consultar todos los cobros recibidos en enero: la cohorte puede generar movimientos en meses posteriores.
Documenta también la fecha de corte de los datos. Un cobro incorporado tarde puede modificar una comparación aunque no haya cambiado la definición de la métrica.
Reconcilia diferencias con causas identificables
Para investigar una discrepancia, empieza por un conjunto de operaciones que ambas fuentes puedan identificar. Comprueba moneda, estados incluidos, periodo, corte y tratamiento de correcciones.
Separa los movimientos que todavía no están vinculados de los que tienen una vinculación validada. Excluir silenciosamente un cobro sin asignar puede hacer que una tarjeta parezca coherente a costa de perder información.
La reconciliación entre cuadros de mando debe terminar con una explicación de las diferencias, no con una fórmula de ajuste para que los totales se parezcan.
Qué dejar documentado antes de publicar el informe
Cada métrica necesita una definición, fuente, responsable funcional, fecha utilizada, grano y regla para correcciones. Añade un pequeño conjunto de operaciones como el ejemplo anterior y verifica sus valores por periodo y en el total.
Si estás revisando cuadros de mando de Business Intelligence, comparte con Nexeus Big Data las definiciones actuales y operaciones que puedas rastrear entre sistemas. Ese material permite construir vistas comerciales, financieras y de tesorería que expliquen sus diferencias sin perder el significado de cada dato.