Gastos

Entrada única al dominio de gasto corriente: qué se gasta, qué parte es compartida con entity:pareja, qué es recurrente y qué es pico. El estado numérico vive en el ledger cifrado; esta página dice cómo está montado el sistema y dónde mirar.

Estado del sistema

Ledger activo: ledger/expenses/YYYY-MM.jsonl 🔒, un registro por transacción, desde 2026-04 (primera ventana con cobertura completa de exports Chase). Schema: ledger/_schemas/expense.v1.json.
Registro semántico de comercios: ledger/expenses/_merchants.json 🔒. Cada comercio declara una sola vez qué es, su categoría y su split por default; de ahí en adelante clasifica solo. Seed inicial derivado de las ~400 decisiones históricas de la sheet compartida (ene-ago 2026).
Registro de liquidaciones: ledger/expenses/_settlements.json 🔒, con las tres rondas que existen hasta hoy: la de enero-abril (liquidada antes de que hubiera ledger, se declara para poder marcar qué cubrió), la de abril-agosto (pagada a medias, el resto en camino) y una de servicios que se habían cobrado por Splitwise, abierta como por-confirmar sobre la memoria de una conversación y confirmada después contra la app. Cada cierre dice qué ventana cubrió, cuál era el neto, con qué pagos se movió y qué documento lo respalda; el settled_in de cada registro apunta a ese id (S-001, S-002…) y ya no a un mes, porque una ronda cruza meses y un mes puede quedar partido entre dos cierres. Se abre a mano contra el estado de cuenta: el script solo estampa los registros que la ventana cubre y avisa si el neto declarado no cuadra con el que sale del ledger. Schema: ledger/_schemas/settlements.v1.json.
Herramienta: bin/reconcile (import | sync | capture | queue | resolve | report YYYY-MM | pending | settle). Tres puertas alimentan el ledger: import estrena meses desde el export, sync reconcilia contra fuentes que ya cambiaron, capture registra lo que no pasa por la tarjeta. El ciclo completo está descrito en el protocolo.
Pendientes abiertos: ledger/expenses/_pending.json 🔒 rastrea disputas y reembolsos esperados (fraudes reportados, fianzas por devolver). El reporte mensual los imprime hasta que se resuelven: nada queda flotando en la memoria de nadie.
Fuente: exports de la tarjeta Chase a raw/assets/, más el lado compartido de entity:pareja (hoy: la sheet, re-exportada cada vez que la ronda avanza; destino: statement mensual emitido por su propia instancia del corpus), más lo capturado a mano.

Qué objetivos toca

O-001 🔒: el objetivo de gasto mensual. Los reportes del ledger separan baseline recurrente, variable y one-offs precisamente para que O-001 se contraste contra el gasto estructural y no contra totales distorsionados por picos.

Cómo leer el gasto (las tres capas)

Baseline recurrente: compromisos estables (renta, suscripciones, gym). Se vigila por delta contra el mes anterior: un cambio aquí es estructural.
Variable por categoría: el gasto habitual (súper, restaurantes, transporte). Se compara contra su mediana trimestral.
One-offs: neto mensual por comercio que supera el umbral del protocolo. Lista corta, nombrada, para internalizar uno por uno; los que fueron decisiones merecen página decision.

El split con entity:pareja se emite por mes: qué debe cada quien y el neto. El mes es la unidad de lectura, el cierre es la de cobro: cuando el saldo se paga, ese acto se declara una vez en el registro de liquidaciones y settled_in lo estampa en cada registro que cubrió. Los movimientos que no son gasto (un Bizum prestado, un reembolso) mueven ese saldo y no el gasto del mes: se reportan aparte y no entran al ledger.

Pendientes conocidos

Gastos fuera de Chase: cerrado del lado de la sheet compartida (luz, agua, internet, limpieza, club entran solos desde el bloque de entity:pareja), abierto del propio. Bizum y efectivo míos tienen puerta (capture) pero no automatismo: si no los capturas, nadie los echa de menos y el baseline miente por abajo.
Deriva de ids: los id que viven en el ledger no los reproduce la receta actual de txn_id, así que regenerar un mes desde cero lo duplicaría entero. sync esquiva el problema comparando por identidad natural en vez de por id, pero no lo cura. Es la deuda más cara del sistema.
Comercios que estrena la sheet: llegan con el split correcto (la fila lo trae) y sin categoría, así que caen en otros hasta declararlos en _merchants.json. Los de la primera tanda ya están puestos; el riesgo es permanente porque cada ronda nueva puede traer más, y ahí un recurrente de servicios se vuelve invisible dentro del cajón de sastre. Un cuidado extra: el concepto de esas filas lo teclea una persona y cambia cada vez (“gimeno”, “gimeno torneo”, “gimeno titulo”), así que sin regla de alias el mismo comercio estrena handle cada mes y la detección de recurrencia nunca ve la serie.
Splits con terceros (splitwise en viajes con amigos): v1 no los modela; un gasto reembolsado por fuera infla el costo propio del mes del viaje.
Instancia de entity:pareja: cuando exista, la sheet muere y el split corre por statements mensuales cruzados entre corpus (solo lo compartido y el saldo cruzan, en ambas direcciones).
Alineación de categorías con O-001: la taxonomía del ledger debe cuadrar con la lista cerrada de categorías que O-001 heredó de D-007.

Páginas relacionadas

reconcile-gastos.md: el protocolo del ciclo mensual, con la metodología de taggeo y las reglas de clasificación.
finanzas.md: el mapa de dinero del que este hub es spoke; metas y portafolio, más el link a impuestos.
impuestos.md: los pagos al fisco cuando cruzan la tarjeta o el capture.
cuerpo.md: gasto ligado al movimiento y a la nutrición (club, clases, material, súper) cuando cruza el ledger o el split.
vida.md: baseline de vivienda y servicios, picos de mudanza y costo de órbita entre anclas.
pendientes.md: la cola que indexa _pending.json sin copiarlo.
_index.md: el dominio en el mapa general del corpus.