El pronóstico de caja falla cuando oculta la edad de sus datos
Por Equipo Quantum Developers
Resumir:
Un pronóstico puede cuadrar y aun así estar equivocado para la decisión que se quiere tomar. La tesis es concreta: un pronóstico automatizado no es confiable si cada cifra no declara cuándo fue observada, de qué fuente proviene y qué decisiones está autorizada a soportar. Un saldo bancario de ayer, una cuenta por cobrar actualizada hoy y una obligación cargada hace una semana no forman una única fotografía solo porque aparezcan en la misma columna.
La automatización de flujo de caja suele concentrarse en conectar más fuentes o mejorar el modelo. El riesgo más básico queda oculto: datos con edades, cierres y autoridades diferentes se mezclan sin avisar. La solución práctica es un ledger de frescura que acompañe cada aporte al pronóstico.
Separe la clasificación contable de la decisión operativa
IAS 7 organiza los flujos de efectivo en actividades operativas, de inversión y de financiación, y exige conciliar efectivo y equivalentes con los importes del estado de situación (IAS 7). Esa estructura es una base contable, no una política diaria de tesorería. El dato que sirve para presentar un periodo cerrado puede no tener la vigencia necesaria para decidir una transferencia hoy.
Por eso cada uso debe declarar su horizonte: posición observada, proyección, escenario o decisión. También debe indicar si un registro es efectivo confirmado, movimiento en tránsito, obligación aprobada, estimación comercial o supuesto manual. Mezclar categorías sin señalarlas produce una cifra precisa en apariencia, pero imposible de defender.
El ledger de frescura
El ledger puede ser una tabla o un objeto asociado a cada fuente. Debe contener al menos:
| Campo | Función |
|---|---|
| source_id | identifica sistema, cuenta o dataset |
| business_object | cuenta, factura, pago, nómina u obligación |
| observed_at | cuándo ocurrió o era válido el dato |
| extracted_at | cuándo se leyó de la fuente |
| available_at | cuándo estuvo disponible para el pronóstico |
| expected_cadence | frecuencia acordada con el dueño |
| freshness_tolerance | edad máxima para ese uso específico |
| reconciliation_state | confirmado, parcial, pendiente o disputado |
| provenance | proceso y versión que lo produjo |
| owner | quien responde por significado y corrección |
| decision_right | informar, recomendar, simular o comprometer |
Los nombres son una propuesta operativa, no un estándar. La idea sí coincide con principios reconocidos. El Basel Framework resume BCBS 239 con expectativas de exactitud, integridad, completitud y oportunidad; además señala que el tiempo requerido depende de volatilidad y criticidad (BIS, SRP 36). Una tolerancia de frescura no debería ser igual para todas las fuentes: depende de la decisión.
El modelo PROV de W3C relaciona entidades, actividades y agentes para describir cómo se produjo información y quién tuvo responsabilidad (W3C PROV-DM). En el ledger, eso se traduce en no guardar solo el número final: conserve la entidad de origen, la transformación y el actor o proceso responsable.
Derechos de decisión, no solo permisos técnicos
Acceso de lectura no equivale a autoridad financiera. Use cuatro niveles separados:
- Informar: mostrar el dato y su estado.
- Recomendar: proponer una acción con supuestos visibles.
- Simular: calcular escenarios sin modificar sistemas fuente.
- Comprometer: crear una instrucción, transferencia o cambio contractual.
El último nivel requiere política explícita, aprobación separada y verificación de vigencia justo antes de actuar. Un pronóstico aprobado por la mañana no debería habilitar una ejecución por la tarde si las fuentes críticas cambiaron. La autorización debe vincularse a una versión del escenario y a un conjunto de entradas identificable.
Cuando una fuente supera su tolerancia, no la elimine silenciosamente. Marque el escenario como degradado, explique qué decisiones quedan bloqueadas y solicite actualización. La ausencia visible es más útil que una certeza fabricada.
Ejemplo ilustrativo: comité semanal
Considere una empresa que prepara una vista semanal con cuentas bancarias, cuentas por cobrar, pagos aprobados y nómina. Este ejemplo no representa resultados reales. El banco entrega saldos observados; el ERP contiene facturas y obligaciones; ventas mantiene probabilidades de cobro; nómina aporta un calendario aprobado.
El ledger puede permitir que un saldo reciente informe la posición, que una factura disputada participe solo en un escenario optimista y que una previsión comercial nunca autorice una transferencia. Si el extracto de una cuenta está vencido, el escenario sigue visible pero queda etiquetado como incompleto. El agente puede recomendar obtener el dato o reducir una salida discrecional; no puede inventar el saldo faltante.
La reunión cambia de “¿cuál es el número?” a “¿qué parte es observada, qué parte es supuesto, qué fuente está atrasada y qué decisión admite?”. Esa conversación es más lenta al principio y mucho más auditable después.
Cómo llevarlo al plano de control
En Quantum Automation Center, cada ejecución puede registrar fuentes usadas, estado, línea de tiempo, artefactos y logs. La analítica financiera debe mostrar la frescura del conjunto, no solo el valor agregado. Los objetos de negocio permiten vincular una factura o un pago con eventos posteriores sin perder identidad; consulte la documentación de objetos de negocio.
Una vista útil incluye: hora de corte del escenario, fuentes críticas vencidas, porcentaje de partidas reconciliadas sin convertirlo en una afirmación de calidad, supuestos manuales, aprobador, política aplicable y decisiones habilitadas. El artefacto aprobado debe quedar inmutable, mientras una nueva actualización crea otra versión.
El contrapunto: no toda exploración necesita un ledger completo
Para una conversación estratégica de bajo riesgo puede bastar una proyección aproximada con supuestos claros. Instrumentar linaje de campo a campo antes de saber si la vista será usada puede ser más costoso que el aprendizaje. Empiece por las fuentes que cambian decisiones y por los campos que pueden bloquear una acción.
El control debe ser proporcional. Una hoja exploratoria puede usar etiquetas manuales; una recomendación recurrente necesita validaciones; una instrucción de fondos exige evidencia y separación de autoridad.
Cuándo no usar automatización de decisión
No automatice compromisos cuando las cuentas no están reconciliadas, nadie posee las fuentes o la política de liquidez depende de conversaciones no registradas. Tampoco cuando el costo de integrar datos supera el valor de decisiones infrecuentes; en ese caso, documente un procedimiento manual y su corte.
La disciplina final es simple: toda cifra debe responder qué era cierto, cuándo, según quién y para qué decisión. Si el sistema no puede contestar, tiene una colección de números, no una capacidad gobernada de flujo de caja.
