A lender funds a $200,000 merchant cash advance. One investor contributes 20%, another takes 15%, and the lender keeps the remaining 65%.
Simple enough.
Now imagine the merchant makes daily payments. Some settle successfully. Others return days later. The lender charges management fees, incurs collection expenses, and needs to distribute the correct amounts to each investor.
Suddenly, that simple percentage split isn’t so simple.
This is the problem Cloudsquare Lend’s Syndication module attempts to solve. It keeps track of who participated in a financing agreement, how much they’re entitled to receive, and what happens when the money collected from the merchant doesn’t behave as expected.
I find this side of Cloudsquare considerably more interesting than its sales CRM.
There’s actual financial accountability involved.
The Investor Isn’t Lending Directly to the Merchant
Cloudsquare makes an important distinction between the lead funder and the syndicator.
The lead funder maintains the agreement with the merchant. The syndicator participates through a separate relationship with the funder.
That means the investor isn’t automatically a party to the merchant’s financing contract.
Their financial relationship runs through the lead.
Cloudsquare represents this arrangement using two records.
The Syndicator account stores the participant’s usual terms, including default participation percentages, fees, maximum exposure, and preferred payment method.
The Syndication record connects that investor to one specific financing agreement.
This separation is useful because an investor might take 10% of one deal and 25% of another, with different fees applying to each.
It also prevents the lender from having to recreate every investor’s standard terms from scratch.
But the real question is whether the platform prevents a lender from promising more participation than it can actually sell.
Fortunately, Cloudsquare has controls for that.
You Can’t Sell 120% of a Deal
Administrators establish a default lender participation percentage.
If the lender retains 40%, the remaining 60% becomes available for syndication.
When investors commit to a deal, Cloudsquare updates the committed percentage and reduces the remaining amount available.
The system is designed to prevent commitments from exceeding the allowable participation.
There’s also a maximum percentage that can be assigned to an individual syndicator.
That’s a reasonable safeguard. Nobody wants to discover after funding that several investors were promised overlapping shares of the same agreement.
However, these controls only work properly when the underlying amounts and participation settings have been configured correctly.
Cloudsquare also permits custom overrides of certain syndication calculations.
Those overrides are powerful, but the documentation makes clear that the customer is responsible for validating the substituted figures.
A custom formula that produces incorrect numbers can affect everything calculated afterward.
An Investment Invitation Without a Login
One of the more unusual features is Cloudsquare’s public Offering Memo page.
A lender can email an investor a link to a particular financing opportunity.
The investor opens the page without signing into Salesforce, reviews the deal information and shared documents, and chooses whether to accept or decline.
Depending on the lender’s configuration, the investor may also adjust the participation percentage within permitted limits.
Fees are displayed but aren’t freely editable by the investor.
Once accepted, the memo becomes Committed, and the deal’s participation totals update.
It’s a practical way to collect commitments without requiring every outside investor to become a Salesforce user.
But I wouldn’t confuse it with a full investor dashboard.
A public Offering Memo is an invitation interface, not proof that every syndicator has a permanent self-service account for managing payments and banking information.
The link can expire. It also stops working when the agreement is created.
And the information investors see depends on the fields and permissions configured by the lender.
Cloudsquare’s documentation even warns that incorrectly configured guest permissions can cause deal information or attachments to disappear from the public page.
That’s an unfortunate failure mode: the internal administrator sees everything correctly while the outside investor sees an incomplete offer.
I’d insist on testing the page while signed out before sending it to anyone.
The Money Doesn’t Move Every Time the Merchant Pays
Here’s the part that deserves the most attention.
Cloudsquare creates a payable for each syndicator when an eligible merchant collection settles.
That payable represents the investor’s share of the collected amount, adjusted for applicable management fees and expense allocations.
But the payable doesn’t necessarily become an immediate bank transfer.
It begins in a Due status.
Cloudsquare can hold it for a configured aging period before including it in a remittance.
Then, on the appropriate schedule, eligible payables are grouped into a payment to the investor.
The platform supports daily, weekly, and monthly syndication remittance schedules, including participant-specific overrides.
So one investor might receive a weekly distribution while another receives monthly payments.
That’s a useful arrangement for a lender managing investors with different agreements.
The important thing is that the merchant’s collection schedule and the investor’s payout schedule are separate.
Daily ACH collections do not automatically mean daily investor deposits.
What Happens When Yesterday’s Successful Payment Comes Back?
ACH payments can be returned after initially appearing successful.
That’s unpleasant for everyone, but especially for a lender that has already distributed the investor’s share.
Cloudsquare handles this with negative payables, sometimes called clawbacks.
When a previously settled collection is returned, the system can create a reversing payable tied to the original transaction.
That negative amount is applied against a later remittance.
The investor’s next distribution is reduced accordingly.
I like that the correction remains traceable instead of somebody quietly changing the amount on an earlier payment.
But this mechanism raises a commercial question that software cannot answer by itself.
What happens when an investor has already received their last distribution and there’s no future payment available to offset the return?
The system documents the negative-payable mechanism. That doesn’t eliminate the need for a contractual policy governing recovery of outstanding amounts.
ACH Distribution Is Not the Same as Investor Self-Service
Cloudsquare supports ACH remittances to syndicators.
The lender configures the relevant ACH processor, remittance bank accounts, and payment schedules.
Each investor’s account can contain a default bank account and collection method.
Once a remittance is processed successfully, the corresponding payables move to Paid, and the platform updates the distribution totals.
There are also PDF remittance reports explaining which agreements contributed to a payment and how the amount was calculated.
That’s the sort of reporting I’d expect from a serious syndication platform.
However, I couldn’t establish from the available documentation that syndicators can independently log into a common Cloudsquare portal and change their ACH bank details.
The documented workflow describes bank-account configuration within the lender’s system.
That’s a meaningful limitation for anyone expecting a self-service investor portal.
Cloudsquare clearly supports automated distributions. It doesn’t follow that every recipient has direct control over the destination account.
Those are separate capabilities, and I’d ask to see both demonstrated.
The Detail That Would Make Me Nervous
Cloudsquare has three Syndication Status values: Onboarding, Active, and Inactive.
Only active syndicators are included in remittances.
An investor left in Onboarding may have legitimate participation records while being excluded from scheduled payments.
There’s also a separate Pause Syndication Remittance setting.
These controls are useful when an investor’s account needs attention, but they introduce another place where an incorrect configuration can interrupt payments.
Imagine spending an afternoon investigating missing ACH deposits only to discover that the recipient was never marked Active.
Not exactly the sophisticated financial problem anyone expected to solve.
And it illustrates something important about Cloudsquare.
The platform can automate a large portion of investor accounting, but somebody still needs to understand the settings controlling that automation.
Would I Trust It With Investor Distributions?
I’d want to see one deal from beginning to end.
Invite two syndicators, record their commitments, fund the agreement, settle several merchant collections, allocate an expense, generate payables, and send a scheduled ACH remittance.
Then return one of the original collections and inspect the resulting adjustment.
Finally, show the investor’s report and explain how their bank account can be updated.
That’s the test.
Cloudsquare has documented functionality for the majority of that workflow, including participation records, remittance schedules, ACH batches, reports, and negative adjustments.
What I wouldn’t accept is a vague promise that the entire investor experience is self-service.
Tracking what investors are owed is one problem. Delivering the correct money, on time, to the correct account is another.
Cloudsquare appears much more serious about the second problem than an ordinary CRM.
But in syndication, the last mile of the payment process is where trust is either earned or lost.