Skip to main content
Después del desembolso, un préstamo se convierte en una cuenta de préstamo, la vista de administración del contrato vivo. La administración cubre toda la vida de la cuenta. Entra dinero, el cronograma cambia y corriges errores sin reescribir la historia.

​
Leer la cuenta

​
Registrar dinero

1

Previsualizar la asignación

POST /api/v1/loan-accounts/{id}/preview-repayment muestra cómo asignaría Lender un pago entre las cuotas pendientes sin registrarlo. Lender paga primero la cuota vencida más antigua. Dentro de cada cuota paga penalidades, luego comisiones, luego intereses y luego capital.
2

Registrar el pago

POST /api/v1/loan-accounts/{id}/repayments registra el dinero recibido y lo asigna a lo largo del cronograma. Envía un id de solicitud en X-Request-ID, o en X-Idempotency como respaldo. Una llamada sin ninguno de los dos responde 422. El mismo id con la misma cuenta de préstamo, el mismo monto y la misma fecha efectiva devuelve el pago ya registrado. El mismo id con hechos distintos responde 409. Consulta Idempotencia.
3

Pagar por anticipado

POST /api/v1/loan-accounts/{id}/prepayments liquida el préstamo antes del cronograma, en todo o en parte. Una cuenta de préstamo brasileña necesita primero una cotización de pago anticipado.

​
Cambiar el cronograma

POST /api/v1/loan-accounts/{id}/reschedules reescribe el cronograma restante, por ejemplo para una renegociación. El cambio es un nuevo estado del cronograma, no una edición del anterior.

​
Corregir sin destruir

Las correcciones conservan una línea de tiempo consistente y auditable. Para deshacer una transacción registrada, revértela: POST /api/v1/loan-accounts/{id}/transactions/{transactionId}/reverse Una reversión agrega una transacción compensatoria en lugar de borrar algo, así la cuenta conserva un registro de auditoría completo. Una reversión toma un id de solicitud en los mismos headers que un pago. El mismo id repite la reversión ya registrada solo cuando también coinciden todos los hechos de la reversión. Los hechos de la reversión son la transacción que reviertes, la cuenta de préstamo, la fecha efectiva de la reversión, el motivo, la versión del perfil y el código de jurisdicción. Cualquier diferencia en esos hechos responde 409.
La administración nunca edita el pasado. Los pagos, las reprogramaciones y las reversiones agregan hechos nuevos. El estado actual se vuelve a derivar de ese historial, así la cuenta sigue siendo explicable desde su propio registro.

​
Un pago final devuelto se vuelve una cuenta por cobrar

Reversar el pago que liquidó un préstamo consignado no siempre devuelve la deuda al contrato. Una vez que la exclusión — la orden que manda a la entidad pagadora dejar de descontar de la nómina — salió al carril y no fue rechazada, el mandato de nómina ya no existe, y nada en Lender lo inscribe de nuevo. Un contrato revivido ahí sería deuda sin instrumento detrás: cobrada por atraso, provisionada y ofrecida de vuelta al oficial como algo cuyo descuento él podría cancelar una segunda vez. La reversa se sigue aceptando, porque el banco devolvió el dinero y el ledger tiene que estar de acuerdo con el banco. Lo que cambia es el destino. Lender abre una cuenta por cobrar de pago devuelto contra el prestatario, fuera de la operación de crédito, sin mandato de nómina y cobrada por otros medios. La reversa responde cuál de las dos ocurrió, y con el id de la cuenta por cobrar cuando se abrió una. El contrato conserva su estado liquidado. Nada reabre, ningún cronograma se reprocesa y ninguna asignación se deshace.
Una exclusión todavía en vuelo cuenta como emitida. Una reversa no puede esperar la respuesta del carril, y una revivencia tomada mientras esa respuesta está pendiente no la deshace nada cuando vuelve confirmada. Donde el carril rechazó la exclusión, el mandato nunca murió, y la reversa revive el contrato exactamente como siempre lo revivió.

​
Trabajar la cuenta por cobrar

Una cobranza liquida la deuda entera, así que no carga monto: la cifra se lee de la cuenta por cobrar. Toma un id de pedido en los mismos encabezados que toma un repago. Reenviar la misma cobranza bajo ese mismo id de pedido responde 200 con la cobranza que ya está en pie, y una segunda cobranza, distinta, contra una deuda ya cobrada responde 409 con LENDER-0325. Una cobranza sin id de pedido, con un instante de cobranza que no es RFC 3339, con un nombre de cobrador más largo de lo que el campo admite, o con un id de pedido ya gastado cobrando otra deuda se rechaza con 422 y LENDER-0326. La cuenta por cobrar nombra el contrato del que vino, así que encuentras las de un contrato acotando la lista a esa cuenta de préstamo. No forma parte de la vista de servicing del contrato mismo, porque ya no es deuda del contrato.
Un pago devuelto que cargaba dinero que la institución tenía retenido sin asignar se rechaza con 422 y LENDER-0323. Ese rechazo es terminal por diseño, no un hueco: la reversa no se registra, y el contrato queda exactamente como estaba.
La cuenta por cobrar se lleva a valor facial. Nada la envejece, la provisiona ni la castiga todavía, así que una deuda de pago devuelto no avanza por una escalera de provisiones. Eso es trabajo aparte, todavía por llegar.

​
Lo que ocurre downstream

Cuando el streaming está habilitado y hay un broker configurado, la administración emite repayment.recorded, repayment_reversal.recorded, loan_schedule.prepayment_applied, loan_schedule.rescheduled, returned_payment_receivable.opened y returned_payment_receivable.collected. Un pago anticipado liquidado contra una cotización de pago anticipado brasileña registra una intención de asiento durable. El pago anticipado transmite esa intención al ledger solo cuando configuras el relay del ledger. Consulta la ruta de asiento.

​
Próximos pasos

Contabilidad y ejecuciones de devengo

Reconoce intereses a lo largo del tiempo y lee la referencia de diario que registra cada ejecución.

Paquete regulatorio de Brasil

Lee la etapa de PDD de un préstamo vencido y aplica una transición de etapa.