Ledger double-entry: cómo diseñamos un motor contable que nunca pierde un centavo

Por qué la doble entrada importa en fintech — y por qué la mayoría de las fintechs lo hacen mal

Los sistemas de entrada simple rastrean saldos. Los de doble entrada rastrean el movimiento de valor. Para instituciones financieras reguladas, esto no es opcional — es obligatorio.

Pero aquí está lo que la mayoría de los ingenieros fintech no entienden: la contabilidad de doble entrada no es solo un checkbox regulatorio. Es el único sistema contable que es auto-verificable. Cada débito tiene un crédito correspondiente. Si los débitos totales no igualan los créditos totales, algo está mal — y puedes encontrarlo.

Los sistemas de entrada simple no pueden decirte cuándo algo está mal. Rastrean un saldo: +R$ 100, -R$ 50, saldo = R$ 50. Si un bug suma R$ 100 sin restarlo de algún lado, el saldo dice R$ 150 y nadie sabe que hay un problema hasta que un reporte de reconciliación lo detecta — días o semanas después.

En un sistema de doble entrada, ese bug es imposible. No puedes acreditar una cuenta sin debitar otra. El sistema impone conservación de valor a nivel de transacción, no como una verificación posterior.

La epidemia de ledgers fintech: tablas de balance pretendiendo ser ledgers

Déjame describir lo que el 80% de las fintechs llaman su "ledger":

Una tabla PostgreSQL llamada balances con columnas: account_id, currency, available, pending, blocked. Cuando llega un pago, el sistema ejecuta UPDATE balances SET available = available + 100 WHERE account_id = 'abc'.

Esto no es un ledger. Es un rastreador de saldos. Y tiene defectos fatales:

Sin trail de auditoría

UPDATE sobrescribe el valor anterior. Una vez que el saldo cambia de R$ 500 a R$ 600, no hay registro del estado R$ 500.

Condiciones de carrera

Dos transacciones concurrentes leen available = 500, ambas suman R$ 100, ambas escriben R$ 600. La cuenta debería tener R$ 700 pero tiene R$ 600. Acabas de crear — o destruir — R$ 100 de la nada.

Sin capacidad de reconciliación

¿Cómo verificas que el saldo es correcto? Necesitarías repetir todas las transacciones históricas. Pero no las tienes — solo tienes el saldo actual.

Errores de redondeo se acumulan silenciosamente

Cuando calculas una tasa de plataforma del 12.5% sobre R$ 99,99 (= R$ 12,49875), redondeas a R$ 12,50. Sobre millones de transacciones, estos errores se acumulan. En un sistema de entrada simple, nadie lo nota hasta que la reconciliación de fin de trimestre revela una discrepancia de R$ 47.000.

La arquitectura de ledger de Revenu: los 11 engines

Nuestro ledger no es una sola tabla ni un solo servicio. Es un sistema de 11 engines especializados:

1. Core Ledger Engine

La fundación. Maneja asientos de doble entrada, impone la ecuación contable (Activos = Pasivos + Patrimonio), y garantiza que cada transacción balancea a cero.

2. Chart of Accounts Engine

Gestiona la estructura jerárquica de cuentas. Cada cuenta se clasifica según un plan de cuentas que mapea a COSIF — la clasificación contable obligatoria de BACEN.

3. Multi-Currency Engine

Maneja cuentas denominadas en diferentes monedas, rastreo de tasas de cambio y asientos de conversión de moneda.

Cuando un pago transfronterizo convierte USD a BRL, el engine crea pares de asientos que capturan el tipo de cambio exacto, el timestamp de conversión y la fuente de la tasa — todo inmutablemente.

4. Escrow Engine

Gestiona cuentas escrow para splits de marketplace, retenciones de pago y cronogramas de liquidación.

5. Fee Engine

Calcula y registra tasas de plataforma, MDR, interchange, costos de gateway y tasas de anticipación. Cada tasa es un par de asientos separado — nunca una deducción silenciosa de un saldo.

6. Provisioning Engine

Maneja provisiones para pérdidas esperadas — provisiones de pérdida crediticia, provisiones de chargeback y requisitos de capital regulatorio.

7. Accrual Engine

Gestiona reconocimiento de valor basado en tiempo: acumulación de intereses en préstamos, reconocimiento de tasas sobre períodos de servicio e ingresos diferidos.

8. Tax Engine

Calcula y registra IOF, IRRF, ISS y contribuciones PIS/COFINS. Los asientos de impuestos son separados de la transacción subyacente.

9. Reconciliation Engine

Reconcilia continuamente el estado del ledger interno contra fuentes externas: estados bancarios, reportes de liquidación PSTI, archivos de liquidación de redes de tarjetas.

