Re-amortize a loan

Re-amortization redistributes eligible overdue amounts across installments that are still in the future. It is the right tool when the borrower can resume payments now.

On screen. Re-Amortize, in the Hardship column of the loan actions menu.

It does not erase posted history or automatically forgive principal, interest, or fees.

Worked example: Cedar

Cedar has twelve $330 principal-only installments. Four payments posted through May 8, 2027. The June, July, and August installments are unpaid when the arrangement is agreed on August 20.

Before

Outstanding principal is $2,640.00.

future scheduled principal    5 × $330.00 = $1,650.00
overdue principal moved                       $990.00
                                             ─────────
principal across future dates                $2,640.00
$2,640.00 ÷ 5                                  $528.00

After

Reporting can distinguish cured delinquency through payment from delinquency resolved by schedule modification.

Each unmet condition fails before anything posts

The command validates:

• an active loan on a progressive schedule with advanced payment allocation;
• a transaction date on or before current maturity;
• at least one past-due installment with outstanding principal;
• at least one eligible future installment;
• no active charge-off or contract termination.

For an interest-bearing loan, the contract also requires interest recalculation to be enabled.

Interest treatment

The loan’s configured progressive-schedule rules decide how outstanding interest and eligible overdue fees are carried into the re-amortized installments; the command takes no interest-strategy field. If interest should be forgiven, execute the distinct interest waiver with its own amount, approval, and accounting—re-amortization never implies forgiveness.

Same maturity, same principal, new distribution

curl -X POST "$BASE/v1/loans/7204/transactions?command=reAmortize" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_CEDAR_HARDSHIP_4" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: cedar-reamortize-2027-08-20" \
  -d '{
    "transactionDate": "2027-08-20",
    "note": "Borrower resumed employment; keep original maturity.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30514,
  "changes": {
    "transactionDate": "2027-08-20"
  }
}

There is no preview endpoint. Read GET /v1/loans/7204?associations=repaymentSchedule,transactions before deciding and again after executing; the case holds the comparison the arrangement was based on.

The second-person control

When the command is flagged, it parks instead of executing; a different user with the checker permission reviews it in GET /v1/makercheckers and decides with POST /v1/makercheckers/{auditId}?command=approve|reject. Approval executes exactly what the maker submitted, and the execution—parked or direct—writes a governance record readable at GET /v1/loans/7204/governance-records.

Downstream effects

• Autopay targets not yet submitted are regenerated from the new installment amounts.
• A draw already processing is not cancelled silently; resolve the conflict in the case before executing.
• Future statements use the new schedule; completed statements remain unchanged.
• APR/disclosure policy determines whether a post-consummation disclosure or other notice is required.
• Accounting records the transaction and its component movement.

Undo is rejected when replay is unsafe

undoReAmortize is its own governed command, with the same header and governance requirements. It reverses the re-amortization transaction and restores the prior schedule when later activity can be replayed deterministically; a later dependent action that makes reversal unsafe causes the command to be rejected with the blocking condition named.

Compare with re-age.