«Cerebro de analista» en tesorería: un agente de Copilot sobre SharePoint hace el primer análisis de caja de una docena larga de sociedades

En dos frases

Un equipo de tesorería corporativa que heredó la gestión de caja de una docena larga de sociedades, sin plantilla adicional, construyó el analista que le faltaba como un agente de Microsoft Copilot que consulta una base de conocimiento en SharePoint y sigue un procedimiento fijo de seis pasos. La lección que repite su autor es que el agente solo empezó a ser útil cuando la base de conocimiento recogió lo que sabían las personas con experiencia sobre los motores de la caja, y eso habla más de documentación que de modelos.

Quién lo hace y por qué interesa

Phil Capodice se presenta en LinkedIn como AVP, Treasury Transformation, y su perfil lo sitúa en Voya Financial desde octubre de 2023, al frente de lo que llama «agentificación» de la tesorería corporativa, después de trabajar en consultoría de tesorería en Accenture y PwC. Entre agosto y octubre de 2026 publicó una serie de textos breves, en primera persona, sobre agentes que ha construido para tesorería y reporting financiero. No nombran a su empresa, a las sociedades ni los volúmenes, así que lo tratamos como el relato de un profesional, no como un caso corporativo.

La publicación principal, del 19 de agosto de 2026, parte de un problema conocido. Su equipo asumió la gestión de caja completa de un grupo de «una docena larga» de sociedades: posición de tesorería, previsión, liquidaciones entre unidades y reporting mensual. Calcula la carga en torno a media jornada completa. Contratar no era posible, así que «construyó» al analista: un agente de Copilot apoyado en una base de conocimiento en SharePoint y que ejecuta unas instrucciones de análisis fijas en seis pasos.

Por qué importa para este directorio:

• Usa herramientas que muchos departamentos financieros ya pagan. En otra publicación insiste en que todo funciona con un agente de Copilot sobre SharePoint, Power Automate y Teams, «sin ninguna licencia nueva». La mayoría de los casos de tesorería que recogemos usan una plataforma especializada o código a medida.
• El cuello de botella era el conocimiento, no el modelo. La solución, escribe, no fue un prompt mejor ni un modelo más grande, sino las entrevistas.
• Cuenta lo que no funcionó. La primera base de conocimiento era demasiado pobre, y la primera versión del agente de arrastre de saldos era inconsistente. Los dos fallos enseñan mucho.

Qué construyó, pieza a pieza

Entre las cinco publicaciones hay cuatro cosas, en distinto grado de madurez.

1. El agente analista de caja (en uso). La primera versión tenía documentado el negocio y el comportamiento esperado de sus flujos de caja. Acertaba «a alto nivel», pero no daba la visión que aporta un buen gestor de tesorería. Entonces se sentó con quienes entienden qué mueve las nóminas, los ingresos y otros flujos, puso por escrito lo que «solo estaba en sus cabezas» y lo devolvió a la base de conocimiento. A partir de ahí, dice, el agente funcionó bien.

2. El agente de arrastre de saldos (construido, sin resultados declarados). Al abrir cada periodo de reporting, alguien tiene que comprobar a ojo que las cifras de apertura de un informe de más de cien páginas cuadran con las de cierre del periodo anterior y que la información de las notas sigue siendo coherente. Su agente recibe el documento actual y el anterior, decide cómo abordarlos, los compara sección a sección y devuelve una tabla con lo que coincide, lo que cambia y las excepciones que hay que mirar. Su primera instrucción, «revisa la coherencia de los documentos», marcaba cosas correctas y se saltaba errores. Lo que funcionó fue documentar el proceso como una skill: cómo se trazan las cifras del periodo anterior al actual, qué es una diferencia real frente a un cambio de formato y qué hacer cuando una cifra cambió con motivo. Añade que la tabla de salida sirve además de pista de auditoría.

3. Una rúbrica de idoneidad (un método). Antes de construir, puntúa los procesos financieros en dos ejes: cuánto se presta el proceso a la IA y cuánto valor liberaría. El cuadrante que merece atención es el de mucho valor y poca idoneidad: el problema es real, pero los datos están atrapados, la integración no existe o el criterio nunca se ha escrito. Cambió la rúbrica para nombrar el bloqueo (datos, integración, criterio o control) y calificar esos casos como rediseño de proceso, no como automatización con IA, porque si no se acaba automatizando un traspaso roto y equivocándose más deprisa.

4. Consultar, avisar, orquestar (un patrón). En una charla a compañeros de finanzas mostró tres peldaños con las mismas herramientas de Microsoft: consultar (preguntas al agente, apoyado en un buzón compartido y en SharePoint, y redacta o resume), avisar (un flujo de Power Automate clasifica cada mensaje al llegar y marca un pago urgente antes de que nadie abra el buzón) y orquestar (Teams asigna cada asunto a un responsable, lo sigue hasta que se resuelve y publica el estado). Dice que aplicó la misma escalera a un buzón de grupo, a una previsión de caja y a una conciliación entre periodos.

