By Stefan Idriceanu, Co-founder
The MCA Control Plane: Why the Next Layer Isn't Another CRM or Parser
Parsers analyze the application. The CRM stores the opportunity. Neither one operates the deal, and that missing layer is where MCA funders lose time, money and control. We call it the MCA control plane: the system responsible for moving each deal from submission to funding, servicing and renewal.
Last updated: 21 October 2026
The stack most funders actually run
Walk through a typical MCA funder's operation and you will find a familiar set of parts.
- A CRM that holds merchants, ISOs and opportunities.
- A bank statement parser or analysis provider that scrubs statements and returns revenue, NSFs and suspected positions.
- An email inbox where ISO submissions and stips arrive.
- An e-signature tool for contracts.
- An ACH processor for daily and weekly debits.
- A servicing system or spreadsheet for payments, returns and balances.
- Spreadsheets for syndication participation and ISO commissions.
Each tool can be good at its job. The problem is the space between them. Somebody copies revenue from the parser into the CRM. Somebody retypes offer terms into the contract. Somebody updates the servicing sheet when an ACH bounces. Somebody works out, from memory, whether this merchant is eligible for renewal.
That is what "patching your operation together" looks like. The work between systems is invisible in any one system, so nobody measures it and nobody owns it.
Three layers, three jobs
The clearest way to see the gap is to separate what each layer is responsible for.
| Layer | Its job | What it is not responsible for |
|---|---|---|
| Parser / analysis provider | Turn documents into data and findings | Deciding what to do about the findings |
| CRM | Store relationships, opportunities and history | Enforcing credit policy or moving money |
| Control plane | Operate the deal: evidence, policy, exceptions, decisions, contract, funding, servicing, renewal | Being the only system you use |
Parsers analyze the application. The CRM stores the opportunity. The control plane operates the deal.
These are different layers, not rivals. A funder can have an excellent parser and a well-configured CRM and still have no system that is accountable for getting a deal completed.
What "operating the deal" means
A control plane is defined by responsibility, not by features. It is accountable for the deal reaching an outcome. In practice that covers:
- Intake. Submissions and stips arrive and land on the right deal, not in someone's inbox.
- Evidence. Findings arrive with their supporting transactions and source pages.
- Policy. The funder's credit box is applied to the file, consistently.
- Exceptions. Anything outside policy becomes a queued decision with an owner.
- Decision record. Every approval, adjustment and decline is stored with what the decision-maker saw.
- Offer and contract. Terms flow from the decision to the offer to the contract without retyping.
- Funding and servicing. The funded structure drives the ACH schedule, returns and balances.
- Renewal and partners. Renewal eligibility, syndication distributions and ISO commissions come from the same record.
The first two items are where parsers help. The CRM records all eight after the fact. Only a control plane is on the hook for making them happen.
We wrote about the first half of this in detection is not resolution, and about the evidence layer in stacking and existing positions.
Why one record from submission to renewal matters
When underwriting and servicing live in different systems, the decision and its outcome never meet. The underwriter who approved a file with an exception rarely learns how that merchant paid.
Keeping the whole life of the deal in one record changes that. The evidence behind the decision, the exception that was approved, the funded structure, the returned payments and the renewal all sit together. A manager reviewing a renewal can see what was known at approval and what happened after.
That is the foundation for a real outcome loop. It does not require sophisticated analytics to start being useful; it requires the data to exist in one place in the first place.
How to adopt a control plane without a migration
The usual objection is reasonable: nobody wants to rip out a CRM and a parser that the team already knows. A control plane should not demand that. The adoption path has three stages.
1. Coexist. Keep the CRM and the analysis provider. Run the control plane alongside them on a subset of deals. Measure the manual work that remains between submission and funding.
2. Control. Let the control plane own the workflow between systems: the gates, the decisions, the handoff from offer to contract to ACH. Existing tools keep doing their jobs; the control plane is accountable for the deal moving.
3. Selectively replace. Once the workflow runs through one place, each surrounding tool becomes a component. Keep the ones that earn their cost. Replace the ones where the control plane already does the job.
The architectural principle behind this is that the control plane should be neutral about the tools around it. The deal record, the policy and the decision history belong to the funder, not to whichever parser or CRM happens to be in place this year.
What to measure
If you are evaluating any operational software, measure the gaps, not the features. For a sample of deals, track:
- Manual touches per deal
- Submission-to-decision time
- Decision-to-funding time
- Exception-resolution time
- Repeated data entry (the same value typed into more than one system)
- Missing-document delays
- Underwriter capacity (files per underwriter per day)
- Funded conversion
Record these before you change anything. They are the only honest baseline.
How DueDeal fits
DueDeal is built as the MCA control plane. Here is what it does today.
- Intake: ISO and broker emails and attachments are matched to the right deal automatically, and unmatched emails are parked for review.
- Evidence: bank statements are reconciled to the cent; true revenue is shown with netted amounts by category; each MCA position is linked to its supporting transactions.
- Policy and exceptions: the funder's max-positions policy is enforced, and exceptions become gates that are claimed, decided and written to an audit entry with a frozen snapshot of the evidence.
- Offer to funding: an offer matrix, lender matching and submission, contract packages, e-signature through DocuSign, OpenSign or Adobe Sign, and ACH collections through Actum.
- After funding: payment schedules, returned payments, balance transfers, amendments, renewal eligibility by percentage of term elapsed, syndication and ISO commissions.
- Coexistence: DueDeal integrates with Salesforce, HubSpot, Zoho, Pipedrive and Downhome, so a funder can keep its CRM while trying DueDeal.
DueDeal extracts and analyzes documents itself. It does not currently integrate with third-party analysis providers, so a funder running a separate provider during a pilot would use both side by side rather than feeding one into the other.
Start with 20 deals
Your MCA stack, finally working as one. Keep your CRM and your analysis provider. Give DueDeal 20 deals in a parallel pilot, and we will measure the manual work left between submission, underwriting, funding and servicing. Or book a demo.
Frequently asked questions
What is an MCA control plane? An MCA control plane is the system responsible for operating each merchant cash advance deal from submission to renewal. It applies policy, routes exceptions, records decisions and carries the deal through contract, funding and servicing.
Is a control plane the same as an MCA CRM? No. A CRM stores relationships and opportunities and records what happened. A control plane is accountable for moving the deal forward, including policy, exceptions, funding and servicing.
Do I need to replace my CRM to use a control plane? No. The recommended path is to coexist first, running the control plane alongside the existing CRM, then let it take control of the workflow, and only later replace tools where it already does the job.
What is the difference between a bank statement parser and a control plane? A parser turns documents into data and findings. A control plane takes those findings and gets the deal to an outcome: evidence reviewed, policy applied, exceptions decided and the deal funded and serviced.
How do you measure whether MCA operations software is working? Measure manual touches per deal, submission-to-decision time, decision-to-funding time, exception-resolution time, repeated data entry, missing-document delays, underwriter capacity and funded conversion on a sample of deals.
Does DueDeal work with Salesforce? DueDeal integrates with Salesforce, HubSpot, Zoho, Pipedrive and Downhome. Funders can run DueDeal alongside their CRM during a parallel pilot.