Agentes de cierre en un grupo de capital riesgo con QuickBooks y Sage: la IA detecta y explica, el código calcula cada cifra

En dos frases

Un grupo empresarial participado por un fondo de capital riesgo, con cuatro sociedades operativas en QuickBooks y dos en Sage, tiene ya agentes trabajando en su cierre mensual, la consolidación, la conciliación intragrupo y la previsión de caja a 13 semanas; los construyó la consultora Bolt Group, que asegura que el modelo de lenguaje no tiene permiso para calcular ni una sola cifra. Es una de las descripciones públicas más concretas de cómo acercar agentes a números que leen un consejo de administración y un banco, pero procede del proveedor, el cliente es anónimo y no hay resultados medidos.

Quién lo hace y por qué interesa

El 28 de agosto de 2026, Dean Sloves, fundador de Bolt Group, una empresa de implantación de IA que integra ingenieros en empresas medianas, publicó en X un hilo largo sobre uno de sus encargos. El cliente es un roll-up, un grupo formado por la compra sucesiva de empresas, respaldado por un fondo de capital riesgo: cuatro sociedades operativas llevan la contabilidad en QuickBooks y dos en Sage, las cuentas a pagar se gestionan en Bill.com y los costes por obra en ServiceTitan. Las seis contabilidades alimentan la información que se entrega al consejo y a un prestamista.

Antes del proyecto, el responsable financiero (VP of Finance) cerraba a mano. Cada mes exportaba seis balances de sumas y saldos y los cosía en Excel, y, según Sloves, llamaba al resultado «una fuente de mejor estimación, no una fuente de verdad». Quien haya consolidado un grupo nacido de adquisiciones reconocerá el problema: cada sociedad conserva su propio plan de cuentas, sus costumbres para facturarse entre empresas del grupo y su propia idea de qué va en «Reparaciones y conservación».

Dos semanas después, Sloves describió en una publicación más breve lo que parece el mismo tipo de proyecto: consolidación multisociedad para un holding que creció por adquisiciones, con «6 libros mayores en dos plataformas, un sistema de cuentas a pagar y más», construida sobre el harness propio de Bolt y no sobre una herramienta comercial. La regla que dice no haber roto nunca: la consolidación, las eliminaciones intragrupo y los estados financieros se calculan en código que se puede rastrear hasta el origen, y «ningún LLM toca un total».

Por qué importa para este directorio:

• Habla de contabilidades de pequeña empresa, no de un gran ERP. La mayoría de casos publicados de agentes financieros vienen de clientes de SAP, Oracle o NetSuite. Aquí la materia prima es QuickBooks y Sage, el software que usan de verdad muchas de las pymes que acaban comprando los fondos.
• Separa con nitidez calcular y explicar. En lugar de preguntarse «qué precisión tiene el modelo», el diseño saca la aritmética de su trabajo.
• Convierte al responsable financiero en el banco de pruebas. El VP of Finance sigue rehaciendo el paquete a mano y devuelve las diferencias como errores a corregir.

Conviene tener las cautelas presentes desde el principio: Bolt vende este trabajo, el hilo es tanto marketing como caso práctico, el cliente no se puede comprobar y el único resultado que se ofrece es que los agentes «ya pueden ejecutar» varios procesos y que el encargo se amplió dos veces.

Herramientas y arquitectura

Según el hilo, el sistema tiene cinco capas. Los nombres son nuestros; el contenido, de Bolt.

