Tus posiciones ya están en el libro contable. Sus precios son la parte que no paras de reescribir.
Esa asimetría es la tarea más antigua de la contabilidad de texto plano. Una compra se escribe una vez y es verdad para siempre: 120 NWRB {41.80 USD, 2024-03-12} registra una cantidad, un coste y una fecha, y nada de lo que ocurra después cambia ninguno de los tres. Un precio es lo contrario: correcto durante un día, y después silenciosamente erróneo, y erróneo de una forma que ninguna comprobación de saldo detectará jamás, porque un precio obsoleto sigue cuadrando a la perfección. La propia respuesta de Beancount siempre ha sido obtenerlos con una herramienta y confirmar la salida, lo cual funciona y mucha gente ha automatizado. Pero sigue siendo un script que es tuyo, una entrada de cron que mantienes, y un fichero que fusionas.
El motor de libros contables de beancount.io ahora hace esa resolución por sí mismo, para los libros alojados con nosotros. Este artículo trata de lo que realmente se ha implementado, de lo que deliberadamente no toca y — igual de importante — de lo que todavía no está construido.
Lo que se ha implementado
Un libro alojado en beancount.io puede llevar un include cuyo destino sea una URL en lugar de un nombre de fichero:
; main.bean, in a hosted beancount.io ledger.
;
; The managed line is shown commented out on purpose: upstream `include` takes a
; file glob, so this file still loads if you copy it to your own machine. Only
; the hosted engine resolves the URL form.
option "title" "Taxable brokerage"
option "operating_currency" "USD"
include "accounts.bean"
; include "https://beancount.io/prices/ACME-USD"
include "transactions/purchases.bean"
include "transactions/sales.bean"El include del Beancount original toma un nombre de fichero — "la ruta especificada puede ser un nombre de fichero absoluto o relativo" es toda la especificación — así que un include con URL no es Beancount estándar y nunca pretende serlo. Es un comportamiento del motor alojado, y esto es exactamente lo que el motor hace con él:
- Materializa el feed como un fichero virtual de solo lectura. La URL se resuelve a través de la propia ruta de resolución de includes del motor, exactamente donde habría aterrizado un fichero local, así que cada directiva conserva una ubicación de origen real. Tus bytes nunca se reescriben. El fichero que escribiste sigue siendo el fichero que escribiste.
- El cuerpo obtenido se valida como solo-precios. Directivas
price, comentarios y cuatro claves de metadatos permitidas —price-source,price-kind,observed-atyprovisional— y nada más. Cualquier cosa más allá de eso rechaza el cuerpo entero. No hay ingesta parcial, así que un feed nunca puede colar una transacción en tus libros. - Los feeds se cachean como una revisión inmutable más un puntero móvil. La actualización se rige por una marca temporal en lugar de por la expiración de la caché, lo que significa que una caída del proveedor no puede llevarse por delante tu última revisión buena. Una actualización fallida nunca sustituye una revisión buena por nada.
- La frescura se calcula cuando se lee el libro contable, no se almacena:
recent,staleounavailable, junto con el momento de observación que el propio feed reportó. Un precio que no puedes fechar es un precio que no puedes auditar. - Las entradas gestionadas son de solo lectura. Editar o borrar una se rechaza con un error que nombra la fuente gestionada, y no cuentan contra los límites de directivas — al feed no se le permite consumir el presupuesto de tu libro contable.
Todo lo de esa lista se ejecuta dentro del servicio de libros alojados. Nada de ello cambia lo que significa una directiva price: sigue estableciendo el tipo de cambio entre una mercancía base y una mercancía cotizada, exactamente como lo define la referencia del lenguaje. El trabajo del motor es solo poner delante del cargador precios correctos, fechados y atribuibles.
Tu propio precio siempre gana
Esta es la parte que decide si un feed es utilizable por alguien que se toma su libro contable en serio, así que se enuncia con exactitud.
Para la misma fecha y el mismo par de mercancías — y para el par recíproco — un precio que hayas escrito tú mismo gana sobre el feed gestionado, independientemente del orden de los includes.
No "normalmente", y no "si pones tu include al final". La decisión de ensombrecimiento se toma antes de construir el mapa de precios, así que no depende de dónde esté el include en el fichero. Muévelo arriba, muévelo abajo, divídelo en tres ficheros: la respuesta es la misma.
; include "https://beancount.io/prices/ACME-USD" ; hosted-engine form, again shown commented
; A price you wrote yourself, for the same date and pair.
; This one wins — above the include or below it, it makes no difference.
2026-09-16 price ACME 93.40 USD(ACME es el emisor ficticio del libro de ejemplo de más abajo; el número es inventado, no una observación de mercado.)
Por qué esa regla y no la otra: un precio en tu propio fichero es una decisión. Puede ser el cierre que tu bróker imprimió en el extracto contra el que estás conciliando, una cotización contemporánea para una posición de poca liquidez, o una cifra que tu contable te pidió usar. Un feed no sabe nada de eso, y un sistema que sobrescribe silenciosamente una cifra escrita por un humano ha dejado de ser un libro contable y ha empezado a ser una opinión. El feed rellena huecos; no te corrige.
Los precios mueven la valoración, y nada más
La segunda garantía es estructural en lugar de una decisión de política, y merece mostrarse con números reales en vez de afirmarse. Aquí está el libro de ejemplo de cripto — lotes fechados, staking, minería, posiciones DeFi, airdrops:
Toma una entrada de él. Llega un airdrop de token de gobernanza y se registra como ingreso a valor de mercado razonable el día en que aterriza:
2024-03-20 * "Uniswap" "Receive UNI governance token airdrop"
Assets:Crypto:Wallet:MetaMask:UNI 50.00 UNI {12.50 USD, 2024-03-20}
Income:Crypto:Airdrops -625.00 USDEsos 625,00 $ de ingreso, y la base de 12,50 $ por unidad asociada al lote, son ahora hechos sobre el 2024-03-20. Toda directiva de precio en el libro contable — gestionada, escrita a mano o ausente por completo — deja ambas intactas. Los precios cambian el valor de mercado; nunca cambian cantidades, base de coste, flujos de caja, comisiones ni ganancias realizadas. Que es precisamente por lo que un feed de precios es algo seguro con lo que aceptar ayuda: lo peor que puede hacer un precio erróneo es informar mal de cuánto vale hoy una posición, y nunca puede corromper la cifra que pondrás en una declaración de la renta.
Dónde te engaña de verdad un modelo de precios erróneo
El libro de ejemplo de acciones y ETF deja más afilada la misma idea:
Contiene un split de acciones 4 a 1, y el split se registra de la forma correcta — como un cambio de cantidad que preserva la base total, sin tocar ninguna cuenta de ingresos:
2025-07-15 * "Broker" "NWRB 4-for-1 share split — quantity change, not income"
Assets:Brokerage:NWRB -120 NWRB {41.80 USD, 2024-03-12}
Assets:Brokerage:NWRB 480 NWRB {10.45 USD, 2024-03-12}Ambos lados son 5.016,00 $. El valor de mercado no cambia con el split — 120 acciones a 62,00 $ el día anterior, 480 acciones a 15,50 $ el día siguiente, 7.440,00 $ en cualquier caso — y la fecha de adquisición entre llaves sobrevive, que es lo que mantiene a largo plazo una venta de esas acciones en 2026.
El error habitual es registrar un split como un evento de precio y apoyarse en una serie "ajustada por split" para que la valoración salga bien. Eso funciona solo mientras todos los precios que veas hayan sido ajustados de la misma manera. En el momento en que llega una cifra sin ajustar — una confirmación antigua, una captura de pantalla, una serie de terceros que no reexpresa nada — la posición se valora al cuádruple de su valor, y el número de acciones en el libro contable ya no cuadra con el extracto del bróker, así que la aserción de fin de año que lo habría detectado no puede dispararse.
Este es el argumento real a favor de un feed de precios con una fuente declarada, un tipo declarado y un momento de observación visible: no la comodidad, sino saber bajo qué convención se calculó el número que acabas de importar. El propio fichero de precios del libro de ejemplo es deliberadamente sin ajustar y lo dice, y sus dos directivas que cruzan el split están escritas como una comprobación que puedes verificar a ojo.
Una nota honesta sobre pinchar en cualquiera de los embeds: el visor de libros alojados renderiza los saldos de las cuentas a coste, y no ofrece ningún control de valoración en la página. Los libros de arriba están ahí para mostrarte los libros — los lotes, el split, las ventas de lotes específicos — no una valoración de mercado que el visor no dibuja actualmente. Ambos son públicos, y ambos se pueden clonar y ejecutar en local.
Lo que todavía no está aquí
Una entrada de changelog vale menos que nada si te deja creer algo que no es cierto, así que aquí está la otra mitad, sin rodeos y sin poner fecha a nada de ello.
- El endpoint de precios no es público. Una petición anónima a
https://beancount.io/prices/<ALIAS>se redirige a la página de inicio de sesión. No hay catálogo público de alias. - Así que esto no es algo que puedas pegar en tu propio fichero hoy. El motor resuelve el include; la ruta que resuelve aún no está abierta. Cuando lo esté, eso tendrá su propia entrada de changelog.
- La CLI local
beano resuelve includes con URL. Lee ficheros del disco, así que un include con URL falla localmente como un glob de ficheros que no coincide con ninguno. El soporte del cargador en la CLI es un seguimiento ya nombrado. - No hay superficie de API. Ni REST, ni GraphQL ni campo MCP para precios gestionados.
- No hay superficie de panel. Ni pantalla de conectar-un-feed ni etiqueta de frescura en la interfaz; la frescura que calcula el motor no tiene dónde mostrarse todavía.
- Las instantáneas y la exportación no están construidas, y tampoco lo están un catálogo de instrumentos ni un endpoint de actualización manual.
Lo que se ha implementado es la capa del motor: la resolución de includes, la validación, la caché de revisiones, la regla de precedencia y el cálculo de frescura. Esa es la parte sobre la que todo lo demás tiene que sostenerse, y es la parte más difícil de cambiar después, que es por lo que fue primero.
Dónde mirar a continuación
Ambos libros de arriba forman parte de la galería de ejemplos, seis patrones trabajados que puedes clonar y ejecutar en local — estos dos incluyen ficheros de precios estáticos y versionados a propósito, para que un clon hecho dentro de dos años siga produciendo el informe que produce hoy. Todo lo demás que publicamos aparece en el changelog.
Si sigues manteniendo los precios al día con un obtenedor propio, esa sigue siendo la respuesta correcta para un libro contable local, y la propia documentación de obtención de precios de Beancount, junto con la herramienta mantenida beanprice, son por donde empezar.
Mantén aburrida la parte aburrida
La razón por la que los precios merecen automatizarse es que son la única parte de un libro contable de texto plano que se degrada por sí sola. Beancount.io te da contabilidad de texto plano que sigue siendo tuya — auditable, bajo control de versiones y nunca reescrita a tus espaldas, que es exactamente el estándar que un feed gestionado tenía que cumplir antes de que publicáramos uno. Empieza gratis y mantén tus libros en ficheros que puedes leer.
