By Othman Kabbaj, Co-founder

Detection Is Not Resolution: Where MCA Deals Stall After the Parse

Detecting a problem on an MCA file takes seconds; resolving it is where deals actually stall. A flag like "two existing positions detected" is only useful once someone sees the evidence, applies the funder's policy, records a decision and moves the deal to contract.

Last updated: 24 September 2026

The parse is fast. The deal is not.

Bank statement scrubbing has improved a great deal. A funder can now receive an ISO app and three to six months of statements and get back revenue, NSFs and ODs, average daily balance and a list of suspected positions almost immediately.

Time to decision has not fallen at the same rate. The reason is simple: a parser produces findings, and findings are not decisions.

Every finding creates a small piece of work. Somebody has to open the file, check whether the finding is right, decide what the funder's policy says about it, and either clear it, adjust the offer or decline. On many desks that work happens in email threads, Slack messages, sticky notes and spreadsheets.

That gap between "flagged" and "done" is where files sit overnight, where the ISO calls three times, and where a merchant signs with a faster funder.

Five places deals stall after the parse

1. The flag without the evidence. "Possible MCA position, weekly debit" tells an underwriter what to worry about but not why. The underwriter re-opens the PDF, scrolls to find the debits, and rebuilds the story by hand.

2. The missing month. The ISO sent January, February and April. Nobody notices March is missing until the file reaches a senior underwriter, and then the stip request goes out a day late.

3. The policy question nobody owns. The merchant has three positions and the funder's box says two. Is that a decline, a smaller offer, or a consolidation? The underwriter pings a manager. The manager is on a funding call.

4. The decision that lives in a chat message. The manager says "approve, cap at $40K" in a message. Two weeks later nobody can find it, and the contract went out at $50K.

5. The re-keying at every handoff. Offer terms get retyped into the contract. Contract terms get retyped into the ACH schedule. Each retype is a chance for a factor rate or holdback to drift.

None of these stalls is about reading documents. Every one of them is about operating the deal.

What resolution actually requires

Resolution means a finding ends in a recorded outcome that the next step can trust. In practice that needs four things.

• Evidence attached to the finding. The flag should link straight to the transactions and source pages that triggered it.
• Policy applied, not remembered. The funder's limits (max positions, minimum true revenue, NSF tolerance) should be checked against the file, not recalled from memory.
• An owner and a queue. Exceptions need a place to sit, a person who claims them, and a clear decision: approve, adjust or decline.
• A record. The decision, who made it, and what the evidence looked like at that moment should be stored with the deal.

Once those four exist, the rest of the deal can move without anyone asking "wait, who approved this?"

A worked example

Consider an illustrative file. The numbers below are hypothetical, for example only.

A restaurant submits four months of statements. The parser reports average monthly deposits of $92,000 and "2 positions detected."

Here is how detection-only and resolution-oriented workflows differ:

The second column is not smarter analysis. It is the same analysis, finished.

A checklist for your own desk

Use this to audit where your files wait. Pull ten recent deals and answer each question honestly.

1. For every flag on the file, could an underwriter reach the underlying transactions in one click?
2. Was the true revenue figure shown with the amounts that were removed, by category?
3. Were missing statement months caught at intake or discovered later?
4. Was each policy exception decided by someone with authority, and is that decision written down with the deal?
5. Could you reconstruct, today, what the underwriter saw when they approved?
6. How many times were offer terms typed by hand between approval and the first ACH debit?

If the answers are mostly "no", adding a better parser will not shorten time to funding. The work you need to remove is downstream of the parse.

How DueDeal handles it

DueDeal is built around resolution rather than detection. Parsers analyze the application; DueDeal operates the deal.

• Evidence stays attached. Every transaction keeps its source page, and each detected MCA position is linked to its supporting debits and credits. Bank statements are reconciled to the cent before numbers reach an underwriter.
• True revenue is shown with its workings. Transfers, MCA fundings, owner infusions, reversal credits and returned deposits are netted out and displayed by category, per month.
• Policy is enforced. The funder's max-positions limit is enforced on the file, and stacking risk is given a level.
• Exceptions become gates. Gates sit in a queue where an underwriter claims and decides them. Decisions can be restricted to admins, and every decision writes an audit entry with a frozen snapshot of the evidence and who resolved it.
• Missing months are flagged. Gaps in statement months are detected automatically and raised as a "statements needed" gate. Sending the request to the ISO is still a manual step.
• The deal keeps moving in one record. Offers, contract packages, e-signature, ACH collections through Actum, servicing and renewals all run from the same deal, so terms are not retyped between steps.

DueDeal can run alongside the CRM and analysis tools a funder already uses. That layer between systems is what we call the MCA control plane.

Try it on your own files

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 to walk through a live file.

Frequently asked questions

Why do MCA deals stall after bank statement parsing? MCA deals usually stall after parsing because findings still need someone to verify the evidence, apply the funder's policy and record a decision. Those steps often happen in email and chat, where files wait for the right person.

What is the difference between detection and resolution in underwriting? Detection identifies an issue, such as an existing position or a missing month. Resolution ends that issue in a recorded outcome: cleared, offer adjusted or declined, with the evidence and the decision-maker stored on the deal.

Will a more accurate parser reduce time to funding? A more accurate parser reduces rework on bad extractions, which helps. Most time between submission and funding, however, is spent on exceptions, stips, approvals and re-keying terms, which a parser does not handle.

How should MCA funders track underwriting exceptions? MCA funders should track underwriting exceptions in a queue with a clear owner, a decision of approve, adjust or decline, and an audit record that captures the evidence at the moment of decision.

Does DueDeal replace my bank statement parser? DueDeal extracts and reconciles bank statements itself, so a funder can use it for analysis. A funder can also keep its existing provider during a parallel pilot and use DueDeal to run the workflow around the file.