> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lms.bsa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Adjust disbursement date

> Shift an active loan's disbursal date when the partner-side wallet credit landed later than the LMS recorded.

Shifts the effective disbursal date on an `Active` loan. Use this when
the partner's wallet credit was delayed (e.g. pending → confirmed two
days later) and the LMS-recorded disbursement date no longer matches
the day the customer actually received the money.

Interest re-accrues from the new date, and the
[`repaymentSchedule`](/loans/overview) is recalculated so the next
due-date math matches reality.

<Warning>
  A loan with **recorded repayments** is rejected with `409 aborted`.
  The adjustment reverses and re-books the disbursement, which would
  cascade-reverse any repayments — so erasing them must be an explicit
  choice. [Reverse](/repayments/reverse) the repayment(s) first, then
  adjust.
</Warning>

## Date constraints

* The new date **must not be in the future** — pass today or any past day.
* The new date **must not be before the loan's approval date.** Because
  `POST /v1/loans` approves on the same day it disburses, the new date
  must be on or after the original disbursement date.

For the realistic delayed-wallet flow both constraints are satisfied
naturally: the partner calls this endpoint on the day the wallet
credit actually confirms, which is between the original
approval/disbursement day and today.

Two equivalent forms — prefer the externalId form for partner integrations.

## Path parameters

<ParamField path="loan_external_id" type="string" required>
  The loan's externalId. On the `/v1/loans/{loan_id}/adjust-disbursement-date`
  form, this is the numeric LMS id instead.
</ParamField>

## Request body

<ParamField body="actualDisbursementDate" type="string" required>
  ISO-8601 `YYYY-MM-DD`. The corrected disbursal date.
</ParamField>

<ParamField body="note" type="string">
  Optional. Reason for the adjustment, captured in the LMS audit log.
</ParamField>

## Examples

```bash theme={null}
# By loan externalId (recommended)
curl -sf -X POST "$BASE/v1/loans/external/loan-ext-12345/adjust-disbursement-date" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "actualDisbursementDate": "2026-05-30",
    "note": "Wallet credit confirmed 2 days after original disbursement"
  }'

# Same effect, by LMS id
curl -sf -X POST "$BASE/v1/loans/501/adjust-disbursement-date" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"actualDisbursementDate": "2026-05-30"}'
```

## Response

`200 OK` returns the [loan object](/loans/overview) with the new
disbursal date, recomputed schedule, and adjusted next-due fields.

## How it works

The wrapper performs `undo-disbursal` then re-`disburse` against the
LMS with the corrected date. These are two separate LMS commands, so
the wrapper makes them **atomic from the partner's point of view**: it
records the current disbursement date first, and if re-disbursing at the
new date fails it automatically rolls the loan back to the original
date. Either the adjustment succeeds (loan `Active`, new schedule), or
it fails cleanly with the loan left in its original `Active` state — the
loan is never stranded in `Approved`.

The only exception is the rare case where the re-disbursal *and* the
automatic rollback both fail; the response is then a `500` whose message
states the loan is in `Approved` and names the original date to
re-disburse manually.

## Errors

| Code                  | When                                                                                                                                           |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `not_found`           | No loan with that id or externalId                                                                                                             |
| `failed_precondition` | The loan has no disbursement to adjust (not yet disbursed)                                                                                     |
| `aborted`             | The loan has recorded repayments — reverse them before adjusting the date                                                                      |
| `invalid_argument`    | `actualDisbursementDate` missing, not ISO `YYYY-MM-DD`, in the future, or before the loan's approval date                                      |
| `permission_denied`   | Date in the future, or date before the loan's approval date                                                                                    |
| `internal`            | Re-disbursal failed and automatic rollback also failed — loan is in `Approved` and needs manual re-disbursal (message names the original date) |