> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Contabilidad y ejecuciones de devengo > Descubre cómo Lender se contabiliza en el ledger: perfiles contables, reglas de posting, intenciones durables, ejecuciones de devengo y referencias de asiento. export const GDoubleEntry = ({children}) => {children} ; export const GLedger = ({children}) => {children} ; El desembolso y el devengo de interés llegan al ledger, y también un prepago que liquida una cuenta de préstamo brasileña contra una cotización de prepago. La capa contable de Lender es cómo llegan ahí: un producto declara sus reglas de posting una vez, y de ahí en adelante cada uno de esos eventos se contabiliza de forma automática y rastreable. ## Perfiles contables y reglas de posting *** Un **perfil contable** ata una versión del producto al ledger. Define las **reglas de posting** — los asientos de partida doble que se disparan para cada tipo de evento financiero — y la organización de 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` Las reglas de posting se validan cuando se crea el perfil, así un producto no puede salir a producción con asientos que no balancearían. ## Intenciones de posting y el relay *** Lender no llama al ledger de forma inline. Cuando ocurre un evento financiero, persiste una **intención de posting** durable en la misma transacción de base de datos que cambia el estado del dominio, y luego un relay contabiliza la transacción balanceada en 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 caen en una sola transacción de base de datos, a través de un outbox transaccional. * **Idempotente** — cada posting lleva una clave determinista, así los reintentos colapsan a una sola transacción del ledger. * **Falla cerrado** — si el enrutamiento no puede resolver un destino de ledger no vacío, el posting se rechaza en lugar de escribirse en el lugar equivocado. La ruta completa se describe en [Lender en la plataforma](/es/lender/lender-in-the-platform). ## Ejecuciones de devengo *** Una **ejecución de devengo** reconoce el interés y los demás montos basados en el tiempo. Una ejecución toma cada préstamo cuyo aniversario cae en su fecha de negocio, y produce los postings correspondientes. `POST /api/v1/accrual-runs` inicia una ejecución. Lender selecciona por su cuenta las cuentas de préstamo candidatas, reconoce el interés de cada una y escribe una intención de posting por reconocimiento. El reconocimiento es idempotente por cuenta de préstamo, por mes contable y por tipo de monto. Una ejecución iniciada dos veces para el mismo mes reconoce el interés una sola vez. ## Referencias de asiento *** Cada ejecución de devengo registra una **referencia de asiento** — el identificador contable de la propia ejecución. El registro de la referencia también guarda el id de correlación que Lender derivó para la ejecución. El id de la referencia de asiento identifica una sola ejecución de forma exacta; una lectura por id de correlación devuelve la ejecución más reciente que comparte ese modo, esa fecha de negocio y esos productos acotados. | Operación | Propósito | | ------------------------------------- | ------------------------------------------------------ | | `GET /api/v1/journal-references` | Busca una referencia de asiento por id de correlación. | | `GET /api/v1/journal-references/{id}` | Lee una referencia de asiento. | ## Próximos pasos *** Mira cómo la jurisdicción activa moldea las divulgaciones y los endpoints. Superpón CET, IOF y staging de PDD sobre el modelo contable.