Re-age a loan · LendEasy Docs

Replace the remaining repayment schedule with an explicit start date, cadence, and installment count.

Re-aging takes the eligible outstanding obligation and constructs a new remaining schedule. Unlike re-amortization, it can choose new due dates and a new maturity.

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

A replacement remaining schedule

CommandPOST /v1/loans/{loanId}/transactions?command=reAge

Case contextRequired on human calls

ApprovalMaker-checker; one re-age per business date

Ledger effectA schedule-changing transaction; posted payments stay put

Undocommand=undoReAge, when replay is deterministic

Constructing a new remaining schedule

Comparison builtfrom the schedule read, kept in the casea person
Command parkswhen flagged for checkingwaits
Schedule replacednew start date, cadence, countautomatic
Downstream resetpayoff, autopay, statementsautomatic

The new schedule is the record; a consumer that rebuilds it from the request it sent is reading terms nobody approved.

Worked example: Cedar

On August 20, 2027, Cedar has $2,640.00 outstanding after four of twelve $330 payments. Three installments are overdue. The approved arrangement begins September 15 and uses eight monthly installments.

New principal-only schedule

outstanding principal      $2,640.00
new installment count              8
$2,640.00 ÷ 8                $330.00

first new due date       Sep 15, 2027
new maturity             Apr 15, 2028

Result8 × $330.00

a new remaining schedule

Re-age

New due dates fall on the 15th, not the 8th
New maturity Apr 15, 2028, not Jan 8, 2028
Eight new remaining installments, not five
Three past-due installments give way to a schedule beginning Sep 15

the same dates, redistributed

Re-amortize

The original remaining dates stay fixed
The original maturity stays fixed

Both leave the four posted payments attached to their original periods. Only one moves the finish line.

Re-aging moves only eligible outstanding components; it does not rewrite the four payments already made.

Product policy can only tighten these rules

The loan must be active, use a progressive schedule with advanced payment allocation, have a positive outstanding balance, and not be charged off or contract-terminated.

For this loan family the new start date cannot be before disbursement. Product policy can impose stronger rules—such as not before the next processing day, a maximum extension, or a maker-checker requirement. Re-aging can be used before or after original maturity when those rules and loan state allow it.

Required terms

Field	Meaning
`transactionDate`	Business date the re-age posts.
`startDate`	Due date of the first new installment.
`frequencyType`	Cadence unit—days, weeks, or months—under the product’s allowed cadences.
`frequencyNumber`	Number of frequency units between installments.
`numberOfInstallments`	Positive count of new installments.

Interest enters the replacement schedule under the loan’s configured progressive-schedule rules; there is no interest-strategy field. Forgiveness is never a re-age side effect—it is the separate interest waiver with its own approval and accounting.

A lower installment can cost more

curl -X POST "$BASE/v1/loans/7204/transactions?command=reAge" \
  -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-reage-2027-08-20" \
  -d '{
    "transactionDate": "2027-08-20",
    "startDate": "2027-09-15",
    "frequencyType": "months",
    "frequencyNumber": 1,
    "numberOfInstallments": 8,
    "note": "Affordable repayment arrangement per case plan.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30518,
  "changes": {
    "transactionDate": "2027-08-20",
    "startDate": "2027-09-15",
    "numberOfInstallments": 8
  }
}

There is no preview endpoint. A lower installment can still increase total cost or extend the obligation materially—compare total payments, interest, maturity extension, and delinquency treatment, not just the new installment amount.

The second-person control

A flagged command parks; a different user holding the checker permission reviews GET /v1/makercheckers and decides with POST /v1/makercheckers/{auditId}?command=approve|reject. Every execution writes a governance record at GET /v1/loans/7204/governance-records.

After execution

Re-read the schedule for the authoritative new period list, then invalidate stale payoff projections, regenerate future autopay targets, and preserve already-completed statements.

Undo and repeated re-aging

undoReAge is the compensating command. It restores the prior schedule and replays later transactions when deterministic; if later reschedules, disbursements, or other schedule-dependent activity prevents safe replay, the command is rejected with the blocking condition named.

Repeated re-aging replaces the prior remaining schedule; it must not accumulate duplicate stub periods. The schedule read always shows the complete resulting period list, making this rule externally testable.

Compare with re-amortization.