Una empresa familiar española con ERP propio y agentes de Claude Code: los controles del dinero que lo hacen funcionar

En dos frases

El dueño de una pequeña empresa familiar española de servicio técnico de lavado de coches, que asegura que allí nadie programa, ha dedicado dos años a sustituir un programa comercial por un ERP propio y un equipo de agentes de Claude Code que llevan el buzón, los partes, las facturas de proveedor, el banco y las facturas encadenadas que se remiten a Hacienda. Lo útil para un equipo de finanzas no es la ambición, sino los controles que describe: nada que mueva dinero ocurre sin un clic en su móvil, los agentes tienen que leer procedimientos escritos antes de escribir y la lógica del dinero está cubierta por pruebas que, en público y en un día, encontraron y corrigieron dos fallos reales.

Quién lo hace y por qué interesa

Jorge Garzón se presenta como la segunda generación de una pequeña empresa familiar que repara y mantiene equipos de lavado de coches (puentes, túneles y boxes de lanzas) para dos de los grandes fabricantes y para clientes propios: «unos pocos técnicos de campo, una oficina» y él. El 9 de octubre de 2026 publicó en DEV Community, en inglés y en español, un artículo titulado «Dos años después», y en los comentarios del día siguiente informó de resultados de pruebas y arreglos. No nombra la empresa ni el programa que sustituyó, y la cuenta se creó ese mismo día, así que lo tratamos como un testimonio de primera mano que no podemos verificar. Él mismo indica que lo escribió con ayuda del mismo asistente y que lo revisó y corrigió.

Por qué nos interesa:

• Es el extremo pyme de las finanzas con agentes. Un dueño sin equipo técnico ha puesto la facturación, el IVA y el banco en un sistema que construyó con un agente, y es él quien responde de ello.
• Las lecciones son de control, no de modelos. Casi todo lo que cambió tiene que ver con separar proponer de hacer, reglas escritas, copias de prueba y pruebas de la lógica del dinero.
• Toca la normativa española. Las facturas van «firmadas y encadenadas» y, según los comentarios, registradas en Hacienda, lo que plantea preguntas que tratamos más abajo.

Qué ha construido, pieza a pieza

Según el artículo, la empresa funciona hoy con:

1. Un ERP propio en producción que sustituye al programa comercial de años. Lleva avisos, partes de trabajo desde el móvil de los técnicos, presupuestos, pedidos, facturas de proveedor, banco, variables de nómina y, «desde este mes» (octubre de 2026), la facturación electrónica que se está haciendo obligatoria en España. Una vez emitida una factura, la propia base de datos impide tocarla.
2. Agentes con Claude Code y un servidor MCP. Leen el buzón, convierten los correos de los fabricantes en avisos, cuadran lo que aprueba el fabricante con los partes, preparan pedidos a proveedores y redactan correos, que nunca envían.
3. Una biblioteca técnica que los técnicos consultan desde el móvil (fuera del alcance de este artículo).
4. Aprobación humana por Telegram. Todo lo que tiene consecuencias (crear un documento, cambiar un precio, mandar algo) le llega al móvil con dos botones, y cada decisión queda registrada: quién, cuándo y resultado.
5. Un segundo modelo, de otra empresa, que revisa lo que hace el primero y avisa cuando no está de acuerdo. No dice cuál.
6. Unos 1.500 procedimientos escritos que los agentes deben consultar antes de escribir nada: «sin procedimiento leído, no hay escritura».
7. Modelos locales en una máquina propia para lo barato y repetitivo: clasificar documentos, los índices de la biblioteca y una primera revisión de código. «El criterio se queda en Claude.»
8. Copias de seguridad cuatro veces al día, cifradas, en tres sitios, que restaura en una máquina limpia cada pocas semanas.

Herramientas y arquitectura

Capa	Qué usa	Para qué
Constructor y operador	Claude Code	Escribe y mantiene el ERP; los agentes corren sobre él
Acceso a datos	Un servidor MCP propio	La única puerta por la que los agentes leen y proponen
Reglas	~1.500 procedimientos con fecha y motivo	El agente debe leer los pertinentes antes de escribir
Aprobación	Telegram con dos botones y registro	Toda acción con consecuencias de dinero, clientes o producción
Segunda opinión	Un modelo de otro proveedor	Revisa al primero y señala desacuerdos
Trabajo barato	Modelos locales	Solo clasificación, índices y primera revisión de código
Red de seguridad	Copia de pruebas, tests, vigilantes, copias	Cazar errores antes y después de producción