Una quinta publicación, del 14 de octubre, describe un sistema para grabar en vídeo los procedimientos de tesorería, hacer que la IA detecte huecos en la grabación y redactar procedimientos normalizados con un identificador fijo para cada paso, control y excepción. Él mismo lo deja claro: está diseñado y en construcción, sin resultados todavía.

Herramientas y arquitectura

Qué respaldan las fuentes y qué es deducción nuestra:

• Agente: un agente de Microsoft Copilot. Las publicaciones no dicen si se hizo con Agent Builder de Microsoft 365 Copilot o con Copilot Studio, ni qué modelo usa.
• Conocimiento: una base en SharePoint con la descripción del negocio, el comportamiento esperado de la caja y las notas de las entrevistas. Según la documentación de Microsoft, Agent Builder admite hasta 100 archivos de SharePoint y una lista de SharePoint por agente, respeta los permisos y las etiquetas de confidencialidad existentes y no puede usar SharePoint como origen si está activada la búsqueda restringida de SharePoint (Restricted SharePoint Search). También indica que los agentes responden mejor sobre Excel cuando los datos están en una sola hoja.
• Instrucciones: un procedimiento fijo de seis pasos. En Agent Builder el campo de instrucciones admite 8.000 caracteres, de sobra para un análisis numerado pero no para todo un manual de tesorería: el manual va en la base de conocimiento.
• Automatización y reparto: Power Automate y Teams para los peldaños de avisar y orquestar.
• Control: una persona revisa cada resultado. Las publicaciones no dicen que el agente contabilice, mueva fondos ni escriba en ningún sistema de tesorería o ERP, y no recomendaríamos que lo hiciera.

Paso a paso para replicarlo

Los pasos son nuestros, a partir de su descripción y de la documentación de Microsoft.

1. Puntúa antes el proceso. Valora de 1 a 5 la idoneidad para la IA (¿las entradas son digitales?, ¿el criterio está escrito?, ¿se puede comprobar el resultado?) y de 1 a 5 el valor (horas, riesgo, frecuencia). Nombra el bloqueo de todo lo que quede por debajo de 3 en idoneidad. Empieza por un análisis recurrente, como la revisión mensual de desviaciones de caja.
2. Diseña la base de conocimiento como documentos que leería un analista. Una página por sociedad: a qué se dedica, sus cuentas bancarias, su patrón mensual normal de caja, su calendario de nóminas e impuestos, las liquidaciones recurrentes entre sociedades, los hechos puntuales conocidos y a quién preguntar. Y una página de reglas del grupo: saldos mínimos, convenciones de liquidación y umbrales de materialidad.
3. Entrevista a quienes saben. Pregunta a nóminas, ventas, proveedores e impuestos qué mueve la caja de un modo que la documentación no refleja: desfases, estacionalidad, clientes que siempre pagan tarde, meses en que caen un bonus o un pago fiscal. Añade sus respuestas, con autor y fecha, a las páginas de cada sociedad.
4. Escribe las instrucciones en seis pasos (abajo va nuestro ejemplo) y mantenlas breves y fijas, para que el análisis de cada mes tenga la misma forma y se pueda comparar.
5. Crea el agente. En Microsoft 365 Copilot elige Nuevo agente y después Omitir para configurar (Skip to configure); dale un nombre, una descripción precisa y las instrucciones, y añade como conocimiento la carpeta o el sitio de SharePoint por su URL. Deja las cifras del periodo en archivos aparte que adjuntas o señalas cada mes.
6. Pruébalo con meses cerrados. Ejecútalo sobre dos o tres meses que el equipo ya analizó a mano y compara: qué se le escapó, qué se inventó y qué explicó mejor. Corrige la base de conocimiento antes de tocar las instrucciones.
7. Mete la revisión en la rutina. Una persona con nombre firma cada resultado, y cada corrección vuelve a la base de conocimiento como regla o motor nuevo.
8. Solo entonces, avisar y orquestar. Añade un flujo de Power Automate que avise cuando se cumpla una condición (por ejemplo, un pago marcado como urgente), filtrando en el propio desencadenador, como recomienda Microsoft para no gastar en balde la cuota de ejecuciones del plan; después reparte los asuntos en Teams.

Ejemplo concreto: unas instrucciones en seis pasos

Él no publicó sus seis pasos. Esta es nuestra versión para una revisión mensual de caja de varias sociedades, muy por debajo del límite de 8.000 caracteres:

Eres el analista de caja del equipo de tesorería. Usa solo los archivos de este
periodo y la base de conocimiento. No inventes cifras; si un dato no está en los
archivos, dilo.

