Before an underwriter can analyze a single number, someone has to figure out what was actually submitted. A borrower's file might arrive as a single 40-page PDF mixing bank statements, a driver's license photo, a signed application, and a scanned voided check — in no particular order, sometimes upside down, occasionally missing pages. This sorting step is unglamorous, but it is where a surprising share of underwriting time disappears in merchant cash advance underwriting and broader SMB lending.
Document intelligence is the discipline of turning that raw, messy input into structured, labeled, and extractable data before analysis begins. Done well, it removes hours of manual sorting per file. Done poorly, it just moves the mess from a PDF viewer into a slightly nicer-looking dashboard.
What document intelligence actually needs to do
It is useful to break document intelligence into three distinct jobs, because vendors often only do one or two of them well.
Classification: knowing what you're looking at
The first job is identifying document type — this page is a bank statement, this one is a tax return, this one is a driver's license — even when files are combined, scanned at odd angles, or missing headers. Classification quality determines whether everything downstream works correctly; a bank statement misclassified as a generic PDF will never get analyzed for cash flow.
Extraction: pulling out the fields that matter
Once a document is classified, the relevant fields need to be extracted — account holder name, statement period, transaction lines, business name and address, EIN. This is harder than it sounds because statement formats vary enormously across thousands of banks and credit unions, each with their own layout, terminology, and formatting quirks.
Linking: keeping evidence connected to its source
The most commonly skipped job is linking every extracted value back to its exact location in the source document. Without this, an underwriter reviewing a flagged number has no fast way to verify it against the original page — they either trust it blindly or go hunting through the PDF manually, which defeats much of the point. Our guide on source-linked extraction covers this specific requirement in depth.
Why manual document review doesn't scale
A single experienced underwriter can typically sort and organize a borrower's file in a reasonable amount of time. The problem shows up at volume. As deal flow grows — particularly for funders working through broker and ISO channels where submission quality varies widely — the sorting burden multiplies faster than headcount usually can. Our related piece on the hidden cost of manual document review breaks down where that time actually goes.
There is also a consistency cost that is easy to underestimate. Two underwriters manually organizing the same messy file will not necessarily catch the same missing pages or misfiled documents. That inconsistency compounds into inconsistent downstream analysis, which is a much harder problem to detect and fix after the fact than a slow intake process.
Evaluating a document intelligence tool
- Test it on a genuinely messy file — a combined PDF with mixed document types, not a clean single-purpose upload. This is where classification quality actually shows up.
- Check what happens with unfamiliar bank formats. No system recognizes every bank's statement layout perfectly; ask how the tool flags uncertainty rather than silently guessing.
- Verify the evidence link works both ways. From an extracted field, can you jump straight to the source page? And from the source page, is it clear which fields were pulled from it?
- Ask about missing-document detection. A good system should flag when an expected document type appears to be absent, not just process whatever was uploaded.
- Understand the correction workflow. When extraction gets something wrong, how does an underwriter fix it, and does that correction get preserved for the file's audit trail?
How document types vary across MCA, term loan, and revenue-based financing files
Not every underwriting file looks the same, and document intelligence needs to handle that variety without requiring a separate configuration for every product. An MCA application typically centers on recent bank statements and a straightforward application form. A traditional term loan file might include tax returns, financial statements, and collateral documentation spanning a longer history. A revenue-based financing application often includes platform-specific revenue reports — Shopify or marketplace payout summaries, for instance — alongside standard bank statements, requiring document classification that recognizes formats beyond the traditional banking and tax document universe.
A document intelligence system built narrowly around one product's typical file composition tends to struggle when a lender expands into adjacent products, which is worth considering even for lenders currently focused on a single loan type.
What happens when document intelligence gets it wrong
No document intelligence system achieves perfect accuracy on every file, and it's worth thinking through failure modes explicitly rather than assuming they won't occur. A misclassified document — a tax return mistakenly tagged as a bank statement — should be easy for an underwriter to notice and correct, ideally within seconds, precisely because the source-linked evidence trail makes the underlying page visible rather than hidden behind an opaque extraction layer. A field extracted incorrectly — a transaction amount misread from a low-quality scan — should be flagged with a confidence indicator low enough that an underwriter checks it before relying on it, rather than presented with the same confidence as a cleanly extracted figure.
The practical question when evaluating a tool isn't whether it ever makes mistakes — it will — but whether mistakes are visible and correctable quickly, or whether they silently propagate into downstream financial analysis and policy evaluation without anyone noticing until much later, if at all.
Common mistakes in document handling
Treating OCR accuracy as the only metric that matters
Raw text-extraction accuracy is necessary but not sufficient. A tool can extract text perfectly and still fail underwriters if it cannot correctly classify document types, structure the extracted data usefully, or preserve links back to source pages. Evaluate the full pipeline, not just the OCR layer.
Losing page-level context during processing
Some systems extract data and then discard the connection to the original document layout entirely. This might seem efficient, but it removes the ability for a human reviewer to sanity-check extracted values against how they actually appeared on the page — a real problem when a statement has unusual formatting that could confuse automated extraction.
Ignoring document freshness and completeness checks
Document intelligence should flag not just what was submitted, but whether it meets basic freshness and completeness expectations — are the bank statements from the required lookback period, are all pages of a multi-page statement present. Skipping this pushes the check back onto the underwriter manually, undoing much of the time savings.
From here, this article is about Cevrynt
How Cevrynt structures document intake
Cevrynt's Document Intelligence module classifies and organizes submitted files, extracts decision-relevant fields, and keeps every extracted value linked back to its exact source page. This structured output feeds directly into financial analysis, verification, and fraud review without requiring an underwriter to re-key or re-organize anything manually.
The goal is not to remove the underwriter from document review, but to hand them an already-organized file with evidence one click away, so their time goes toward judgment calls rather than PDF archaeology. A qualified walkthrough is the best way to see how this handles your own representative file mix.