1. Fuentes. Seis libros mayores (cuatro en QuickBooks y dos en Sage), el auxiliar de proveedores en Bill.com y los costes por obra en ServiceTitan. El hilo no aclara si las sociedades de QuickBooks usan la versión Online o la de escritorio, ni qué producto de Sage usan las otras dos.
2. Mapeo canónico. Antes de que funcionara ningún agente, Bolt unificó los planes de cuentas de las seis contabilidades en una estructura canónica, «para que el agente razone sobre datos mapeados en lugar de adivinar a qué sociedad pertenece cada cuenta de reparaciones y mantenimiento».
3. Almacén de datos con trazabilidad. Cada fila lleva un hash de origen y una marca de tiempo de extracción, de modo que cualquier cifra de cualquier pantalla se puede seguir hasta el apunte del que procede, y los periodos cerrados se reproducen exactamente. Los importes son cadenas decimales de principio a fin: los números en coma flotante nunca entran en el cálculo.
4. Motor determinista. Código en TypeScript calcula todas las cifras: el cierre, la consolidación, las eliminaciones intragrupo, los costes por obra y la previsión de caja a 13 semanas.
5. Agentes. «Detectan, señalan, vigilan y explican» y nunca producen un total. Todos siguen el mismo patrón: precalcular los datos, dar al modelo un catálogo acotado de herramientas, validar su respuesta contra un esquema y dejar que el código determinista decida qué se publica. Cada herramienta declara si lee el mayor o un auxiliar, de modo que el enrutado es «un contrato y no un párrafo del prompt». Un agente es configuración, no código: sus skills, su alcance de datos, su calendario y a quién avisa. Publican en Teams, Slack, iMessage o email, y el equipo puede conversar con ellos ahí.

Alrededor hay dos bucles de control: un banco de pruebas que evalúa el enrutado de herramientas con aserciones deterministas antes de llegar a producción, y que se repite con cada versión de modelo, y el propio VP of Finance, que rehace el paquete a mano y envía las diferencias por email.

Paso a paso para replicar el patrón

Esta es nuestra traducción del diseño a pasos que puede seguir un equipo financiero con un desarrollador. No es el método de Bolt, que no es público.

1. Inventaría cada contabilidad y cada auxiliar y cómo leerlos. En QuickBooks Online, la API de contabilidad ofrece el informe TrialBalance (sumas y saldos) por empresa y rango de fechas, con criterio de devengo o de caja. En otros productos, usa la API o la exportación programada que ofrezcan. Anota para cada fuente: sociedad, moneda, criterio, frecuencia de extracción y responsable.
2. Construye antes que nada el plan de cuentas canónico. Una fila por cuenta de origen con: sociedad, código y nombre de la cuenta original, cuenta canónica, línea de los estados financieros y si es intragrupo (y con qué contraparte). Una cuenta sin mapear debe detener el proceso, no caer en «Otros». Esta tabla es la parte lenta y valiosa; cuenta con discusiones con el negocio.
3. Guarda datos, no hojas de cálculo. Cada saldo o movimiento extraído es una fila con sociedad, periodo, cuenta canónica, importe como cadena decimal o en céntimos enteros, sistema de origen, identificador de origen, momento de extracción y un hash del registro original. No edites nunca un dato: vuelve a extraerlo y conserva ambas versiones.
4. Escribe la aritmética como código normal con pruebas. El balance consolidado, las eliminaciones intragrupo, la conversión de moneda si hace falta, la agregación de costes por obra y la previsión a 13 semanas son funciones sobre esos datos. Pruébalas contra un periodo que el responsable financiero ya cerró a mano, al céntimo.
5. Diseña un catálogo de herramientas pequeño y tipado. Cada herramienta lee una sola cosa y lo declara: gl_balances(entity, period), ap_open_items(entity, as_of), intercompany_pairs(period), mapping_exceptions(period). Devuelven datos con su trazabilidad; ninguna devuelve una respuesta en texto libre.
6. Da a cada agente un único trabajo y un esquema de salida. Por ejemplo, un vigilante de intragrupo devuelve una lista de hallazgos, cada uno con tipo, sociedades, cuentas canónicas, los importes tal como los calculó el motor, los hashes de los datos en que se apoya, una causa probable y un nivel de confianza. Lo que no supera la validación se descarta y queda registrado.
7. Que el código decida qué se publica. Un hallazgo solo llega a las personas si supera comprobaciones deterministas: los importes que cita coinciden con los del motor, los datos que menciona existen y la diferencia supera el umbral de importancia relativa que fijes.
8. Escribe pruebas de enrutado antes de salir a producción. Aserciones cortas y deterministas: una pregunta sobre proveedores debe llamar a la herramienta de cuentas a pagar, una pregunta sobre la cuenta de resultados debe quedarse en el mayor, un saludo no debe llamar a ninguna herramienta. Ejecútalas cada vez que cambies los prompts o el proveedor publique una versión nueva del modelo.
9. Mantén la reconstrucción manual en paralelo. Pide al responsable de las cifras que siga preparando el paquete a la antigua durante unos cuantos cierres y que envíe cada diferencia. Convierte cada una en una corrección y en una prueba de regresión.
10. Publica donde ya trabaja el equipo. Los hallazgos van al canal de cierre en Teams o Slack, con enlaces a los datos de origen, y cada agente tiene un responsable.

