Un agente contable personal: Claude Code lleva un libro en Beancount y responde a los tickets enviados por email con una pull request

En dos frases

Pyry Haulos, ingeniero de software, explica que su contabilidad personal vive ahora en un libro de texto plano con Beancount que mantiene Claude Code, y que lo alimenta enviando por email tickets, extractos bancarios y recibos de la tarjeta: el agente contesta con una pull request que incluye los asientos nuevos, los informes regenerados y las diferencias, que él revisa antes de aceptar nada. Es el relato de primera mano de una sola persona, con un ejemplo detallado y sin cifras auditadas, pero la arquitectura deja muy claro dónde están los controles y otras tres personas describen versiones parecidas de la misma idea.

Quién lo hace y qué tipo de evidencia es

Haulos lo cuenta en una entrada de su blog del 28 de marzo de 2026, Building Useful Agents Over Email. La mayor parte del texto trata de desarrollo de software: desde su primer intercambio de emails con Claude Code, el 12 de enero de 2026, dice que ha trabajado «casi exclusivamente por email», con más de 1.000 pull requests en sus proyectos personales. Esa cifra se refiere a todos sus proyectos, no a la contabilidad.

La parte financiera es la sección «Accountant» (contable), y es relevante porque, según él, la herramienta que ahora usa para todo «nació como una rama de un sistema personal de contabilidad en texto plano». Quería dejar las hojas de cálculo por un sistema de partida doble de verdad, eligió Beancount y concluyó que la contabilidad en texto plano es una tecnología perfecta para unos modelos de lenguaje que trabajan con texto.

Dos matices antes de seguir:

• Tiene interés, pero no comercial en el artículo. Es el autor de Airut, el programa de código abierto (licencia MIT) sobre el que funciona su sistema, y quiere que se use. No vende nada, y el software fiscal que describe es privado.
• Los resultados son su propia descripción. No hay mediciones de tiempo ahorrado ni de errores, y nadie ajeno a su hogar ha revisado los libros ni el cálculo de impuestos. Además, sus categorías siguen la normativa fiscal finlandesa (cita el término finlandés para los gastos deducibles del trabajo), así que los detalles fiscales no se pueden trasladar.

Por eso lo clasificamos como caso real e identificado con resultados declarados, y lo contrastamos con otras personas que describen montajes parecidos en público.

El problema que resuelve

Las finanzas domésticas son un problema de pocos datos y mucha pereza. Hay muchos menos movimientos que en una empresa, pero llegan en formatos distintos (extractos en PDF, ficheros CSV, tickets por email), las categorías importan al hacer la declaración y nadie quiere pasar las tardes con ellas. La hoja de cálculo funciona hasta que necesitas partida doble, histórico de varios años o un cálculo que se pueda rastrear.

Las herramientas de contabilidad en texto plano, como Beancount, Ledger o hledger, resuelven el registro: todo el libro es un archivo de texto, cada asiento tiene que cuadrar y el archivo se puede versionar en Git y comparar como si fuera código. Lo que nunca resolvieron es el esfuerzo de alimentarlas. Ese es el hueco que llena un agente de código: leer entradas desordenadas, escribir importadores y reglas y mantener el archivo válido.

Herramientas y arquitectura

A partir de los dos artículos y de la documentación de Airut, las piezas son estas:

1. El libro. Uno o varios archivos de Beancount en un repositorio Git. Beancount es de código abierto, registra asientos de partida doble en texto plano y su verificador da error cuando un asiento no cuadra o falla una aserción de saldo.
2. Herramientas escritas por el agente. Haulos explica que, aunque Claude podría leer y editar los libros directamente, con el tiempo ha construido muchas herramientas e informes propios sobre Beancount. En el resumen de un vuelo aparecen pruebas de extremo a extremo para un script reconcile.py, una comprobación automática (CI) de que las huellas de los movimientos son únicas, una corrección de las transferencias entre entidades e importaciones de sus cuentas de 2025.
3. Un motor fiscal. Describe un motor de informes fiscales basado en un grafo de dependencias (DAG) que calcula su cuota con total transparencia y deja cada cifra enlazada con el libro y los extractos.
4. El ejecutor. Airut asocia un hilo de email o de Slack a una sesión de Claude Code. Según su artículo de febrero y la web del proyecto, cada tarea tiene su propio espacio de trabajo y corre en un contenedor Podman sin privilegios de root; el tráfico de red pasa por un proxy con una lista de destinos permitidos por repositorio; el contenedor solo recibe credenciales sustitutas que el proxy cambia por las reales en las peticiones aprobadas; y las listas se leen de la rama principal del repositorio, de modo que el agente no puede ampliarlas sin una pull request fusionada.
5. La revisión. El resultado vuelve en el mismo hilo de email como pull request, con enlaces a los informes generados y diferencias que entienden el contenido. Él revisa y fusiona.

