Charge off a loan · LendEasy Docs

Change a loan's accounting classification on a governed effective date while preserving the recoverable obligation, servicing controls, and future recovery history.

Charge-off recognizes that a receivable meets the lender’s charge-off policy. It is an accounting classification with operational consequences; it does not by itself prove debt forgiveness, satisfaction, or contract termination.

On screen. Charge Off, in the Administrative column of the loan actions menu.

An accounting classification, not forgiveness

CommandPOST /v1/loans/{loanId}/transactions?command=charge-off

Case contextRequired on human calls

ApprovalMaker-checker parks it

Ledger effectClassification posted with its component split

Undocommand=undo-charge-off, while replay stays safe

What the classification changes downstream

Facts readbalances, payments in flight, restrictionsa person
Classification postswith its component splitautomatic
Servicing switchesrecovery paths replace repaymentautomatic
Recovery arriveslinked, separately allocatedwaits

What changes is the classification and which paths stay open, never the history.

Classification first, consequences after

LifecycleCharge-off command

SUBMITTEDcommand issued under case context

PARKEDmaker-checker awaits a second approver

POSTEDclassification and accounting committed

PARKED→REJECTEDchecker declines; nothing posts

POSTED→UNDONEundo-charge-off with replay

Not configured for checking, the command posts directly; the governance record is written either way.

The product decides, not the request

curl -X POST "$BASE/v1/loans/7204/transactions?command=charge-off" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_LOSS_18" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hbr-chargeoff-2028-01-31" \
  -d '{
    "transactionDate": "2028-01-31",
    "note": "Monthly charge-off review; contractual delinquency threshold met.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30465,
  "changes": {
    "transactionDate": "2028-01-31"
  }
}

The product determines eligible delinquency facts, component accounting, future interest and fee treatment, permitted recovery actions, statements, credit reporting integration, and whether autopay cancels—none of it overridable in the request.

Before executing

A pending covering payment or an unresolved bankruptcy or dispute restriction is a reason to hold the command in the case—executing anyway either fails validation or creates review work.

After posting

The loan reads as charged off with its effective date.
Repayment gives way to recovery-payment handling.
Autopay stops or enters review under product policy.
Accrual and charge assessment follow post-charge-off settings.
Collections and communications still pass restriction and contact rules.
Balance reads distinguish ordinary from recoverable components.

The command does not erase the schedule or transaction history.

Recovery and closure

A full recovery can satisfy the remaining obligation, but status transition and closure follow explicit policy; the platform does not automatically undo charge-off to improve portfolio metrics.

Undo is its own governed command

undo-charge-off reverses the accounting classification and replays later activity under ordinary rules. It requires the original charge-off to remain reversible and can be blocked by recoveries, write-offs, closed periods, or external reporting dependencies. It carries new case context, a new governance record, and its own maker-checker configuration.

Whether an obligation remains enforceable after charge-off is a legal and contractual question outside the accounting label. Configure customer communications and reporting from approved policy, not from the word “charged off.”