Dos detalles de los comentarios completan el cuadro. Los vigilantes: pequeños scripts revisan cada pocos minutos la base de datos, las tareas programadas, las copias y cada envío a Hacienda; lo que queda «dudoso» más de un día o una tarea que falla llega al móvil del dueño, y lo que sigue en rojo tres días se convierte solo en una propuesta de arreglo. Y un estado «dudoso»: si se corta la conexión con Hacienda a mitad de una petición, la factura se queda sin número definitivo y un vigilante repite después la misma petición para saber qué pasó. Nunca reemite a ciegas, así que un corte de red no puede crear un duplicado ni un hueco en la numeración.

Paso a paso para replicarlo

Adaptación nuestra para una pyme o un departamento financiero que quiera agentes sobre sus propios sistemas. No exige construir un ERP: el mismo orden vale sobre un ERP comercial con API.

1. Escribe primero las reglas. Elige un proceso (por ejemplo, cuadrar facturas de proveedor con pedidos), escribe cómo se hace y añade una regla con fecha cada vez que algo falle. Como dice el autor, los procedimientos son para las personas; la IA solo hizo que mereciera la pena escribirlos.
2. Una puerta estrecha para el agente: un servidor MCP que solo expone las lecturas y las acciones de «proponer» que necesita, nunca la base de datos.
3. Separa proponer de hacer. Cada escritura es una propuesta que una persona aprueba en el móvil, con registro de quién, cuándo y qué.
4. Leer las reglas, obligatorio. La herramienta rechaza la escritura si el agente no ha cargado el procedimiento; una petición amable en el prompt no basta.
5. Dos copias, dos bases de datos. A producción solo pasa lo que superó las pruebas en la copia.
6. Prueba la lógica del dinero con invariantes (numeración, IVA, redondeos, abonos, reintentos, cadena firmada) y ejecútalas antes de cada cambio.
7. Añade vigilantes que solo leen para documentos pendientes, tareas fallidas, copias y envíos a Hacienda; lo que se ignora días se convierte en tarea.
8. Una sesión por tema con una nota de traspaso corta, y restaura las copias en una máquina limpia con calendario.
9. Revisa la normativa antes de emitir facturas con un sistema propio (ver más abajo).

Ejemplo concreto: las pruebas del dinero

Lo más instructivo es un intercambio público. Un comentarista, cuyo perfil promociona un producto para que los agentes manejen un ordenador, propuso cuatro pruebas de invariantes; el autor las ejecutó ese mismo día en su copia de pruebas. Resumimos lo que contó; la última columna es nuestra.

Invariante	Resultado según el autor	Qué protege
Dos conexiones reales emiten a la vez en la misma serie	Superada: la segunda recibe «ya se está emitiendo» sin gastar número y, al reintentar, toma el siguiente	Sin huecos ni números repetidos
Cambiar un byte de una factura guardada en una copia de pruebas	Superada tras escribir un verificador de la cadena, probado antes con una cadena real registrada en Hacienda	La manipulación se detecta justo en ese registro
Abono más factura original suman cero por cada tipo de IVA	Fallida en facturas antiguas importadas del programa anterior con descuento en cabecera: un céntimo de diferencia en un tipo	El redondeo por tipo, no solo el total
La misma petición de alta enviada dos veces crea un solo documento	Fallida en presupuestos y borradores de factura (las facturas de proveedor y los gastos ya rechazaban duplicados)	Los agentes reintentan; el reintento no debe duplicar

Según su mensaje posterior, los dos fallos quedaron arreglados y en producción esa misma noche. Los abonos de esas facturas con descuento salen ahora a cero exacto por tipo de IVA, y crear un documento admite una clave de idempotencia: la pantalla envía una al abrir el formulario y los agentes envían una construida a partir del contenido de la petición, válida diez minutos. Si llega un reintento con el mismo contenido pasada la ventana, se tramita, pero el dueño recibe un aviso con los dos documentos. Ya tenía probados los reintentos de la misma petición a Hacienda y que no hubiera dos facturas confirmadas con el mismo número.

Un segundo comentarista, que vende revisiones de montajes con agentes, añadió una idea barata: guardar unos cuantos documentos erróneos a propósito (por ejemplo, cinco partes con un precio que se sabe erróneo) y pasar el paso de cuadre sobre ellos tras cada cambio. Si alguno sale aprobado, el cambio se para ahí.

Resultados declarados por la fuente

Todas las cifras son del autor y no están auditadas:

• Revisa unas veinte decisiones de los agentes al día desde el móvil «en unos minutos» y «nunca pasa nada que me sorprenda».
• Una sesión de trabajo que arrastraba toda la conversación «releía cientos de miles de tokens en cada paso»; con una sesión por tema y una nota de traspaso, «el mismo trabajo cuesta una fracción».
• En siete tareas reales de su lista, un modelo local de 27B sacó 21 de 52 puntos frente a 46 de Claude. Funciona con un plan muy corto y preciso y empeora con más contexto.
• Los errores que admite: cuando los agentes actuaban y avisaban después, «perdimos un día» con una tanda de partes aprobados con precios equivocados; y la única vez que compilaron directamente en producción, un error de sintaxis tiró el sistema un minuto.

