A lender schedules 200 ACH debits for Monday. The batch goes out, the dashboard updates, and everything appears to be moving normally.
Then the processor rejects several entries. Another payment gets returned by the merchant’s bank. And one transaction never reaches the processor at all.
Those are three different problems.
Treating them as one generic Failed Payment status is a great way to create unnecessary collection attempts, inaccurate balances, and angry merchants.
Cloudsquare Lend takes a more detailed approach. Its servicing system distinguishes between payments that haven’t been submitted, payments awaiting settlement, processor rejections, and bank returns.
That may sound like accounting trivia. It isn’t. The difference determines what a servicing team should do next.
A Payment Schedule Is Not a Payment
Cloudsquare Lend creates payment schedules against financing agreements. Each schedule defines an amount, frequency, initial payment date, and payment method.
Supported frequencies include daily, weekly, monthly, quarterly, semiannual, and annual.
An agreement can have more than one active schedule.
For merchant cash advances, that flexibility is useful. A lender might need to handle different collection arrangements without manually creating every debit.
There’s an interesting restriction, though: once a schedule becomes active, it can’t simply be edited in place.
For supported MCA workflows, servicing staff use the Update Schedule action to replace it. The old schedule remains linked to the new one, preserving a record of the change.
I prefer that to quietly overwriting the original terms.
If a borrower disputes when a payment was supposed to occur, having the history available is considerably better than discovering that somebody changed a date three weeks ago and nobody knows why.
Cloudsquare also handles banking holidays according to agreement settings. Daily collections may be skipped or carried forward, while weekly and monthly obligations follow different rules.
This is exactly the sort of configuration that should be reviewed before a portfolio goes live.
A small scheduling mistake repeated across hundreds of accounts becomes a very large operational problem.
The ACH Statuses That Actually Matter
Cloudsquare documents nine transaction statuses, but these are the ones I’d watch most closely:
| Status | What it tells the servicing team |
|---|---|
| Scheduled | Payment is ready for processing |
| Pending | Submitted to the ACH processor; final result not confirmed |
| Settled | Processor reports successful settlement |
| Rejected | Processor declined the entry |
| Failed | Payment did not successfully reach the processor |
| Returned | Payment was sent but subsequently returned by the bank |
| Not Verified | Bank account has not met the configured verification requirement |
The dangerous mistake is treating Pending as Settled.
A payment can leave the lender’s system without becoming successfully collected money.
Cloudsquare uses processor status checks to update the corresponding ACH items and transactions. That means servicing staff can distinguish an outstanding payment from one that has actually cleared.
But it also means the accuracy of the dashboard depends on processor responses and correctly configured status-check jobs.
Automation doesn’t eliminate dependencies. It just makes those dependencies easier to overlook when everything is working.
A Failed Batch Shouldn’t Require Rebuilding the Agreement
Cloudsquare Lend includes a Reschedule action for ACH batches.
If an entire batch fails to process, staff can select the affected payments and move them to the next available banking-day batch.
The same applies when only certain payments in a batch fail.
There are options for same-day or next-day ACH, subject to processing cutoffs and costs.
That’s a sensible recovery mechanism.
But Cloudsquare’s documentation makes an important distinction: rescheduling a payment that never reached the processor is not the same as attempting to collect a bank-returned debit again.
A bank return may involve insufficient funds, a closed account, stopped payment authorization, or another problem requiring review.
Simply pushing that debit back through the system can create more trouble.
And same-day ACH isn’t a magical fix for every processing delay. It has cutoff restrictions and typically costs more than next-day processing.
I’d want the servicing team to understand those differences before giving everyone permission to retry payments.
What Happens When the Bank Says No?
This is where Cloudsquare’s collections logic becomes more interesting.
The platform uses ACH return codes to decide how repeated payment failures affect an agreement.
Consider three common examples:
- R01 — Insufficient Funds: The account exists, but the available balance isn’t enough.
- R02 — Account Closed: Continuing to debit the same account makes little sense.
- R08 — Payment Stopped: The account holder has requested a stop payment.
Cloudsquare lets administrators configure thresholds for delinquency, default, and automatic payment pauses.
A lender might tolerate multiple insufficient-funds returns while stopping collection immediately after a closed-account return.
Those thresholds are configurable rather than universal rules imposed on every lender.
When the configured pause threshold is reached, Cloudsquare can flag the bank account and stop generating further collections against it.
And this is the detail I particularly like: the system distinguishes between pausing an individual agreement and flagging the underlying bank account.
Pausing an agreement stops new payment generation, but already-created payments may still exist.
Flagging the bank account is stronger. It can remove scheduled payments and pause other active agreements using that account.
That distinction can prevent the same invalid banking information from generating failures across multiple agreements.
The Final Payment Has a Catch
Here’s a surprisingly common accounting trap.
A financing agreement reaches its last scheduled payment. The final ACH debit is sent, and the remaining amount awaiting collection drops to zero.
Does that mean the agreement is paid off?
Not necessarily.
Cloudsquare distinguishes between the pending balance and the current balance.
When the final payment is in process, the pending balance may be zero while the current balance still reflects money that hasn’t settled.
Only after the final payment successfully clears does the system automatically move the agreement to Paid in Full and deactivate its schedules.
If the last debit returns, the agreement remains active and collection can resume according to the schedule and applicable controls.
That’s how it should work.
A payment instruction isn’t money. An attempted debit isn’t money. A processor acknowledgment isn’t necessarily final settlement.
A servicing system that gets those distinctions wrong can make a profitable portfolio look healthier than it really is.
The Feature I’d Test Before Signing a Contract
I wouldn’t start a Cloudsquare demonstration with a successful payment.
Successful payments are boring. Almost every modern platform can display them.
I’d ask the vendor to show a failed Friday batch, a rejected entry, an insufficient-funds return, a closed bank account, and a final payment that gets returned.
Then I’d look at the agreement balance, transaction history, payment schedule, return code, and collection status after each event.
Does the system prevent inappropriate retries? Can staff identify why the payment failed? Does pausing one bank account affect the correct agreements? Does the outstanding balance remain accurate?
Cloudsquare Lend documents mechanisms for handling all of these situations.
That doesn’t prove every lender’s installation is configured correctly. Processor connections, thresholds, permissions, and scheduled jobs still need proper setup.
But it provides a far more serious starting point than a CRM that merely displays Paid or Unpaid next to each financing agreement.
For lenders processing large numbers of ACH transactions, the failures are where the software earns its keep.
The successful payments were never the difficult part.