Paso 1 - Entradas. Enumera los archivos usados, sus fechas y las sociedades que
cubren. Detente e informa si falta alguna sociedad, cuenta bancaria o el archivo
de previsión.
Paso 2 - Posición. Para cada sociedad, da el saldo inicial y final y compara el
saldo final con su saldo mínimo operativo según la base de conocimiento.
Paso 3 - Desviaciones. Para cada sociedad, compara el flujo neto real con el
previsto y enumera toda desviación superior al umbral de materialidad de la base
de conocimiento, por motor (nóminas, cobros de clientes, pagos a proveedores,
impuestos, entre sociedades, otros).
Paso 4 - Explicación. Explica cada desviación con los motores y calendarios de la
página de la sociedad. Cita el documento. Si la base de conocimiento no la
explica, escribe "SIN EXPLICAR" y no supongas nada.
Paso 5 - Liquidaciones entre sociedades. Enumera las vencidas, las liquidadas y
las pendientes, y todo importe que no cuadre entre las dos sociedades.
Paso 6 - Borrador. Redacta un resumen de una página para el informe mensual y una
lista de preguntas para el equipo, ordenada por importe. Marca todo el resultado
como borrador pendiente de revisión humana.

Las decisiones de diseño importantes son la regla «SIN EXPLICAR», que convierte los huecos de la base de conocimiento en una lista visible de tareas en lugar de una ficción verosímil, y el paso 1, que detiene la ejecución si falta una entrada.

Para el agente de arrastre de saldos, la skill equivalente sería un documento breve con reglas como estas: un saldo de apertura debe coincidir exactamente con el de cierre anterior salvo que exista una nota de reexpresión; un cambio de redondeo, de unidades o de orden de columnas es formato, no una diferencia; una partida reclasificada debe aparecer con el epígrafe antiguo y el nuevo; y cada excepción va a la tabla con la referencia de página de los dos documentos.

Resultados que declara la fuente

• Análisis de caja: «un primer análisis con criterio en minutos», cuando antes una persona del equipo tardaba días cada mes, según el autor. Sin mediciones, sin tasa de acierto y sin más detalle sobre el número de sociedades que «una docena larga».
• Alcance que cubre: alrededor de media jornada completa, según su propia estimación.
• Agente de arrastre de saldos: el primer intento era inconsistente; la versión con skill hace la primera pasada y «tiene el potencial» de devolver tiempo en cada periodo. Sin cifras.
• La escalera: la mostró a sus compañeros sobre un buzón de grupo, una previsión de caja y una conciliación, sin dar resultados.
• El sistema de procedimientos: sin probar, según él mismo.

Su empresa no ha confirmado nada de esto, y son publicaciones de alguien cuyo trabajo es impulsar esta transformación internamente, así que conviene leerlas como el informe de un profesional.

Limitaciones y riesgos

• Una sola fuente. Todo procede de las publicaciones del autor. No encontramos grabaciones de charlas, artículos ni comunicados que confirmen los detalles.
• Entradas desconocidas. No sabemos cómo llegan los saldos y la previsión al agente (exportaciones, informes de Kyriba, hojas de cálculo) ni con qué frescura. Una exportación desfasada, analizada con fluidez, sigue estando desfasada.
• Conocimiento compartido, riesgo compartido. La biblioteca de SharePoint se convierte en la verdad del agente. Si una página está mal o anticuada, todos los análisis heredan el error. Los permisos también importan: el agente los respeta, así que quien lo usa necesita acceso a cada página y nadie debe ganar acceso que no le corresponde.
• Licencias. La documentación de Microsoft indica que el conocimiento de SharePoint y OneDrive exige que el usuario tenga licencia de Microsoft 365 Copilot y que los orígenes disponibles dependen de la licencia. Lo de «sin licencias nuevas» solo vale donde ya las hay.
• La dependencia de personas clave se traslada, no desaparece. Las entrevistas reducen la dependencia de la memoria de cada uno, pero alguien tiene que ser dueño de la base de conocimiento y mantenerla al día.

Errores habituales

• Escribir un prompt mejor en vez de una base de conocimiento mejor. Su propia primera versión falló por eso.
• Instrucciones vagas del tipo «revisa la coherencia». Define qué es una diferencia real y qué hacer con un cambio justificado.
• Automatizar un proceso valioso que no está preparado. Si los datos están atrapados o el criterio no está escrito, rediseña antes el proceso.
• Saltarse la prueba con meses cerrados. Compara con meses ya analizados por personas antes de fiarte de uno nuevo.
• Dejar que el borrador se convierta en el informe. Mantén explícita la firma de una persona, y el agente en solo lectura.

Conclusiones

No es la historia de un modelo brillante. Es la de un responsable de tesorería que trató al agente como a un analista nuevo al que hay que incorporar: una descripción escrita del negocio, el conocimiento no escrito de quienes lo llevan, un método fijo y alguien que revisa. El mismo patrón aparece en su agente de arrastre de saldos, donde documentar el procedimiento como skill convirtió una herramienta inconsistente en una primera pasada útil. Para un equipo que ya trabaja con Microsoft 365, la barrera para probarlo es baja; el trabajo de verdad son las entrevistas y el mantenimiento de la base de conocimiento, y merece la pena hacerlo incluso antes de que ningún agente la lea.