No da cifras de horas ahorradas, licencias evitadas, ingresos ni volumen de facturas, y nadie más confirma el relato.

La parte española: un sistema de facturación propio tiene obligaciones

El autor no nombra el régimen, pero lo que describe (facturas firmadas y encadenadas cuyos registros se remiten a Hacienda) encaja con VERI*FACTU, la modalidad del Reglamento de sistemas informáticos de facturación (Real Decreto 1007/2023). Algunos puntos de fuentes oficiales que conviene conocer antes de tomar este camino:

• El software propio también se certifica. Las preguntas frecuentes de la Agencia Tributaria dicen que, si la empresa ha desarrollado su propio programa de facturación, es ella quien debe certificarlo mediante declaración responsable, según el artículo 13 del reglamento. No hay certificación externa ni registro previo: es una autocertificación incorporada al sistema.
• Cada versión cuenta. Las mismas preguntas frecuentes indican que cada versión, por pequeña variación que introduzca, es un producto distinto que necesita su propia declaración. En un sistema que, como este, pasa de un comentario a producción en un día, eso es papeleo real; pregunta a tu asesor cómo se aplica a cambios frecuentes.
• Lo emitido no debe poder tocarse desde el sistema. Según la AEAT, modificar directamente en la base de datos registros de facturación ya emitidos no debe ser una operativa permitida. El diseño del autor, con una base de datos que impide cambiar lo emitido, va en esa línea.
• Plazos. El 5 de octubre de 2026 Hacienda anunció que prevé aplazar las obligaciones pendientes de VERI*FACTU hasta octubre de 2028, a falta de aprobarlo en una norma. Aparte, la factura electrónica obligatoria entre empresas se aplica desde el 6 de octubre de 2027 a quienes facturen más de 8 millones de euros y desde el 6 de octubre de 2028 al resto. Quienes ya están en el SII quedan fuera de este reglamento, y País Vasco y Navarra tienen normas propias.

Nada de esto significa que el autor incumpla; no sabemos qué ha firmado. Significa que construir tu propio sistema te convierte, a ojos de Hacienda, en el fabricante del software.

Limitaciones y riesgos

• Fuente no verificable. Un artículo y sus comentarios, una empresa anónima, una cuenta nueva y un texto escrito con ayuda de un asistente de IA. Los detalles (pruebas, error, puntuaciones) son coherentes y autocríticos, pero no están confirmados.
• Dependencia de una persona. Lo dice él: «Cuenta con que el mantenimiento es tuyo». Si él falta, la empresa depende de un sistema que solo entienden él y un agente.
• La aprobación vale lo que el revisor. Veinte decisiones en unos minutos es rápido; funciona si cada aviso muestra lo necesario para decidir y si los documentos trampa siguen demostrando que los controles cazan errores.
• Las pruebas son nuevas. Según él, hasta esa semana las pruebas del dinero no se ejecutaban solas antes de cada cambio y no había ninguna de anulaciones, reintentos ni de la cadena.
• Datos. Facturas, variables de nómina y correos de clientes pasan por un modelo en la nube; decide qué va a dónde y con qué contrato.

Errores comunes

• Dejar que los agentes actúen y avisen después; a esta empresa le costó un día.
• Fiarse de la memoria del chat: «Si no está escrito en un procedimiento o un fichero, al día siguiente no existe».
• Probar solo totales: el céntimo estaba en un tipo de IVA, invisible en el total.
• Suponer que los reintentos son inocuos: sin clave de idempotencia, la misma petición crea dos documentos.
• Desarrollar sobre producción y no restaurar nunca una copia.
• Dar tareas largas a modelos locales pequeños: en sus pruebas descarrilan con más de una página.

Conclusiones

Esto no es un argumento para que cada pyme escriba su ERP; la propia lista de lecciones del autor suena a advertencia sobre la responsabilidad que implica, empezando por Hacienda. Pero es uno de los relatos más concretos que hemos leído sobre cómo mantener a los agentes de IA a salvo cerca del dinero: propuestas en lugar de acciones, reglas escritas que la herramienta obliga a leer, aprobaciones en el móvil con registro, pruebas de invariantes de numeración, IVA y reintentos, y vigilantes que convierten los avisos ignorados en trabajo. Esos controles sirven igual para agentes que trabajan sobre Holded, Odoo, Sage o cualquier ERP con API.