A failed ACH payment isn’t automatically a collections problem. Two failed payments might be a warning. Five consecutive returns? Now somebody probably needs to investigate.
The difficult part is deciding when an ordinary servicing issue becomes a serious delinquency.
Cloudsquare Lend has a dedicated Collections module for that exact transition. Instead of asking employees to notice patterns in payment reports and manually open cases, the system can create collection records when an agreement reaches a configured threshold of consecutive ACH returns.
Sounds useful. But the details are where things get interesting.
Because Cloudsquare doesn’t merely track overdue payments. It can follow a troubled account from its first collections case through a negotiated payment arrangement, a broken promise, and eventual escalation to a UCC workflow.
That’s quite a lot of responsibility for software.
The Case That Opens Itself
The starting point is a setting called Collections Case After.
Administrators configure it under CS Lend Settings → ACH → Return Codes & Fees.
Each ACH return code can have its own threshold.
That flexibility is important. A payment returned for insufficient funds shouldn’t necessarily trigger the same response as one involving a closed account.
Once the number of consecutive returns reaches the configured threshold, Cloudsquare creates a Collections Case linked to the financing agreement and payer account.
The returned transactions are associated with the case, and Salesforce assignment rules determine which employee or queue receives it.
There’s a safeguard against duplicate active cases: the system checks whether an open Collections Case already exists for the agreement.
I like that. A servicing department doesn’t need three collectors independently investigating the same financing agreement because several payments failed in succession.
But the configuration has to be sensible.
A threshold of one could create a flood of cases for temporary banking problems. A threshold that’s too generous might let genuinely troubled accounts go unattended.
And no software setting can determine why a merchant stopped paying without further investigation.
A business suffering a temporary revenue decline isn’t necessarily behaving dishonestly. A stopped payment or changed banking relationship can have a different explanation entirely.
The automatic case should begin an investigation, not replace one.
The Promise to Pay Has Actual Consequences
This is where Cloudsquare gets considerably more useful than a spreadsheet.
When a collector reaches an arrangement with a merchant, the system offers two approaches.
Individual Payments allow the employee to create specific payments with amounts, dates, methods, and associated bank accounts.
Payment Schedules allow the employee to establish a new recurring payment plan, including frequency and start and end dates.
The employee can also decide whether existing active schedules should be deactivated.
That’s a detail worth examining carefully.
Cloudsquare doesn’t necessarily replace every existing schedule when a new arrangement is created. Only the schedules selected for deactivation are affected.
If someone overlooks an existing schedule, the account could end up with overlapping payment obligations.
That’s not the kind of mistake you want to discover after the merchant complains about an unexpected debit.
When the arrangement is applied, the Collections Case moves to Promise to Pay.
The newly created payments and schedules are linked to the originating case, preserving a record of what was agreed.
And then the system starts watching.
Broken Promise Isn’t Just Another Failed Transaction
Suppose the merchant agrees to make a catch-up payment.
The ACH debit is submitted, reaches the banking system, and gets returned.
Cloudsquare automatically changes the related case to Broken Promise, provided the case is still open and hasn’t already been marked that way.
That’s useful because the collections team doesn’t need to compare every new bank return against every outstanding repayment arrangement manually.
But here’s the distinction that deserves credit.
Cloudsquare does not treat every unsuccessful payment attempt as a broken promise.
A transaction marked Failed or Rejected before reaching the bank does not trigger that status. The system specifically looks for Returned payments.
That’s a reasonable separation.
A technical submission failure and a bank-returned payment are not equivalent events.
And calling both of them broken promises would make the collections history less trustworthy.
The UCC Button Is Where I’d Get Nervous
Cloudsquare includes an Escalate to UCC action.
When an authorized user selects it, the original Collections Case changes to UCC status, and a separate UCC Case is created.
The new record inherits the relevant agreement and account references. Both cases remain linked, so staff can trace the escalation back to the original collections activity.
That’s good recordkeeping.
But a UCC workflow deserves more caution than an ordinary payment reminder.
UCC-related remedies involve legal rights, contractual terms, applicable law, and potentially significant consequences for the business involved.
Clicking Escalate to UCC in Cloudsquare is a case-management action. It does not, by itself, establish that a lien has been filed or that enforcement is legally justified.
Cloudsquare also exposes the escalation action for custom Salesforce automation using Flow or Apex.
In other words, a lender can potentially create rules that move qualifying cases into the UCC workflow without requiring someone to press the button manually.
Technically impressive.
Operationally? I’d want strict review criteria before allowing that.
A system should be very good at identifying accounts that need attention. It should be much more careful about initiating workflows that may lead to legal enforcement.
Here’s the Catch: You Have to Build Part of the Experience Yourself
Cloudsquare’s documentation is unusually revealing about the setup required.
The Collections module doesn’t simply become fully operational because somebody installs the software.
Administrators need to configure Salesforce Case statuses, support processes, record layouts, assignment rules, permissions, and the Case Lightning page.
They also need to activate the Case Status Tracking Flow.
That flow is initially inactive.
Until someone enables it, the timestamp fields intended to show when a case entered each stage won’t populate as expected.
And permissions can create another surprise.
The existing CS Lend Collections permission set isn’t enough on its own to enable every collections action. Administrators must also configure the relevant case access and custom permissions.
Those permissions separately control accepting a case, applying payment arrangements, and escalating a case.
This is exactly where a sophisticated Salesforce application can become frustrating.
The software offers considerable flexibility, but the customer is responsible for getting a long list of configuration decisions right.
I’d be especially interested in who has authority to create new payment arrangements and who can escalate cases.
Those should not automatically be the same people.
A Collection Status Doesn’t Tell the Whole Story
Cloudsquare records timestamps as cases move through their statuses.
That allows managers to examine how long a case remained unresolved, when an arrangement was reached, and whether the account returned to an earlier stage.
The timestamp for a previously visited status is updated if the case re-enters that status.
This can help identify stalled work, but it isn’t a complete historical timeline by itself. The associated case history and transaction records remain important.
There’s also a separate retention feature that tracks merchants and agreements based on whether payments actually clear.
I find that separation sensible.
Not every merchant with a temporary payment problem should be treated as permanently lost business. And not every customer who promises to catch up should be considered successfully recovered.
Actual payment behavior should carry more weight than reassuring notes entered by a collector.
What I’d Want to See in a Demo
Show me an agreement that has returned several ACH payments.
Let the automatic case open. Assign it to a collector. Create a revised payment plan. Return one of the promised payments. Show me the Broken Promise status.
Then demonstrate what happens when the case is escalated, who is authorized to perform that action, and what records remain available afterward.
That’s a far more revealing test than a dashboard displaying total overdue balances.
Cloudsquare Collections has the machinery to handle a complicated servicing process. The automatic case creation, linked payment arrangements, return monitoring, and escalation history are all meaningful features.
But the system’s quality will depend heavily on how the lender configures it and how responsibly its employees use it.
Automating collections should make decisions more consistent and traceable. It shouldn’t make aggressive decisions easier to execute without thinking.
There’s a difference, and in commercial lending, it’s a very expensive one to ignore.