How to Automate Centrex

Every advance on the book runs through Centrex

Centrex Software is a CRM and servicing platform for alternative business finance: merchant cash advance funders, the ISOs and brokers who source the deals, the syndicates that participate, and the lenders running SBA, business and mortgage products on the same platform. It is white-labelled, so a funder's brokers and merchants see the funder's brand rather than Centrex's.

What it holds is the deal from both ends. The application a broker submitted this morning, the bank statements behind it, the underwriting notes, the offer, the signed contract, the funded advance, and then the remittance schedule that pulls against a merchant's account until the advance is paid off.

That last part is why it is unlike ordinary CRM. It is not tracking a sale that ends at signature. It is tracking money still owed, every business day, for months.

The stips arrive by email and get typed in by hand

The work around a funding desk is mostly verification, and verification means other people's websites.

A submission lands by email from an ISO with four bank statement PDFs attached, and somebody keys the merchant, the industry, the amount and the contact into the CRM. Then the diligence starts. Somebody checks the business is in good standing on a secretary of state site. Somebody runs a UCC search to find out who has already filed against this merchant's receivables. Somebody searches court records for judgments and liens. Somebody looks the business up on a map listing to confirm it exists and is trading.

After funding it does not stop. An ACH pull comes back as a return code in the processor's portal, and somebody has to see it and work out whether that is a technical failure or a merchant in trouble. Somebody checks whether a merchant has quietly taken a second position from another funder.

Centrex

Diligence done before underwriting opens the file Entity status, registered agent and UCC filings pulled against the merchant's exact registered name, so a file arrives already checked.

Stacking caught while it is still early Existing merchants re-checked for new UCC filings, which is the first visible sign somebody has taken a second position.

Returned pulls matched to their advance ACH return codes read from the processor's portal each morning and set against the advance they belong to, without moving any money.

The submission packet builds itself, the diligence does not

Centrex automates the deal flow it can see, and a funder should have all of it running.

The document builder generates contracts and agreements with the merchant's data already populated, and electronic signature sends them out without anyone retyping a name. The white-labelled client portal gives merchants a login to upload documents, view messages and check a balance, which removes much of the inbound calling. Deal submission packages the merchant's documents and data and sends them to multiple lenders at once, with per-lender criteria and filters behind a recommendation on where a file should go. On the servicing side, native integrations with ACH processors including ACH Works and Actum cover automatic or manual transactions, late payment logic and payoff calculations, while syndication management runs syndicate portals, ACH credits and payouts on the settings you configure. Time and event based triggers fire system actions, with Zapier for the rest. Multi-entity management runs several brands, ISOs, lenders and syndicators at once.

All of it operates on records already in Centrex, or on parties who have a Centrex login. The secretary of state does not have one.

Stacking and liens show up on public registers first

Three public registers decide most of what an underwriter needs to know, and all three are readable from a desk.

Entity status and registered agent pulled from the secretary of state for every new application, so a dissolved company is caught before anyone opens the statements. A UCC search run against the merchant's exact registered name, with existing filings listed by secured party and date, because who is already in front of you decides the whole deal. Court and judgment records searched for the same name, so a live suit is on the file rather than a discovery after funding.

The portfolio side gains as much as origination. Existing merchants re-checked monthly for new UCC filings, which is the earliest visible sign that somebody has stacked another position. Returned ACH codes read out of the processor's portal each morning and set against the advance they belong to, so a merchant who is failing is a conversation this week instead of next month. State licence status re-checked for merchants in the trades that need one, because a lapsed licence and a missed remittance tend to arrive in the same month.

Nothing in that list moves money. It is all reading, and it is all currently a person.

An underwriter should open a file that is already checked

Somebody is going to run that UCC search. The only question is whether an underwriter spends the first hour of the day doing it, or starts on a file where the searching is done and the disagreements are already marked.

WebRun is an AI agent that works a real Chrome browser, signed in as you. It opens the secretary of state, the UCC index, the court records site, the ACH processor's portal or the merchant's own public listings, reads what is there, and writes the result onto the file in Centrex where your underwriter will see it.

It does not approve, decline, fund or move money, and it does not initiate an ACH. Anything reaching a merchant or a broker is drafted and waits for a person.

The workflows below are already built, and each one names what it opens.