La reconciliación corre como un proceso streaming, no como un batch job. Cada evento externo se empareja contra asientos internos en tiempo real.

10. Reporting Engine

Genera estados financieros COSIF-compliant, balances generales, estados de resultados y reportes de flujo de caja — todo desde datos del ledger.

11. Archive Engine

Maneja el ciclo de vida de datos del ledger: compresión de asientos históricos, offloading a almacenamiento frío, y recuperación garantizada para solicitudes de auditoría. Requisito regulatorio: 10 años de historial completo.

El principio de inmutabilidad: por qué nunca hacemos UPDATE

Cada entrada de ledger en Revenu es inmutable. Una vez escrita, no puede modificarse ni eliminarse. Nunca.

Nivel de base de datos

Las tablas de ledger no tienen permisos de UPDATE o DELETE. El usuario de base de datos de la aplicación solo puede INSERT y SELECT.

Nivel de aplicación

El servicio de ledger expone solo dos operaciones: post(entries) y query(filters). No hay endpoint de update o delete.

Mecanismo de corrección

¿Qué pasa cuando algo está mal? No corriges la entrada incorrecta — creas una nueva entrada de reversión que la neutraliza, luego creas una nueva entrada corregida. El trail de auditoría muestra exactamente qué pasó, cuándo y por qué.

Event Sourcing + doble entrada: un match natural

Nuestro ledger está construido sobre Event Sourcing. Cada operación financiera emite eventos de dominio. El ledger es una proyección de esos eventos.

Porque los eventos son inmutables y ordenados, el ledger puede reconstruirse desde cero repitiendo todos los eventos. Hacemos esto periódicamente como verificación: reconstruimos el ledger entero desde el event store y lo comparamos con el ledger en vivo. Si coinciden (siempre han coincidido), sabemos que el ledger es correcto.

Esta es la garantía de auditoría definitiva: el ledger no es solo auditable — es reconstruible.

Reconciliación en tiempo real

La reconciliación tradicional es un proceso batch. Al final del día, alguien compara registros internos contra estados bancarios externos. Las discrepancias encontradas hoy pueden relacionarse con transacciones de hace 3 días.

Nuestro engine de reconciliación opera en tiempo real:

Matching por eventos

Cuando llega un evento externo (confirmación PIX del SPI, confirmación TED del CIP), el engine inmediatamente lo empareja con el asiento interno correspondiente.

Verificación continua de balance

Cada 60 segundos, el engine verifica la ecuación contable fundamental:

SUM(todos_los_débitos) == SUM(todos_los_créditos)

Si esta ecuación no se cumple — incluso por R$ 0,01 — se dispara una alerta inmediatamente.

Performance: 50.000 asientos por segundo

Paralelismo a nivel de cuenta

Transacciones que tocan diferentes cuentas se ejecutan en paralelo. Solo transacciones que tocan la misma cuenta se serializan.

Batch posting

Múltiples pares de asientos de la misma operación se agrupan en una sola transacción de base de datos.

Escrituras append-only

Entradas inmutables son append-only. Sin row locks, sin ciclos read-modify-write. Solo INSERT.

Los números de producción

Después de 18 meses y R$ 8 mil millones en volumen procesado:

• Discrepancia de balance: R$ 0,00 — el ledger nunca ha estado desbalanceado
• 11 engines especializados trabajando en concierto
• 50.000 asientos/segundo throughput sostenido
• < 5ms latencia de asiento (p99)
• 100% alineación COSIF — sin capas de traducción para reporting regulatorio
• Reconciliación en tiempo real — discrepancias detectadas en < 60 segundos
• 0 correcciones manuales — todas las correcciones son reversión automática + re-posting
• Archivo de 10 años — historial completo, recuperable en < 48 horas
• Verificación por reconstrucción de ledger: reconstrucción mensual completa desde event store — 100% coincidencia cada vez

Por qué esto importa

Un ledger no es una feature. Es la fundación de todo lo demás: pagos, compliance, reporting, reconciliación, auditoría. Si el ledger está mal, todo lo construido sobre él está mal.

Diseñamos nuestro ledger para hacer estos escenarios imposibles. No improbables — imposibles. La conservación de valor se impone a nivel de transacción. La inmutabilidad se impone a nivel de base de datos. La reconciliación corre continuamente. La ecuación contable se verifica cada 60 segundos.

El resultado: un ledger en el que puedes confiar. No porque alguien dice que es correcto, sino porque la arquitectura hace matemáticamente imposible que esté mal.

Eso es lo que la contabilidad de doble entrada fue diseñada para hacer hace 700 años. Nosotros simplemente la implementamos correctamente.