Recurring-payment notices
For variable recurring transfers, LendEasy can generate the program's advance notice with a ledger-backed amount and the configured delivery timing.
Solutions · Payment operations
Handle payments from authorization through returns
Preserve the borrower’s authorization date while ACH settles, so servicing can treat an on-time payment according to your approved value-dating policy. Returns trigger automated paths instead of exception queues. Each transaction stays linked to its payment request, making reconciliation and review straightforward.
The payment lifecycle
Ledger
Payment authorized on the due date
System
In flight — authorization date preserved
System
A return starts the configured response
Ledger
Posted using the configured value date
Every transition stays linked to the original payment — full lifecycle below
The payment lifecycle
Authorize → in flight → settled → posted
Follow one payment from authorization to posting, including return and correction paths. Authorization and settlement remain separate, and each change is recorded.
- Ledger
Payment authorized on the due date
A payment intent is created and value-dated to the moment of authorization. From here, everything that happens is tied back to this intent.
Evidence: Payment intent with amount, instrument, and authorization timestamp.
- Ledger
In flight — authorization date preserved
While ACH settles, the platform can suppress late fees and stand collections down according to lender policy. Authorization and settlement remain separate facts, and any open promise to pay sits in pending evaluation.
Evidence: Value-dating annotation plus the late-fee and collections suppression records.
- Ledger
Settled — funds confirmed by the network
Settlement confirmation arrives and is matched to the original intent automatically.
Evidence: Settlement confirmation linked to the intent.
- Ledger
Posted using the configured value date
When lender policy uses the authorization date as the value date, the ledger posting, statements, account status, and promise evaluation use that configured date while retaining the settlement date separately.
Evidence: Posted transaction with value date and the full intent lineage.
- System
If the network returns the payment
Each return code starts its configured response, with the payment and network details attached.
R01 — insufficient funds
- Retry scheduled under lender policy and network limits
- Borrower status and fees handled consistently through the retry window
- Outcome recorded against the original intent
Hard return — e.g. account closed
- Payment instrument disabled so it is not retried
- Case opened with the return details for follow-up
- Borrower notified to provide a new payment method
NOC — notification of change
- Payment details updated from the network correction
- Future payments use the corrected details
- The change and source are recorded
Evidence: Return code, the automated response taken, and the resulting case or correction — all chained to the intent.
Value dating
Apply your value-dating policy while ACH settles
ACH settlement takes time. The platform tracks authorization and settlement separately, so lender policy can value-date a payment to the day the borrower authorized it while still monitoring the network outcome.
Configured fee treatment in flight
While a payment settles, late fees can be suppressed according to the lender's value-dating and return policy.
Collections stands down
An in-flight payment can suppress collections activity on the debt until settlement or return resolves the payment state.
Promises resolve after settlement
A promise covered by an in-flight payment remains pending, then resolves from the final ledger outcome.
Autopay
Keep notices, retries, and pauses in one flow
Generate recurring-payment notices, apply retry rules, and pause affected autopay when a configured protection is recorded.
Automated retry rules
Failed debits follow your configured retry policy within network limits, with each attempt recorded against the original payment.
Autopay pauses for protected accounts
A recorded bankruptcy restriction or other configured protection can pause affected autopay alongside outreach restrictions.
Return-code automation
Automate the response to each return code
Configure the retry, account update, borrower notice, or review case for each ACH return. Every response stays linked to the original payment.
| Code | Meaning | Automated response |
|---|---|---|
| R01 | Insufficient funds | Smart retry scheduled automatically, within network retry limits. Status stays consistent through the retry window; the final outcome is recorded against the intent. |
| R02 | Account closed | Hard return: instrument invalidated immediately, a case opens with the return details, and the borrower is notified to provide a new payment method. |
| R03 | No account / unable to locate | Hard return: same automated path — instrument invalidated, case opened, borrower notified. Nothing retries into an account that does not exist. |
| R10 | Unauthorized debit | Instrument invalidated and autopay halted on it; a case opens for review with the dispute facts attached, and downstream payment activity is restricted while it is worked. |
Representative codes shown. The same pattern — match the original payment, take the configured response, and record the outcome — applies across the return-code catalog.
Reconciliation
Turn reconciliation gaps into assigned work
Compare payment requests with processor events and ledger postings continuously. Any gap opens a case with the relevant facts, owner, and due date.
Every posting traces to a payment
Each ledger transaction links to the payment request, authorization, and settlement events that produced it.
Mismatches create assigned work
When the processor and ledger disagree, LendEasy opens a case with the relevant facts, owner, and due date.
Complete payment history
Payment requests, postings, returns, retries, and corrections remain linked in a tamper-evident audit trail.
FAQ
Payment operations, answered
Authorization and settlement remain separate dates linked to the same payment. If your policy uses the authorization date as the value date, the posting and borrower-facing status can use that date while the settlement record still reconciles to the network.
Trace a payment from authorization to posting
Bring a representative return scenario. We will walk through authorization, settlement, return and correction paths, and the resulting audit record.