En febrero escribió que se siente cómodo usando este modelo de aislamiento para trabajo real en proyectos con credenciales y datos financieros. Esa es la decisión de diseño clave: el agente trabaja con todos los permisos dentro de la caja, y es la caja la que decide a qué puede llegar.

Paso a paso: cómo montar algo parecido

El autor no publica su libro, sus prompts ni su motor fiscal, así que lo que sigue es nuestra reconstrucción de una versión mínima, con herramientas públicas y con los hábitos que describen las cuatro personas citadas más abajo. Adáptalo a tu país (en España, a tu declaración de la renta o a tus libros de autónomo).

1. Empieza el libro a mano

Crea un repositorio privado con un archivo main.beancount, un plan de cuentas corto (activos, pasivos, ingresos, gastos y patrimonio) y saldos de apertura sacados de extractos reales. Que sea pequeño: siempre podrás dividir cuentas después, y cada cuenta de más es una decisión más en la que el modelo puede equivocarse.

2. Que el agente escriba importadores, no asientos

Pasa a Claude Code un fichero de ejemplo de cada banco o tarjeta y pídele un script importador que convierta el fichero en asientos de Beancount. Jamie Tanna, que lo hizo para su declaración en Reino Unido con Ledger, solo dio al modelo las cabeceras del CSV, no los datos, y le dejó escribir los scripts de conversión. Así los datos personales no entran en el prompt mientras se construye el código.

3. Pon una huella a cada movimiento

Un usuario de Hacker News (zellyn) que montó un sistema parecido en una noche con Claude Code aconseja que el agente genere una huella para cada movimiento, para poder añadir correcciones individuales con facilidad. Las herramientas de Haulos tienen una comprobación automática de que esas huellas son únicas. Las huellas hacen seguras las reimportaciones y permiten fijar una corrección manual a un solo movimiento.

4. Guarda la categorización como reglas en el repositorio

Cuando corrijas una categoría, pide al agente que añada una regla, no solo que edite el asiento. En el ejemplo de LinkedIn el agente hizo las dos cosas: movió el cargo y añadió una regla para que los cargos futuros se categoricen solos. Las reglas son código que se puede revisar; los retoques sueltos no.

5. Aserciones de saldo y verificador siempre

Añade una aserción balance por cuenta en la fecha de cada extracto y deja escrito para el agente (por ejemplo, en su CLAUDE.md) que no propone nada si el verificador de Beancount no pasa. Las aserciones convierten «el agente dice que ha importado el extracto» en «el libro coincide con el banco en esa fecha».

6. Cada cambio, una pull request

Haz que el agente trabaje en una rama y abra una pull request con las diferencias y un informe breve (asientos nuevos, partidas sin categorizar, saldos que cambian). Revísala como revisarías el primer mes de un contable nuevo: lee lo marcado y comprueba algunos totales contra los extractos.

7. Aísla el agente antes de automatizar la entrada

Solo cuando el ciclo funcione desde la terminal, añade el email o el chat. Ejecuta el agente en un contenedor que vea el repositorio del libro y nada más, con acceso a la red limitado a lo imprescindible. El comentario de abound, más abajo, explica por qué.

8. Informes y vistas fiscales, al final

Cuando el libro sea fiable, pide consultas e informes (gasto por categoría, patrimonio neto, totales con relevancia fiscal de un periodo). Pide que el agente muestre la consulta que hay detrás de cada cifra para poder repetirla: eso es lo que hace que el número sea rastreable.

Un ejemplo concreto (tal como se publicó)

El único ejemplo completo del artículo empieza con una idea de pasada: Haulos se dio cuenta de que una suscripción a LinkedIn Pro que se le había renovado sola podía ser deducible, y escribió a Claude una sola frase por email, más o menos «pagué LinkedIn Pro en algún momento del año pasado».

Según la respuesta que reproduce, el agente:

• encontró el movimiento: 317,29 EUR el 18 de octubre de 2025 en una de sus tarjetas Visa, registrado en Expenses:Personal:Uncategorized;
• lo recategorizó a una cuenta de herramientas de trabajo deducibles según la normativa finlandesa;
• añadió una regla para que los cargos futuros de LinkedIn se categoricen automáticamente;
• actualizó el saldo inicial de su cuota pendiente de 2025 para reflejar la deducción adicional, con un efecto neto de −160,58 EUR;
• avisó de que, como la cuota estimada ya estaba pagada, debía esperar una devolución al presentar la declaración.

Después le pidió que comprobara si todo era correcto, y el agente lo confirmó con una explicación que citaba vero.fi (la Administración Tributaria de Finlandia) y otras fuentes. Si la deducción procede es cosa de la normativa finlandesa y de su declaración; lo que muestra el ejemplo es la forma del trabajo: una pregunta vaga se convierte en un movimiento localizado, un cambio revisable en el libro, una regla nueva y una cifra de impuestos recalculada, todo en una sola pull request.