Una definición mínima de agente, en la línea de «un agente es configuración» (ilustración nuestra):

agent: intercompany-watcher
schedule: "cada día a las 07:00 durante el cierre; semanal el resto del mes"
data_scope: [gl_balances, intercompany_pairs, mapping_exceptions]
skills: [intercompany-rules-v3]
output_schema: finding_v2
ships_if:
  - quoted_amounts_match_engine
  - cited_fact_hashes_exist
  - abs(difference) >= 250.00
notify: ["#sala-de-cierre", "vp-finance"]
owner: "controller del grupo"

Un ejemplo concreto (cifras hipotéticas)

Las cifras son inventadas para mostrar el reparto de tareas; no son las del cliente.

En el cierre de septiembre, el motor determinista empareja los saldos intragrupo. La sociedad A (QuickBooks) tiene una cuenta a cobrar a la sociedad E (Sage) de 48.500,00; la sociedad E tiene una cuenta a pagar a la A de 45.800,00. El motor calcula la diferencia, 2.700,00, y bloquea la eliminación porque no cuadra a cero. Hasta aquí, solo código.

El agente de intragrupo recibe entonces los dos datos, sus apuntes de origen y los movimientos entre ambas sociedades de los últimos seis meses. Su hallazgo, validado contra el esquema, dice: la diferencia es divisible por nueve, algo típico de una transposición de cifras (48.500 frente a 45.800); la factura de la sociedad E se registró el 18 de septiembre con una referencia que coincide con la factura emitida por la A; causa probable: error de grabación en la sociedad E; confianza: media. Cita 2.700,00 porque el motor le dio ese número, no porque haya restado nada.

La compuerta comprueba que 2.700,00 coincide con el motor, que existen los dos hashes y que el importe supera el umbral, y publica el hallazgo en el canal de cierre. El contable de la sociedad E abre la factura y la corrige en Sage; la siguiente extracción trae un dato nuevo, el motor vuelve a emparejar los saldos y la eliminación cuadra. En ningún momento el modelo modificó una contabilidad ni produjo una cifra que acabara en los estados financieros.

Un segundo hallazgo de esa misma mañana podría señalar que la sociedad C registra las reparaciones de maquinaria como coste de ventas, mientras que el mapeo canónico lleva esa misma cuenta a gastos de explotación en las otras cinco: una cuestión de criterio para el controller, no una cifra que deba arreglar el modelo.

Resultados declarados

Todo lo que sigue procede del fundador de Bolt Group:

• A las once semanas de encargo, los agentes «ya pueden ejecutar el cierre, la previsión de caja a 13 semanas, la contabilidad forense, los costes por obra y la conciliación intragrupo».
• El encargo «se ha ampliado dos veces».
• El VP of Finance sigue rehaciendo el paquete a mano y enviando las diferencias, como un descuadre en la cuenta de resultados consolidada, un saldo bancario que faltaba o una sección de clientes que no aparecía; cada una se convierte en una corrección y en una prueba.

