Bank statement software in MCA underwriting — what's changed and what it costs you.

The 60-second answer

Three years ago, MCA underwriting was a person reading your bank statements, jotting numbers on a worksheet, and forming an opinion. In 2026, it's software — almost every funder over $50M in annual originations now feeds your statements into a parser stack (Ocrolus, Plaid, Heron Data, Validis) that extracts and scores 40+ variables in under 90 seconds.

That shift has compressed the time from application to decision — most funders now quote a same-day price band — but it has also made underwriting much harder to bluff. The software sees patterns humans missed: stacking, seasonal revenue collapse, payroll fragility, declining deposit consistency. And once the software's score lands, the merchant-side levers to negotiate price are narrower than they used to be.

This article walks through the dominant software stacks, what they actually measure, where they get it wrong, and how merchants prepare to get the best price the algorithm can give them.

The software stack in 2026

There are four layers in the typical MCA bank statement pipeline. Most funders pick one vendor per layer.

Layer 1: ingestion

PDF statements get OCR'd and parsed. Ocrolus is the dominant vendor — it powers underwriting at OnDeck, Bluevine, Funding Circle, Credibly, Kapitus, and most of the top 30 MCA funders. Its accuracy on bank statement OCR is in the high 99s for major US banks (Chase, Wells, BofA, PNC) and slightly lower for credit unions and regional banks.

Direct bank feeds via Plaid or Mastercard Open Banking(formerly Finicity) skip OCR entirely — the funder pulls structured transaction data from your bank's API after you authenticate. Cleaner data, faster decision, but the funder sees everything in the connected account window (usually 24 months back).

Layer 2: categorization

Every transaction gets tagged: revenue deposit, ACH debit, NSF event, transfer between accounts, payroll, card payment, MCA ACH, IRS payment, etc. Ocrolusand Heron Data handle this with trained ML models. Categorization is where most of the "intelligence" lives — getting the categories right is what lets the downstream score be accurate.

Layer 3: analytics

The categorized transactions feed a metrics engine that computes:

• True monthly revenue (deposits net of transfers and reversals)
• Average daily balance and lowest-day balance
• Deposit count and average deposit size
• NSF count and pattern
• Existing MCA detection (daily fixed-amount ACH pattern matching)
• Payroll regularity (bi-weekly or weekly fixed-amount outflows)
• Tax payment detection (IRS, state)
• Revenue trend (slope across the lookback window)
• Seasonality (variance pattern by month)
• Customer concentration (recurring depositor analysis)

Heron Data and Validis are the dominant analytics vendors. Some funders build this layer in-house.

Layer 4: scoring + decisioning

The metrics feed the funder's credit model, which outputs a paper grade (A/B/C), a price band (e.g., 1.28-1.32 factor), and a maximum advance amount. The model is usually a gradient-boosted tree or logistic regression trained on the funder's own historical performance data — defaults, prepayments, renewals, recoveries.

The model is the funder's secret sauce. Two funders running the same Ocrolus + Heron stack will price the same merchant differently because their internal scoring is trained on different portfolio histories.

What software sees that humans missed

Stacking detection

Stacking — having multiple MCAs running concurrently — used to be hideable. A merchant would route MCA ACH withdrawals through a second bank account, submit statements from their primary account, and the funder would never see the existing debt.

The software shut that down. Plaid feeds expose every linked account on the same EIN. Ocrolus flags the daily-fixed-amount ACH pattern even when the descriptor is obfuscated ("MERCH CAP" instead of "KAPITUS"). Heron's stacking detector matches against a continuously-updated list of 200+ known funder ACH descriptors. The detection rate is north of 95% for any merchant with stacking on the same EIN.

True revenue vs gross deposits

Humans used to add up the deposits column. Software now distinguishes between actual revenue and:

• Transfers between merchant's own accounts (excluded from revenue)
• Reversed deposits (excluded)
• Loan proceeds (excluded)
• Refunds from vendors (excluded)
• Owner contributions (excluded)

A merchant who used to show $80K in monthly deposits might score at $52K in true revenue after the software strips out transfers. Funders price off the true number, which usually moves the merchant down a paper grade.

Payroll fragility