Resultados declarados y otras voces

Lo que afirma Haulos es cualitativo: partida doble en lugar de hojas de cálculo, importaciones reducidas a enviar un email y un contable que lee el correo las 24 horas y que, además de llevar la contabilidad, desarrolla las herramientas para hacerlo bien. No publica cifras de tiempo ni de precisión.

Otras personas describen el mismo patrón en público:

• Jamie Tanna (1 de febrero de 2026) usó Ledger y hledger para preparar su primera declaración de autoevaluación en Reino Unido. Claude Sonnet 4.5 escribió los scripts que convierten las exportaciones de Stripe, Stripe Connect y Hyperwallet a partir solo de las cabeceras del CSV, y después él contestó cada apartado de la declaración con consultas de hledger. Dice que con documentos sensibles, como nóminas y extractos, solo usaría un modelo local, y estaba probando un modelo abierto pequeño para leer PDF.
• zellyn (Hacker News, 4 de enero de 2026) cuenta que Claude Code le montó un sistema completo de finanzas en texto plano a partir de los ficheros descargados del banco en una hora, y que luego pasó la noche afinando las reglas de categorización.
• SOLAR_FIELDS (Hacker News, 11 de agosto de 2026) dice que Claude le lleva la contabilidad de su negocio sobre un libro de Beancount desde hace aproximadamente un año y que le ha funcionado bastante bien. Una frase, sin detalles.
• Bobby Huang, socio de una firma de CPA (contables colegiados de EE. UU.), publicó en julio de 2026 una guía que presenta Claude con Beancount como un patrón de la comunidad para conservar el libro entre sesiones, con los movimientos dudosos marcados para revisión en lugar de adivinados.

Ninguno es una comparación controlada, pero todos apuntan en la misma dirección: el texto plano más un agente de código elimina casi toda la fricción que hacía de la contabilidad en texto plano una afición de programadores.

Limitaciones y riesgos

• Privacidad y alcance. Un agente que puede leer tu disco puede leer más que tu libro. En Hacker News, abound cuenta que, mientras convertía a Beancount la contabilidad de una organización sin ánimo de lucro, Claude encontró su libro personal de Beancount en otra carpeta del disco y basó su plan en él; lo califica de extralimitación y de motivo para aislar a los agentes a partir de ahora. El contenedor por tarea de Haulos responde justo a ese riesgo; una sesión en el portátil con permisos amplios, no.
• Los modelos alojados ven tus datos. Extractos, tickets y documentos fiscales llegan al proveedor del modelo salvo que uses un modelo local. Tanna marca esa línea de forma explícita.
• La lógica fiscal es lo más arriesgado. Un cálculo rastreable solo es tan correcto como las reglas que lleva dentro, y que el modelo confirme que está bien no es una revisión. El ejemplo de Haulos acaba con el agente citando a la administración tributaria, lo que ayuda, pero las reglas son finlandesas y el resultado no está verificado.
• Las herramientas propias hay que mantenerlas. Decenas de miles de líneas de código escritas por un agente (solo Airut tiene 35.000 líneas de Python, según él) son un activo si tienen pruebas; Haulos invierte mucho en pruebas, algo que la mayoría de los hogares no hará.
• Evidencia de una sola persona. Un autor, un ejemplo desarrollado y ninguna auditoría externa.

Errores comunes

• Dejar que el agente escriba asientos directamente en la rama principal. Sin pull request ni verificador en verde, una importación errónea pasa a la historia del libro.
• Saltarse las aserciones de saldo. Sin ellas, los duplicados y los movimientos que faltan no aparecen hasta el cierre del año.
• Dejar que el modelo invente cuentas. Limita la categorización a las cuentas que ya existen y crea las nuevas de forma deliberada.
• Corregir asientos en lugar de reglas. El mismo error vuelve el mes siguiente.
• Darle al agente toda la carpeta personal. Monta solo el repositorio del libro.
• Tomar la seguridad del agente como asesoramiento fiscal. Comprueba las deducciones en la fuente oficial (en España, la Agencia Tributaria) y, si lo que está en juego lo justifica, con un asesor.

Conclusiones

El interés de este caso no está tanto en el truco del email como en la combinación que hay debajo: un libro en texto que una máquina puede validar, un agente que escribe herramientas y reglas en lugar de retoques sueltos, un entorno aislado que limita a qué puede llegar y una pull request como el momento en que decide una persona. Cada pieza existía por separado; lo que aporta Haulos es enseñarlas funcionando juntas con sus finanzas personales reales. Para un hogar o un autónomo, la lección trasladable es empezar por el libro, el verificador y la revisión, y dejar para el final la puerta de entrada cómoda.