Skip to main content
Los eventos de dinero, como un desembolso, un pago o un devengo de intereses, llegan al . La capa contable de Lender es cómo llegan allí. Un producto declara sus reglas de asiento una vez. A partir de entonces, cada uno de esos eventos se contabiliza de forma automática y trazable.

​
Perfiles contables y reglas de asiento

Un perfil contable vincula una versión de producto al ledger. Define las reglas de asiento: las patas de que se disparan para cada tipo de evento financiero. También define la organización del ledger y el ledger en los que se contabilizan las transacciones resultantes. Creas un perfil por producto: POST /api/v1/loan-products/{id}/accounting-profiles Lender valida las reglas de asiento cuando creas el perfil. Por eso un producto no puede entrar en producción con patas que no cuadren.

​
Intenciones de asiento y el relay

Lender no llama al ledger en línea. Cuando ocurre un evento financiero, Lender persiste una intención de asiento durable. Esa escritura ocurre en la misma transacción de base de datos que cambia el estado del dominio. Después, un relay envía la transacción balanceada a Midaz de forma asíncrona. Esto es lo que hace confiables las contabilizaciones:
  • La intención se confirma junto con el cambio de estado: ambos aterrizan en una sola transacción de base de datos, a través de un outbox transaccional.
  • Idempotente: cada asiento lleva una clave determinista, así que los reintentos colapsan en una sola transacción del ledger.
  • Falla cerrado: si el enrutamiento no puede resolver un destino de ledger no vacío, Lender rechaza el asiento y no lo escribe en el lugar equivocado.
Lender en la plataforma describe la vía completa.

​
Corridas de devengo

Una corrida de devengo reconoce los intereses y los demás montos basados en el tiempo. Una corrida cierra el último mes civil que ya había terminado por completo antes de su fecha hábil, para cada préstamo que selecciona. También produce los asientos de ese mes. POST /api/v1/accrual-runs empieza una corrida. Lender selecciona por sí mismo las cuentas de préstamo candidatas, reconoce los intereses por cuenta y escribe una intención de asiento por cada reconocimiento.
El reconocimiento es idempotente por cuenta de préstamo, por mes contable y por tipo de monto. Una corrida empezada dos veces para el mismo mes reconoce los intereses una sola vez.

​
Repetir una corrida

Un reconocimiento queda durable en el instante en que la corrida hace commit. La contabilización en el ledger no queda durable. Cuando un asiento nunca llega, repite la corrida en vez de empezar una nueva. POST /api/v1/accrual-runs/{id}/retry nombra los ítems a reenviar y toma el mismo encabezado X-Idempotency que toma la corrida misma. Es un segundo intento sobre la misma corrida, así que Lender no registra una segunda corrida. Lender rearma el asiento detrás de cada ítem nombrado que el ledger no confirmó, y lo encola bajo la clave determinista que usó la corrida original. El relay lo entrega, y el ledger trata un duplicado como duplicado y no como una segunda contabilización. Lender deja intactos los ítems que el ledger ya confirmó. La respuesta nombra, ítem por ítem, lo que no pudo reenviar. También nombra el porqué: el asiento ya había sido entregado, quedó en cuarentena, el contrato detrás de él desapareció, o el producto está mal configurado.
Una repetición rechaza con LENDER-0405 cuando el asiento que rearma es distinto del que ya está encolado bajo esa clave. El perfil contable del producto cambió después de la corrida, así que reenviar contabilizaría el mes contra piernas que nadie eligió para él. Concilia primero el asiento encolado, porque repetir el pedido reproduce el mismo rechazo.

​
Referencias de diario

Cada corrida de devengo registra una referencia de diario, el identificador contable propio de la corrida. El registro de la referencia también guarda el id de correlación que Lender derivó para la corrida. El id de la referencia de diario identifica exactamente una corrida. Una lectura por id de correlación devuelve la corrida más reciente que comparte ese modo, esa fecha hábil y ese ámbito de producto. Solo que una corrida no es un asiento único: emite uno por cuenta de préstamo, por mes contable, por tipo de monto. Lender registra entonces el lazo de vuelta con el ledger por asiento, no por corrida. Apenas el ledger confirma un asiento, Lender guarda un recibo bajo la clave de ese asiento. Una lectura por esa clave responde con la transacción del ledger que lo contabilizó. Una referencia a nivel de corrida no carga transacción de ledger propia: nombra la corrida, y los recibos nombran las contabilizaciones.

​
Próximos pasos

Jurisdicciones

Mira cómo la jurisdicción activa moldea las divulgaciones y los endpoints.

Paquete regulatorio de Brasil

Suma el CET, el IOF y la clasificación en etapas de PDD sobre el modelo contable.