Modern parsers flag businesses where the cash position falls below the bi-weekly payroll amount in the days before payroll. That's a strong default predictor. Pre-2023 underwriting rarely caught this; in 2026 it's a standard scoring input.

NSF clustering

Two NSFs spread evenly across 90 days is treated very differently from two NSFs in the same week. The clustering pattern flags acute cash flow distress versus occasional mistakes. Funders weigh clustered NSFs 3-4x heavier in their scoring.

Where the software gets it wrong

The parsers aren't perfect. Three failure modes show up regularly:

Industry-specific revenue patterns

A restaurant runs daily merchant processor batches that look like daily revenue. A construction contractor receives milestone payments — three lumpy deposits per quarter. A trucking carrier receives factor advances that look like loan proceeds. The software often misclassifies these and either undercounts revenue (construction, trucking) or overcounts deposit consistency (restaurants).

The fix: most funders allow an underwriter override on suspicious categorizations. Volunteer a one-paragraph explanation with your application if your revenue cadence is unusual. It often saves a half-cent of factor.

Multiple-account merchants

A merchant with operating, payroll, and reserve accounts who only submits one statement looks weaker than they are. The software sees transfers out and counts them as outflows. Plaid feeds on a single account miss the full cash picture.

The fix: connect or submit all business accounts. The downside (the funder sees more) is almost always less than the upside (the funder sees the real cash position).

Recent business model changes

A merchant who pivoted in the last 90 days — added a new revenue line, dropped a bad customer, restructured a contract — looks volatile to the algorithm. The lookback window can't distinguish between deterioration and intentional change.

The fix: get an underwriter on the phone. The algorithm's score is the starting point; a 5-minute conversation that explains the pivot can move the price band by 2-3 cents.

How merchants prepare for software underwriting

Before applying

• Run 90 days clean. Zero NSFs, zero overdraft fees, zero returned items. Even one NSF in the lookback window can shift you a tier.
• Consolidate deposits. Funnel all revenue into one account. Avoid transferring money between accounts during the lookback window — every transfer is seen and categorized.
• Pay down stacked MCAs first. If you have an existing advance and want better terms on the next one, run the current one to 70%+ paid down before applying — the daily ACH burden shows up in every metric.
• Maintain a $5K-$10K cushion. Lowest-day balance is a major scoring input. A consistent floor of $5K+ moves the algorithm meaningfully.

At application

• Prefer Plaid if your statements are clean. Faster, richer data, more accurate decision. Use PDF if you need to control which months the funder sees.
• Submit all relevant accounts. Hiding accounts is the #1 reason decisions get reversed mid-funding. Funders cross-validate against merchant processor statements.
• Volunteer context for anomalies. One paragraph in the application notes explaining a one-time large outflow (tax payment, equipment purchase, owner distribution) can save you from a software penalty.
• Have CPA-prepared financials ready. P&L and balance sheet sometimes unlock manual review at top-tier funders, which can override the algorithm's score.

How the software is changing the broker game

Pre-software, brokers added value by knowing which underwriter at which funder would look kindly on which kind of deal. That knowledge mattered — a relationship broker could get a 1.38 deal funded at 1.34 by routing it to the right desk.

The software has flattened most of that arbitrage. The algorithm scores you the same regardless of which broker submitted. The remaining broker value is in (a) routing to the right funder's algorithm — different funders weight metrics differently — and (b) packaging the application well enough that the human override is invoked when the algorithm misreads you.

The brokers who add value in 2026 know exactly how each major funder's parser stack handles common merchant patterns. The brokers who don't are pure margin extractors who will route your deal to whichever funder pays the highest commission.

The trade-off the merchant didn't ask for

Software underwriting is faster, cheaper, and more consistent — three things that benefit merchants. It is also less forgiving. A merchant with a genuine explanation for a one-time bad month used to get a human conversation. Now they get a score, a price band, and a take-it-or-leave-it offer.

The merchants who do best in this environment are the ones who treat the bank statement window like a credit score: groom it actively, defend it from one-off shocks, and present it cleanly when the time comes to apply. The merchants who do worst are the ones who only think about funding when they need it — by then the lookback window has already locked in.