A Windows Micro-App that reads, classifies, renames, and files loan documents entirely on the local machine. No cloud. No API calls. No network access of any kind.
Installed like any other desktop application. No server, no integration project, no IT dependency.
Scanning is read-only. A single confirmed action is the only thing that writes to disk.
Confidence is arithmetic, not a model output. Each file records exactly why it was classified.
Point LoanSorter at a folder of loan documents — PDFs, Word files, and scans in any order, under any filenames. It identifies each document, gives it a name that follows your institution's convention, and files it into the right folder of your vault. Then it tells you what is still missing.
PDF text layer, Word text, or OCR for scans and images.
Weighted recognition phrases score each document against your types.
Dates, periods and tax years are pulled off the page.
Your naming format applied consistently to every file.
A proposed filing you review and can override, row by row.
For most software, "we don't send your data anywhere" is a policy. Here it is a property of the build — asserted by automated checks that fail the release if they stop being true.
The user interface runs fully sandboxed, with filesystem and network access removed rather than merely unused, under a content policy that permits no outbound connection.
Any package capable of making a network request is flagged by an automated check and must carry a written, reviewed justification before it can ship.
Part of every test run: a full batch of loan documents processed with every network primitive replaced by one that records and refuses. Any attempt to reach the network fails the build.
The text-recognition engine and its language data are installed with the application. The usual behaviour — fetching them from a content network on first use — is removed and checked for.
Documents containing borrower identifiers never traverse a network, are never held by a third party, and are never used to train anything. Sensitive values are stripped at the point of extraction, full document text is never written to disk, and no crash or usage reporting exists in the application at all.
Lending teams filing commercial loan packages by hand, where the document work sits between the closer and the credit decision and slows both.
Workstations that cannot reach the internet by policy — where a cloud service is not a procurement question but a non-starter.
Banks whose naming standards and credit-policy checklists already exist and are not going to change to suit a vendor's defaults.
Sorting software is only adoptable if a bad run cannot cost you the file. LoanSorter separates deciding from doing, and puts a confirmation between them.
The intake folder is opened read-only for the whole run. LoanSorter reads every document and produces a proposed filing.
One confirmed action applies the plan. It writes only into the destination vault, never back into the intake folder.
Every classification is a weighted score over recognition phrases your institution controls — deterministic, reproducible, and recorded. The manifest is the audit trail, so "why did it file this here?" always has an answer.
The system requires both high confidence (80%+) and a decisive margin before auto-classifying a document – Ties or close calls are always flagged for human review.
Each classified document records which recognition phrases matched and what each contributed. Nothing has to be reconstructed after the fact.
LoanSorter is software your team installs and operates, for institutions that need document handling to stay inside the building. If the constraint is capacity rather than data residency — you want the work done, not a tool to do it with — Polaris is the managed service version of the same problem.
See Polaris Automated Loan Document Processing →How to run a batch, read the results, correct a misfiling, and configure LoanSorter for your institution's conventions. Written for the person doing the work, not the person buying the software.
What you need before the first batch.
LoanSorter runs on Windows 10 or 11 (64-bit) and installs like any other desktop application. It needs no server, no database, and no network connection — at install time or afterwards.
Every run involves exactly two locations, and keeping them straight is most of what there is to learn:
| Folder | What it is | What happens to it |
|---|---|---|
| Intake | The folder of loan documents you want sorted, as they arrived. | Opened read-only. Never written to, renamed, or cleared. |
| Vault | Your institution's organized destination — where sorted files land. | The only place LoanSorter writes, and only after you confirm. |
Open Settings and set the Default Vault Folder for this workstation. Every new batch starts pointed at it, so the destination is not a decision anyone has to make under time pressure.
It is stored as a local preference and is deliberately excluded when settings are exported. Importing a colleague's configuration can never silently redirect where this workstation files loan documents.
PDF, Word (.docx), and images — .jpg, .png, .tif. Scanned PDFs and photographs are read with built-in text recognition; nothing needs to be pre-processed.
Phase 1 — read-only. Nothing is written in this step.
Text recognition warms up in the background while the application starts, but a large first batch of scanned documents still takes longer than subsequent ones. This is normal and does not repeat within a session.
The Settings item is disabled during a run. Changing naming rules or document types mid-batch would make the results inconsistent with the plan you are about to review, so it is prevented rather than warned about.
Every proposed change, before any of it is real.
The results screen lists one row per document. This is the review step, and the point of the whole design — read it as a proposal, not a report of work already done.
| Column | What it tells you |
|---|---|
| Raw File Name | The document exactly as it arrived, so you can find it in the source folder. |
| Detected Type | The document type LoanSorter identified — or Unclassified if it could not decide confidently. |
| Confidence | The score behind that decision. See Unclassified documents. |
| Standardized Clean File Name | The name the file will be given, following your institution's naming format. |
Each row carries a status so a long batch can be triaged at a glance:
| OK - Sorted | Confidently identified, named, and ready to file. No attention needed. |
| Review Required | LoanSorter could not identify this document confidently. It needs a decision from you. |
| Error | The document could not be read at all — corrupt, password-protected, or an unsupported format. |
Change the type on any row and the proposed filename and destination folder update immediately. Your override always wins over the detected type, and it takes effect for that run only — it does not silently retrain anything or alter your configuration.
A row override fixes one run. If a document type is consistently missed, the durable fix is a recognition phrase on the Document Types tab in Settings — see Settings.
Use the reset action to abandon a run. You will be asked to confirm with Reset this run?. Because nothing has been written to disk at this point, there is genuinely nothing to undo — you return to the start and can run the folder again.
Why a document lands in review — and what to do about it.
An Unclassified result is not a failure. It is LoanSorter declining to guess, which is the behaviour you want in a loan file.
Each document type carries recognition phrases with an importance weight. LoanSorter scores the document against every type and then applies two tests:
| Test | Requirement | Why |
|---|---|---|
| Minimum confidence | Best score is at least 0.80 | Weak evidence should never file a document anywhere. |
| Minimum lead | Best score beats the next by at least 0.15 | Two plausible types is a question for a person, not a coin toss. |
Failing either test sends the document to review. A document can score 0.92 and still be unclassified, because something else scored 0.85 — strong evidence for two different types is exactly the case worth stopping on.
Both thresholds are adjustable on the Classification tab, but lowering them does not improve recognition — it converts documents that would have been reviewed into documents filed on weak evidence. If a type is consistently missed, add a recognition phrase for it instead.
Phase 2 — the only step that changes anything on disk.
When the plan is right, click Save Organized Folders & Rename. A confirmation appears — Save Organized Folders & Rename? — stating how many files will be written and the exact destination path. Nothing happens until you confirm it.
Confirming is the only action in the workflow that writes to disk. Everything before it can be abandoned freely; after it, correcting a misfiling means moving files in the vault yourself. Review the plan properly before confirming — that is what the review step is for.
What comes out of a completed batch.
After saving, the results screen gives you the paperwork side of the batch — both the record of what was filed and the list of what is still outstanding.
| Export | What it contains | Typical use |
|---|---|---|
| Export Manifests | The full record of the batch: every document, its type, its confidence, the evidence behind the classification, and where it was filed. | The audit trail. File it with the loan. |
| Export Punch-List PDF | The checklist requirements this loan has not yet satisfied. | The internal follow-up list. |
| Export Missing Items PDF | The same outstanding items, formatted for sending outward. | Requesting documents from the borrower. |
| Generate Deficiency Email | A drafted message listing what is missing. | The follow-up email, ready to review and send. |
Every export lands as a file in the loan's folder. The deficiency email is drafted — LoanSorter has no ability to send mail, and reviewing and sending it stays with you.
The Batch History tab in Settings lists previous runs on this workstation, so a batch can be found again without reconstructing which folder it came from.
Six tabs. Your conventions, not the vendor's defaults.
Naming rules, document types, and the checklist matrix are configuration, not compiled-in constants. Each institution tunes them in the app — no rebuild, no vendor request.
| Tab | What you control |
|---|---|
| Vault & Folders | The default vault for this workstation, how borrower folders are named, and which categories documents are filed into. |
| File Naming | Your naming formats and which one is the default. This is what produces Standardized Clean File Name. |
| Document Types | The document types LoanSorter recognizes, their recognition phrases, and which folder each one files into. |
| Loan Checklists | The credit-policy matrix — which documents each loan type requires. See Loan checklists. |
| Classification | The confidence and lead thresholds, and how much different document sources are trusted. |
| Batch History | Previous runs on this workstation. Read-only — nothing to save here. |
On the Document Types tab, a recognition phrase is written in plain English with an importance level — "personal financial statement", marked as strong evidence. You are describing what the document says, not writing a pattern.
An existing phrase that was hand-tuned by a technical user appears in an advanced mode showing the raw pattern instead. That is deliberate: LoanSorter will not regenerate over a precise pattern someone wrote on purpose.
Validation is all-or-nothing. A save applies only when every tab is valid; if anything fails, nothing is written and the running configuration is left exactly as it was. Errors are reported as a trail to the offending field — File Naming → borrower_first → Pattern — and highlighted inline on the tab.
Export your settings as a single file, review it once, and import it on every other machine. Each institution's conventions get approved one time and installed everywhere.
The destination folder is machine-local and deliberately excluded, so importing a colleague's configuration cannot redirect where this workstation writes loan documents.
What the loan still needs — evaluated by date, not by count.
A checklist profile describes what a loan type requires. After a batch, each requirement is evaluated against what was actually filed and reported as:
COMPLETE PARTIAL DEFICIENT
This is the part that matters, and the part most document tools get wrong. Requirements are not presence counts — LoanSorter reads the period each document covers and evaluates against it.
Two January statements and a February statement do not satisfy "3 consecutive months of bank statements". A tool that counted documents would mark that requirement complete. LoanSorter marks it PARTIAL and tells you which month is missing.
| Requirement | What it actually checks |
|---|---|
| Consecutive months | An unbroken run of months — gaps and duplicates are both caught. |
| Distinct tax years | Separate tax years, so three copies of one year does not satisfy a three-year requirement. |
| Count within a period | Enough documents, and recent enough — a stale document does not count. |
| Presence | The document is simply there. Used where recency is not the point. |
Outstanding requirements are what feed Export Punch-List PDF, Export Missing Items PDF, and Generate Deficiency Email — so the follow-up list is produced from the same evaluation, not maintained separately by hand.
The problems that actually come up.
Almost always a configuration gap rather than a defect: the document types in use do not carry phrases that match what your documents actually say. Open a few unclassified documents, note a phrase that appears on all of them and nowhere else, and add it on the Document Types tab. Do not start by lowering the thresholds — see Unclassified documents.
LoanSorter reads a PDF's text layer first and only falls back to text recognition when there is too little usable text. Very low-resolution scans, heavy skew, and faint faxes all reduce what recognition can recover. Rescanning at 300 DPI, straight, in greyscale fixes most of these. A document that is genuinely illegible to a person will not be recovered.
The file could not be opened at all. The usual causes are password protection, a corrupt download, or a file whose extension does not match its actual format. Open it manually to confirm — if it will not open for you, LoanSorter cannot read it either.
LoanSorter deliberately fails loudly rather than starting in a degraded state. If a required component is missing or a configuration file is invalid, it stops with a message naming the exact file. That path is the fix — a reinstall restores missing components, and an invalid configuration file can be replaced by re-importing a known-good export.
Windows limits a full path to 260 characters. Where a generated name would exceed it, LoanSorter shortens the name rather than failing the file. Deeply nested vault folders and long borrower names make this more likely; a shallower vault structure gives names more room.
Have the batch manifest to hand — Export Manifests produces it — and get in touch. It records what was classified, with what confidence, and on what evidence, which is usually enough to identify the cause without sending any documents anywhere.
What banks ask before deploying it.
No. LoanSorter makes no network connections of any kind. There is no cloud service, no API, no telemetry, and no crash reporting. Everything — text extraction, OCR, classification, and filing — happens on the workstation.
No. The intake folder is opened read-only for the entire run. LoanSorter only ever writes into the destination vault you choose, and only after you confirm the Save Organized Folders & Rename dialog.
It is marked Unclassified and routed to review rather than filed into a guessed category. A document is classified only when it scores at least 0.80 and leads the next-best match by at least 0.15, so near-ties always reach a person.
No. Classification is a deterministic weighted-anchor score, not a model output. The same document scores identically every time, and every classification records which recognition phrases matched, so any decision can be explained and audited.
Yes. Document types, recognition phrases, naming formats, folder structure, and the credit-policy checklist matrix are all edited in the app's Settings screen. No rebuild is required, and the whole configuration can be exported as a single file and installed on other workstations.
Yes. LoanSorter reads a PDF's text layer first and only rasterizes and runs OCR when a page yields too little usable text. Images are sent straight to OCR. The OCR engine and language data are installed with the application and are never downloaded.
Windows 10 or 11, 64-bit. It installs per workstation and needs no server, no database, and no network connection at install time or afterwards.
The fastest way to evaluate LoanSorter is a folder of your own documents on your own machine — nothing leaves it, so there is nothing to approve first.
