MCA broker software is the set of tools an ISO uses to turn a merchant lead into a complete, consented deal packet, send that packet to several funders, and track what comes back: stips, offers, declines, funding and commission. The core pieces are a CRM, an application and consent flow, a document portal, a pre-submission check and a submission channel for each funder.
This guide covers the broker side of that stack in depth, layer by layer, with the data each layer should hold and where each one usually fails. It does not repeat the funder-side view; for that, see the merchant cash advance software guide, and for how funders receive and triage what you send, see automating MCA submission intake. If you want the short checklist version of a clean submission, start with how brokers and ISOs submit cleaner deals.
What does merchant cash advance broker software actually include?
Broker software covers nine jobs: lead capture, CRM, application and consent, document collection, pre-submission checks, packaging, multi-funder submission, offer and stip tracking, and commission and renewal tracking. A single product rarely does all nine well, so most ISOs run a CRM at the centre and connect the rest to it.
It helps to think of the stack as three stages that each produce something a funder can rely on. The first stage collects and checks: it gathers the application, the statements and the identity documents, and it catches the gaps that would otherwise come back as stips. The second stage packages once: it turns that material into one versioned packet with a cover sheet, so every funder receives the same file. The third stage submits and tracks: it sends the packet through whichever channel each funder uses and records every response against the right submission.
The stages also explain why so many broker tools disappoint. A generic sales CRM has no idea what a statement period is or which funder asked for which stip, and a tool that only blasts email attachments solves sending while creating a security and tracking problem. The useful question when evaluating any software for merchant cash advance brokers is not how many features it lists, but which of the nine jobs it owns end to end and which it hands off to email and spreadsheets.
Lead capture: the first record you will regret getting wrong
Leads arrive from web forms, inbound calls, referral partners, purchased lists and renewal outreach. Whatever the source, capture three things at the start: the source itself (so you can measure which channels produce funded deals rather than applications), the merchant's legal name as the owner states it, and the consent the merchant gave to be contacted. Detect duplicates early: two reps working the same merchant is how one shop ends up submitting a file twice to the same funder.
What should a merchant cash advance CRM track?
Merchant cash advance customer relationship management software should model merchants, deals, submissions, offers, stips, commissions and renewals as separate records, because one merchant has many deals over time and one deal is sent to many funders. A CRM that stores everything on a single contact record cannot answer the questions brokers ask daily.
Those questions are concrete. Which funders have seen this merchant in the last 90 days? What did Funder B ask for, and did we send it? Which version of the packet went to whom? Which offers expire this week? Which funded deals have paid commission, and which are short? Which merchants have paid down enough that a renewal conversation makes sense? Every one of these needs a submission-level record, not a contact-level note. The illustrative data model below is the minimum shape that answers them.
// Illustrative broker CRM data model. One merchant, many deals; one deal, many submissions.
merchant {
legal_name, dba, ein_last4, state_of_formation, owners[] // ownership % per owner
consent_records[] // what was signed, when, and which funders it names
}
deal {
merchant_id, requested_amount, use_of_funds, stage // lead | docs | ready | submitted | offers | funded | lost
documents[] // file, type, period covered, source (bank download or scan), uploaded_at
precheck { run_at, passed[], explain[], request[] }
disclosed_positions[] // funder or debit descriptor, amount, frequency
}
submission {
deal_id, funder_id, packet_version, channel // email | portal | api
sent_at, delivery_evidence // message id, portal receipt or API request id
status // sent | stips | offer | declined | withdrawn | funded
stips[] { item, requested_at, sent_at }
offers[] { amount, factor_rate, term, payment_frequency, received_at, expires_at }
decline_reason
}
commission {
submission_id, basis, expected, received, received_at, clawback_terms_ref
}
renewal_watch {
deal_id, funded_at, est_paydown_pct, next_review_at // a reminder to call, not an eligibility promise
}A few design choices in that model are worth defending. The deal stage is separate from the submission status, because a deal can have an offer from one funder, an open stip from another and a decline from a third at the same time; collapsing that into one pipeline column hides the information that drives the next call. Documents carry the period they cover and their source, so the system can tell that April is missing or that one statement is a scan. Consent records sit on the merchant and name funders, so the submission step can check that the funder you are about to use is covered. The renewal record is a reminder to call, not a promise of eligibility; whether a merchant qualifies for more funding is the funder's decision.
Pipeline stages that match how deals move
- Lead: contact made, no application yet.
- Docs: application started or signed, statements and IDs outstanding.
- Ready: pre-submission check run, open items resolved or explained.
- Submitted: at least one submission sent; status now lives on each submission.
- Offers: at least one offer received and presented to the merchant.
- Funded or lost: with the reason recorded, so loss analysis is possible later.
Measure the time between stages, not only the count in each. A broker with many deals stuck between docs and ready has a collection problem, which better portals and reminders fix. A broker with many deals stuck between submitted and offers usually has a packaging problem: funders are asking for things that should have been in the first packet.
How should brokers handle the application and borrower consent?
Use one electronically signed application that captures the business, every owner and the requested amount, and pair it with a written authorization that names, or clearly describes, the funders the file may be shared with and any credit or verification checks they may run. Store what was signed and when as its own record.
The application is the document funders read first, and the one most often incomplete. Common gaps are missing ownership percentages, a second owner who did not sign, a business start date that disagrees with the state record, and a monthly revenue figure the statements do not support. Each gap becomes a verification or financial question for the funder. Ownership is the one that causes the most back-and-forth; the KYB guide for lenders explains why funders need the ownership split to reconcile the business record.
Consent deserves more care than it usually gets. A merchant who agreed to work with your shop has not necessarily agreed to have their bank statements sent to every funder on your list, and funders increasingly ask brokers to show what the merchant signed. Write the authorization in plain language, keep the version of the form the merchant signed, and record the timestamp and the signing method. When the list of funders you work with changes, the consent language should keep up. Your counsel should review the form; requirements for consent, credit authorizations and disclosures differ by state and by product.
What makes a good document collection portal for an ISO?
A good document portal gives the merchant one secure upload link per deal, shows exactly which statement months and documents are still missing, accepts the bank's own downloaded PDFs, and files every upload against the deal with its type and period. It replaces 'reply to this email with your statements', which is slow, insecure and impossible to track.
The portal is where most of the speed in a broker shop is won or lost. Merchants are busy, and a request that says 'send six months of statements' produces a mixture of phone photos, partial PDFs and screenshots of the online banking page. A request that lists 'November, December, January, February, March, April for the account ending 7123' and ticks each month off as it arrives produces a complete set on the first try far more often. The best portals also ask, at upload, whether the business has any other operating accounts, because a second account the funder discovers later is one of the most common reasons a deal stalls.
Original files beat retyped or reprinted ones
Ask for statements downloaded directly from the bank, not printed and rescanned, not combined into a new PDF by a free online tool, and never retyped. Funders inspect file structure as part of document review, and a reprinted or merged file can look like an edited one even when it is innocent. The guide on how to detect fake bank statements explains what funders check, which is exactly why brokers should forward the merchant's original files unchanged. If you need to split or rename files, do it in a way that keeps each original intact.
Which pre-submission checks should brokers run before sending a deal?
Before a deal leaves your desk, check completeness (every document and statement month), authenticity of form (original bank PDFs), consistency (names, addresses and owners agree across documents), disclosure (existing positions listed) and consent (the target funder is covered). These checks catch preventable stips; they are not underwriting.
The worked example above is typical. The application and IDs are fine, but one statement month is missing, the statements show a trade name the application does not mention, and two recurring debits look like payments on existing advances. None of these is a reason not to submit. All of them are reasons not to submit yet. Requesting April from the merchant takes a day; a funder discovering the gap takes a stip cycle, and a funder discovering undisclosed positions on its own may take a different view of the whole file. The guide on detecting stacking shows how funders find recurring debits in statements, which is why it is better to list them yourself.
Light financial pre-qualification: helpful, with limits
Many brokers also compute rough figures before choosing funders: average monthly deposits, deposit count, average daily balance, negative days and NSF counts. These help you route a file to funders whose published boxes it plausibly fits, and they stop you from sending a file with frequent overdrafts to a funder that has told you it will not look at them. The articles on average daily balance and related metrics and on NSF patterns explain how funders read those numbers.
Keep two limits in view. First, your figures are estimates; each funder calculates its own way, excludes different transfers and applies its own policy. Second, never present a pre-check to a merchant as an approval, a likely offer amount or a guarantee. A pre-check says the file is complete and consistent enough to send. Only a funder can say what it will offer.
How do ISOs package a deal for funders?
Package a deal once: a one-page cover sheet, the signed application, statements in date order per account, owner IDs, a voided check or bank letter, and any explanations, all named consistently and frozen as a numbered version. Every funder then receives the same file, and every later change is a new version.
The cover sheet is the most underused tool in broker operations. It takes five minutes, and it answers the questions an underwriter would otherwise spend the first twenty minutes reconstructing: who the merchant is, which accounts are included and for which months, what is known about existing positions, and what the broker already knows about any discrepancies. It states facts and explains gaps; it is not a sales pitch.
DEAL COVER SHEET (illustrative)
Merchant: Cedar & Stone LLC DBA: Cedar & Stone Builders
Entity / state: LLC, formed 2019 Industry: residential remodelling
Owners: Owner 1 (60%), Owner 2 (40%), both signed the application
Request: amount and use of funds as stated on the application
Statements: Operating acct ...7123, Nov to Apr, 6 of 6, bank-downloaded PDFs
Second acct ...4410, Feb to Apr, 3 of 6 (rest requested on 10/28)
Positions: 2 recurring ACH debits found, listed with descriptor and amount
Explanations: DBA appears on statements; address moved to suite 210 in March
Consent: application and authorization name this funder
Packet version: v1, sent 10/29 via funder portalFile naming and order
Pick one convention and enforce it in the software, not in people's memories. A pattern such as merchant name, document type, account ending and period (for example 'CedarStone_Statement_7123_2026-04.pdf') lets a funder's intake system and a human reviewer both see at a glance what arrived. Put statements in date order, keep each account's statements together, and do not merge every document into one long PDF unless a funder asks for that; a single 140-page file makes it hard for anyone to see which month is missing.
Versioning: the habit that prevents most disputes
When the merchant sends the missing April statement, the packet becomes version 2. Record what changed, and send the new version, or just the new document with a clear reference to the original submission, to the funders who are still active on the deal. Versioning answers the question that otherwise turns into an argument weeks later: what did this funder actually receive, and when?
Which tools help MCA brokers automate submissions to funders: email, portal or API?
Tools for MCA brokers to automate submissions to funders use three channels: email, the funder's own portal, and an API where the funder offers one. Email needs no set-up but is the weakest for security and tracking; portals are secure but mean re-keying; APIs remove re-keying and return status automatically but take integration work per funder.
In practice an MCA submission platform for brokers is a layer that hides those differences. You choose the funders, and the platform sends the frozen packet to each one in that funder's preferred way: a structured email with secure links for some, an automated or assisted portal upload for others, an API call for the few that offer one. What makes such a platform worth paying for is not the sending. It is that every submission, whatever the channel, produces the same record: funder, packet version, time, delivery evidence and, later, the response.
Email done properly
Email will remain part of the stack because many funders accept submissions to a dedicated address. If you use it, send a link to an access-controlled, expiring download rather than attaching statements, put the merchant's legal name and your internal deal number in the subject line in a consistent format so the funder's intake can match replies, send one deal per email, and log the message ID against the submission.
Portals and APIs
Portals give the funder structured data and give you a receipt, at the cost of typing the same application into several systems. Before automating portal entry with scripts, check the funder's terms; some prohibit it, and a brittle script that misfiles a field is worse than a person typing carefully. APIs are the cleanest channel where they exist. When evaluating one, ask whether it accepts documents as well as fields, whether it returns stips and offers in structured form or only a status word, whether it sends webhooks or must be polled, and how it handles a resubmission of the same deal so duplicates are not created.
Failure modes in multi-funder submission
- Duplicate sends: the same deal reaches one funder twice from two reps, or once from you and once from another broker the merchant also used. Check your own history before sending and ask the merchant whether anyone else has submitted the file.
- Consent drift: a funder is added to the send list after the merchant signed an authorization that does not cover it.
- Version confusion: a funder underwrites version 1 after you sent version 2 to others, and the offers are not comparable.
- Silent bounces: a portal upload fails or an email lands in a filtered inbox, and the deal sits for days marked 'submitted'.
- Spray and pray: sending every deal to every funder, which wastes funders' time and shapes how they view your future files.
How should brokers track offers, stips, commissions and renewals?
Track everything at the submission level: each stip with when it was requested and sent, each offer with its terms and expiry, each decline with its reason, and each funded deal with its expected and received commission. Renewal reminders then come from funded-deal records, not from memory.
Stips
A stip, short for stipulation, is an item a funder needs before it will move forward or fund: a missing statement, a month-to-date printout, a lease, a landlord contact, proof of ownership, a payoff letter for an existing position. Record each stip as its own item with the funder, the request date and the date you sent it. Over a quarter, the stip log is the most honest measure of your packaging: items that appear as stips again and again belong in the pre-submission checklist.
Offers
Offers arrive in different shapes: different amounts, factor rates, terms, payment frequencies and fees. Store them in structured fields rather than as forwarded emails, so you can present them to the merchant side by side and see which expire soonest. Where a state requires the funder's disclosure to reach the merchant before or with an offer, as New York does (covered below), the offer record should also hold the disclosure the funder provided and evidence that you transmitted it.
Commissions and clawbacks
Commission terms live in each ISO agreement, so the CRM should store the basis for each funder (for example, points on the funded amount or a share of the funder's fee) and calculate the expected amount when a deal funds. Take an illustrative case: a deal funds at $50,000 with a funder whose agreement pays an illustrative 8 points, so the expected commission is $4,000. When the funder pays $3,600, the record shows a $400 difference to query, rather than letting it disappear into a monthly bank deposit. If your agreements include clawback provisions, for example on early default, store a reference to the clause with the commission so a later deduction can be checked against the terms.
Renewals
Renewal tracking turns funded deals into future conversations. A simple rule, such as a reminder when the merchant's estimated paydown passes a threshold your funders typically consider, keeps the follow-up timely. Two cautions: the paydown estimate is yours, not the funder's, and the reminder is a prompt to call, not a statement to the merchant that they qualify. The funder decides whether a renewal is offered.
What compliance rules apply to MCA brokers and ISOs?
Broker obligations depend on the state where the merchant is located and keep changing. Several states now regulate commercial financing disclosures, and some require brokers to register. Your software should record which state's rules apply to each deal and keep evidence of what was disclosed, when and to whom.
Three examples show the range. They are summaries for orientation, not legal advice; check the current text and talk to counsel before relying on any of them.
- New York. The Department of Financial Services' commercial finance disclosure regulation, 23 NYCRR Part 600, sets duties for financers and brokers. Under section 600.21, a broker who receives the financer's disclosures must transmit them unaltered to the recipient before communicating a specific offer, and then give the financer evidence of transmission, including the time. The provider must also tell the recipient in writing how, and by whom, the broker will be paid. The DFS announcement of the regulation describes standardized disclosures for commercial financing of up to $2,500,000.
- Virginia. Under Va. Code section 6.2-2230, sales-based financing providers and sales-based financing brokers must register with the State Corporation Commission, with an initial and an annual registration fee set out in the statute.
- Utah. The Utah Department of Financial Institutions administers the Commercial Financing Registration and Disclosure Act, which requires persons engaging in commercial financing transactions as a provider in Utah or with a Utah resident to register, with key provisions in effect since January 1, 2023. The department notes that each person must determine whether the act applies to them.
Other states, California among them, have commercial financing disclosure laws of their own, and new state laws and amendments appear regularly. The details that matter to a broker, such as which products are covered, the dollar thresholds, whether brokers must register and who delivers the disclosure, differ from state to state. Rather than hard-coding one state's rules into your process, build the software so that the merchant's state is a required field, the disclosure delivered on each offer is stored with the offer, and transmission evidence (a timestamped email, an e-signature audit trail or a portal acknowledgement) is attached to the submission.
How should brokers keep bank statements and borrower data secure?
Treat every deal file as sensitive financial data: send statements through access-controlled links or portals instead of email attachments, limit who in the shop can open them, keep them only as long as you need them, and plan for what you will do if an account is compromised.
A broker file holds bank account numbers, transaction histories, owner IDs, dates of birth and often Social Security numbers. That is everything a fraudster needs, collected in one place and, too often, sitting in a shared inbox. The Federal Trade Commission's guide Protecting Personal Information: A Guide for Business organises the work into five principles: take stock, scale down, lock it, pitch it and plan ahead. It also warns that regular email is not secure and that account information should not travel by unencrypted email. Translated into broker software, that means:
- Take stock: know every place deal files live, including reps' laptops, personal email and phone photo rolls.
- Scale down: collect what funders need and no more; do not ask for full Social Security numbers where the last four digits will do.
- Lock it: role-based access in the CRM, multi-factor sign-in for every user, download links that expire, and encryption for stored files.
- Pitch it: a retention rule for lost and stale deals, so declined merchants' statements do not sit in storage for years.
- Plan ahead: a written plan for a compromised mailbox or a mis-sent file, with a named person responsible.
Mis-sent email is the incident brokers actually have. A statement packet sent to the wrong funder, or to a former employee's address, cannot be recalled. Expiring links reduce the damage because access can be revoked, and their access logs show whether the file was opened. When choosing broker software, ask the vendor how files are stored and shared, who can access them, and how access is removed when a rep leaves.
What do funders want from ISOs, and what is an MCA CRM with underwriting?
Funders want complete, original, consistent files, honest disclosure of existing positions, a clear statement of what the broker already knows, and quick answers to stips. On the broker side, an 'MCA CRM with underwriting' is usually a CRM with pre-check or analysis features attached; on the funder side it can mean one platform where the pipeline, ISO records and underwriting share a deal record. Either way, the underwriting decision belongs to the funder.
Seen from the funder's side, the best tools for ISO submissions and underwriting at a merchant cash advance funder are the ones that make the first read of the file the only read it needs. Funders sort brokers, informally or formally, by how often their files arrive complete, how often what the underwriter finds matches what the broker said, and how quickly stips come back. The cleaner submissions guide covers how funders form that view.
This is where the phrase MCA CRM with underwriting needs unpacking. On the broker side it usually means one of three things: a CRM that stores funder responses and notes; a CRM that computes rough bank-statement figures to help route deals; or a CRM linked to an analysis tool that reviews the package before submission. All three can help. None of them underwrites in the sense a funder does, because underwriting means applying the funder's own policy and taking the credit risk. A broker-side score that suggests a merchant 'qualifies' sets expectations no one has agreed to meet, and funders notice when a broker's assessments regularly differ from their own.
The most useful thing broker-side analysis can do is find what the funder will find, early. If a second operating account, an address discrepancy, an earlier application or recurring debits that look like existing advances are going to come up in the funder's review, the broker would much rather know before sending, while there is still time to collect the document or write the explanation. That is the difference between a stip cycle and a clean first read.
A short evaluation checklist for broker software
- Does it model merchant, deal, submission, offer, stip and commission as separate records?
- Does the document request list specific statement months and accounts, and tick them off as they arrive?
- Does it keep original files unchanged and record their source?
- Does it run a pre-submission check and separate 'request' items from 'explain' items?
- Does every submission record the packet version, channel and delivery evidence?
- Can it store funder disclosures and transmission evidence against each offer?
- Are statements shared through expiring, access-controlled links, with multi-factor sign-in for staff?
- Does it avoid presenting any internal score to merchants as an approval or offer?
From here, this article is about Cevrynt
How Cevrynt fits for brokers and ISOs
Cevrynt is an MCA platform built for funders and alternative lenders: AI-assisted underwriting plus a built-in MCA CRM that runs the deal pipeline, ISO and broker management (ISO records and submissions per ISO), offers and contracts, and funding and servicing. That CRM sits on the funder's side of the exchanges in this guide, so it receives and tracks ISO submissions rather than sending a broker's deals out to several funders. For brokers and ISOs, the brokers and ISOs solution describes one specific job: reviewing the borrower package, bank activity, existing obligations, business verification and missing or conflicting information, so your team knows what the lender is likely to find before the file is sent.
In practice that means the pre-submission check in this guide, done with evidence attached. Document intelligence classifies the files in a package and maps them into one record; bank statement analysis reads deposits, balances and recurring obligations; business verification surfaces mismatches such as a different address; and fraud signals are presented as review items with their evidence, never as accusations or automatic declines. Open items are separated by who can move them, the broker, the borrower or the lender, and the credit decision always stays with the funder.
For a funder that works with ISOs, the same deal record holds each ISO's submissions and offers next to the underwriting, so status can flow back to brokers from one place. If you run a broker shop or a funder that works with ISOs and want to see how that works on an illustrative file, book a walkthrough or reach the team through the contact page.