Lo que falta: la duración del cierre antes y después, las horas ahorradas, cuántas diferencias ha encontrado el responsable financiero y si van a menos, qué significa en la práctica «ejecutar el cierre» (¿preparar, revisar o contabilizar?), el modelo utilizado y cualquier declaración del cliente. En su publicación posterior, Sloves afirma además haber automatizado «el 93 % de los asientos de una gran empresa» y ofrece garantía de devolución del dinero; se refiere a otro cliente y no está verificado. La publicación de Shyan-Ming Perng en LinkedIn resume el hilo en una lista de siete puntos, pero es un comentario sobre la misma fuente, no una confirmación independiente.

Limitaciones y riesgos

• Relato del proveedor, cliente anónimo. No podemos comprobar la empresa, sus auditores ni su prestamista, y Bolt tiene un interés comercial directo.
• «Ejecutar el cierre» es ambiguo. El hilo no dice si los agentes contabilizan asientos. Si lo hacen, la segregación de funciones y los límites de aprobación pesan más que cualquiera de las reglas de diseño.
• Determinista no significa correcto. Un código puede calcular mal una eliminación con total exactitud todos los meses. La tabla de mapeo y el motor necesitan revisión y pruebas como cualquier modelo financiero.
• La explicación sigue siendo una salida del modelo. Un controller de un grupo de 12 sociedades contó en r/Accounting que la IA les ahorró tiempo al codificar movimientos, redactar explicaciones de variaciones y señalar conciliaciones que no cuadraban, pero que un mes escribió «una explicación preciosa» para una variación que era simplemente un apunte mal hecho, y que nunca la deja acercarse a periodificaciones ni al corte de operaciones. Las explicaciones merecen el mismo escepticismo que las cifras.
• Datos y accesos. Una capa de acceso unificada a seis contabilidades, cuentas a pagar y costes por obra es una gran superficie de ataque: herramientas de solo lectura, mínimo privilegio y registros no son opcionales.
• El riesgo de persona clave cambia de sitio, no desaparece. Lo que vivía en la hoja de cálculo del responsable financiero vive ahora en la tabla de mapeo y en la configuración de los agentes; alguien tiene que ser dueño de ambas.

Errores comunes

• Dejar que el modelo sume «solo esta vez». Un modelo que suma bien una columna casi siempre es exactamente la trampa que describe el hilo: la gente deja de comprobar.
• Empezar por los agentes antes del mapeo. Sin un plan de cuentas canónico, un agente que razona sobre seis contabilidades está adivinando.
• Coma flotante para el dinero. Los decimales binarios se desvían en los céntimos; usa cadenas decimales o unidades mínimas enteras en todo el recorrido.
• El prompt como enrutador. Escribir en el prompt «usa los datos de proveedores para las preguntas de cuentas a pagar» es un deseo; una herramienta que declara su alcance, más una prueba, es un contrato.
• Un modelo evaluando a otro modelo. El enrutado y los importes se pueden comprobar con aserciones deterministas; deja la evaluación por modelo, si acaso, para el tono.
• Apagar demasiado pronto la reconstrucción manual. El paquete paralelo del responsable financiero es la prueba más barata y fiable que tienes.

Conclusiones

Lo interesante de este caso no es que haya agentes, sino dónde sus autores se niegan a usarlos. La aritmética, la consolidación y la previsión viven en código normal y comprobable; los agentes buscan lo anómalo entre seis contabilidades y lo explican, y una compuerta determinista decide qué ve el equipo. Para un grupo armado con sociedades en QuickBooks y Sage es un patrón que se puede adoptar poco a poco: primero el mapeo, después los datos con trazabilidad y, al final, los agentes.

La evidencia, eso sí, es escasa: el relato de un proveedor sobre un cliente anónimo y sin métricas. Tómalo como un documento de diseño bien razonado de alguien que lo ha hecho, contrasta cada afirmación con tu propio cierre y mantén en el circuito a quien firma las cifras hasta que dejen de aparecer diferencias.