"We've Always Filed It This Way": The Loan File Bottleneck Nobody Owns
Loan intake at most institutions was designed around whoever did the job years ago, and nobody has revisited it since.
TL;DR
Loan file intake at most community banks and credit unions was built around whoever handled the job years ago, and nobody has revisited it since. The result is a process where lenders spend more time collecting and re-typing documents than analyzing credit. This post separates the parts of loan intake that genuinely need a lender's judgment from the parts that are just moving data from one place to another, and describes what a narrow fix looks like.
Ask a commercial lender where a loan file actually loses time and you will rarely hear "underwriting." You will hear about the three weeks before underwriting started. The borrower sent four of the six documents requested. Two came back as photos taken on a phone. The tax return was for the wrong year. Somebody re-requested it, waited, then re-requested it again.
Gene Ludwig, who served as Comptroller of the Currency and now advises banks, described the scale of this in a March 2026 column for American Banker. He recounted speaking with a community banker whose typical small-business loan file involved more than 30 separate email exchanges just to gather financial documents. Weeks passed before the file was complete. Ludwig's broader point is that loan officers frequently end up spending more of their attention on intake than on credit analysis, and that institutions trying to grow lending volume often respond by adding staff rather than fixing throughput.
That last part is the expensive detail. Adding a person to a broken intake process makes the process faster without making it better, and the cost stays on the books permanently.
What makes this particular bottleneck stubborn is that it belongs to no one. Underwriting owns credit decisions. Loan operations owns the system of record. The intake process in between, the part where documents get chased, sorted, renamed, checked and typed, is shared by everyone and owned by nobody. Nobody's annual review mentions it, so nobody has a reason to change it.
Why This Keeps Happening
Most loan intake processes were not designed. They accumulated.
Someone built a workable routine years ago around the tools available at the time and the specific person doing the job. That person developed a filing convention that made sense to them. When they left, the next person inherited the convention without the reasoning behind it. A few years and a few handoffs later, the process is a set of habits nobody can fully explain but everyone follows.
The phrase you hear is some version of "that's just how we do it here." It usually means the last person who understood why left in 2019.
This is also why the problem survives technology purchases. An institution can buy a new loan origination system and still keep the same intake habits around it, because the habits live in email, shared drives and individual memory rather than in the system. The new system inherits the old workflow. Six months later the same three weeks are still disappearing at the front of every file, and the natural conclusion is that the software did not deliver, when the intake process was never really part of the implementation.
What's Actually Slow
Loan intake looks like one process. It is really two, and they have almost nothing in common.
The first is judgment work. Deciding whether a borrower's cash flow supports the request. Reading a tax return in the context of a business the lender knows personally. Noticing that a customer concentration looks different this year and asking about it. Structuring a deal so it works for both sides. This is what a lender is for, and it does not compress.
The second is data movement. Opening a 40-page PDF and figuring out where the tax return ends and the bank statements begin. Renaming files so the next person can find them. Typing figures from a scanned document into a spreading tool. Checking whether all six required documents actually arrived. Emailing the borrower because one did not.
The second category consumes a meaningful share of the calendar time on most files, and it requires none of the skills the institution is actually paying a lender for. It is careful, tedious, error-prone work that a capable person can do and a capable person resents doing. The separation matters because the two categories call for completely different responses.
Judgment work gets better with experienced people and more time. Data movement gets better with structure and less human handling. Institutions that treat the whole file as one undifferentiated block of "loan processing" end up applying the wrong fix to both halves, usually by hiring.
What a Narrow Fix Looks Like
Once the data movement is separated out, the fix stops looking like a system replacement and starts looking like a specific, contained tool.
A document sorter works on the front end of the file, before anyone in lending touches it. A packet arrives, however it arrives. The tool classifies each document by what it actually contains rather than what the file is named, splits the packet into properly labeled pieces, extracts the key figures once, and checks the set against a required-document list. Anything it cannot read confidently, or any figure that looks inconsistent across documents, gets flagged for a person to review before the file moves on.
What matters is what this does not touch. It does not make credit decisions. It does not change how the lender evaluates the deal, and it does not replace the spreading tool or the origination system. It handles the sorting and the first pass of extraction, which is the part nobody wanted to own, and hands off a clean, complete, consistently named file. Our automated loan document processing page goes through how that workflow is typically structured.
The scope is deliberately small, and that is the point. A tool that only sorts and extracts can be evaluated against one question: are files arriving at underwriting complete and usable more often than they were before. If the answer is no, the institution reverts to the old process and has lost a few weeks. If the answer is yes, the three weeks at the front of the file start to compress without anyone changing how credit gets decided.
What This Looks Like in Practice
Consider a $650 million community bank whose commercial lending team handles a steady flow of small-business files. Six documents are requested at application. On a typical file, four arrive in the first round, one arrives in the wrong format, and one requires three follow-up emails over two weeks. An analyst then splits the packet by hand, renames the pieces, and keys the figures into the spreading tool.
The lending team is not slow. The process has simply placed a two-week document chase and a manual sorting step directly in front of the work the team was hired to do.
A narrow fix here changes the sequence rather than the staffing. The completeness check happens at intake rather than after the analyst opens the packet, so the missing document is identified on day one instead of day nine. The sorting and first-pass extraction happen before the file reaches a person. The analyst's first look is at a complete, labeled file, and their attention goes to the figures that were flagged as inconsistent rather than to all of them.
Nothing about credit judgment changed. The bank did not replace its origination system. The lender's relationship with the borrower is the same, except that the borrower was asked for the right documents once instead of four times.
Questions to Ask About Your Own Intake Process
Most of what a lending leader needs to know can be established in a week of asking, without a vendor, a consultant, or a budget request:
How many separate emails does a typical completed file involve, start to finish? Pick three recent files and count.
How many calendar days pass between application and a complete document set? Separate that number from the time spent actually underwriting.
Which document is missing or wrong most often? There is usually one specific offender.
Who renames the files, and according to what convention? If nobody can state the rule, that is the finding.
How many hours a week does your most experienced analyst spend sorting and typing rather than reviewing?
What happens to a file when the person who normally handles intake is on vacation?
The last two tend to be the most revealing. Concentrated, undocumented work is both an efficiency problem and a continuity risk, and it is usually invisible until the person holding it is unavailable.
Have a Problem To Solve?
If your team has an intake routine everyone has quietly learned to live with, that's usually the clearest sign it's worth a second look. The most effective approach is to start small, one problem at a time, rather than looking for a single platform to fix everything at once. Plenty of these get solved with a small script, a quick automated workflow, or a purpose-built tool running inside your own environment. Our automation and micro-apps page covers that approach. If you'd like to talk through what a first project could look like, schedule a discovery call with one of our operations experts.
Frequently Asked Questions
Does automating document intake mean less contact with the borrower?
No, and it usually means better contact. Most of the back-and-forth in a slow file is administrative: re-requesting a document that was missing, unreadable, or the wrong year. Catching those gaps at intake means the borrower gets asked once, clearly, rather than repeatedly over several weeks. The conversations that actually build the relationship are the ones about the business, and those are the ones that get more room.
Will this work if our documents arrive in inconsistent formats?
Inconsistent formats are the normal case, not the exception. Borrowers send PDFs, scans, phone photos and spreadsheets, often in one packet. A sorter that classifies by content rather than by filename is built for exactly that situation. What matters more than format consistency is that low-confidence items get routed to a person rather than passed through silently.
How is this different from what our loan origination system already does?
Most origination systems assume documents arrive already identified and organized, and they manage the file from that point forward. The work of getting a raw packet into that state, splitting it, labeling it, checking it for completeness, generally still happens by hand before anything enters the system. A narrow intake tool addresses that upstream step rather than replacing the system.
Do we need to fix the whole lending process to see a difference?
No. Document intake sits at the front of the file and can be addressed on its own, which is part of why it makes a reasonable first project. Underwriting, approval and closing stay exactly as they are.
What about accuracy? Manual entry is error-prone, but so is extraction.
Both introduce errors, which is why the review step matters more than the extraction itself. The practical difference is that a tool flags what it is unsure about, while a tired analyst at four o'clock does not. Extraction with a person reviewing exceptions is generally more consistent than extraction with a person doing everything, and it produces a record of what was checked.
Is this worth doing at our volume?
That depends less on total loan volume than on how much lender and analyst time currently goes to sorting and re-typing. An institution closing a modest number of document-heavy commercial files can lose more hours to intake than one closing a higher volume of simple consumer loans. Counting the hours before assuming the answer is the useful first step.