For lenders, brokers and underwriters
Bank statement converter for lenders and underwriters
Underwriting reads bank statements for deposits, recurring outgoings and anything that needs explaining. Getting the PDFs into a spreadsheet you can trust is the part this tool does.
- Applicant PDFs to Excel or CSV
- Missing pages show up as failed balances
- Every row linked to its line on the statement
- No scoring, no black-box figures
The short answer
How lenders turn applicant bank statements into reviewable data
A bank statement converter for lenders turns the PDF statements an applicant provides into structured transactions in Excel or CSV, checked against the balances the bank printed, so the review that follows starts from complete data. Underwriters and brokers then sort, filter and total deposits and outgoings in their own spreadsheet or system, with every row traceable to the page it came from.
The manual alternative is reading two to twelve months of statements on screen and keying deposits into a worksheet, which is slow and easy to get subtly wrong. Generic PDF-to-Excel tools are faster but give no indication that a row was dropped at a page break or that a page is missing from the file. In a lending review, a missed deposit or a missed regular payment changes the figure the decision rests on.
VouchRow does the conversion and the arithmetic checking. The analysis, the income figure and the decision stay with you and your policy.
The job
Establish what actually goes into and out of an applicant’s account, over some months, well enough to lend against. The statements arrive as PDFs, sometimes as photographs of printouts, from banks whose layouts you do not control.
Why a missing transaction matters more here
In bookkeeping a dropped row is an error to be found later. In underwriting it changes the answer. A missed regular outgoing overstates disposable income; a missed deposit understates it; either can flip a decision, and neither is visible in a spreadsheet that otherwise looks complete. And unlike a bookkeeper, you have no independent ledger to reconcile against — the statement is the only record you have.
Step by step
From applicant PDFs to a review spreadsheet
- 1Receive the statements as PDFsStatements downloaded from online banking convert best and upload in a batch. Scanned or photographed copies go through OCR one at a time. Password-protected PDFs ask for their password, which unlocks them in your browser.
- 2Convert and run the checksEach statement is read and checked: running balance row by row, page subtotals, opening balance plus movement against closing, printed credit and debit totals, transaction count.
- 3Look at what failed before anything elseA statement that does not reconcile is the first thing to understand. It may be a misread row on a poor scan, or it may be a page missing from what the applicant sent. The flagged row and the source line tell you which.
- 4Export to Excel for your reviewThe Excel export holds the transactions and a Reconciliation sheet. Filter credits to review deposits, look for large or irregular items, and total by month in whatever template your policy uses.
- 5Keep the trail with the fileThe Reconciliation sheet records what was checked. Each row links back to its line on the statement page in VouchRow, so a figure questioned later can be shown at its source.
What helps
What this does about it
The statement checks itself
The statement’s own running balance is the independent check you lack. Every consecutive pair is verified: previous balance plus this amount equals this balance. A transaction dropped anywhere in the file breaks that chain at exactly the row where it should have been, so completeness is demonstrated rather than assumed.
An audit trail back to the page
Every row records which page and which printed line it came from, and clicking it shows you. When a decision is questioned months later, the figure can be traced to the document it came from rather than defended from memory.
Structured data, not a picture of a table
Dates normalised, amounts as exact integers rather than floating point, signs resolved regardless of how the bank laid out its debit and credit columns. Excel or CSV out, ready for whatever model you assess with.
Applicant documents handled deliberately
Digital statements are read in the browser and never uploaded. Retention is a setting, including storing nothing at all, and expired data is deleted daily. There is a data processing agreement for the compliance review.
Why it works
What a lending review gets from a checked conversion
Completeness you can show
When the running balance chains from opening to closing, no row is missing between them. When it does not, you know where to look.
Missing pages surface
A page left out of a PDF leaves the statement unable to reconcile, because the movement no longer gets from the opening balance to the closing one.
Source line on every row
Click any deposit and see it highlighted on the original page, rather than trusting a cell in a spreadsheet.
Clean data for your own template
Dates normalised, amounts signed consistently, wrapped descriptions merged. Excel or CSV, ready for your worksheet.
Scans and photographs handled
Applicants send what they have. OCR reads scanned pages, and the checks show how far the result can be relied on.
Applicant data handled deliberately
Digital statements are read in the browser, scanned pages are discarded after the request, retention is your choice, and nothing is used to train models.
Checked before export
A misread digit is caught on its own row
Every conversion is tested against the statement: the running balance on every row, page subtotals, opening plus movement against closing, the printed credit and debit totals, and the transaction count. When a number does not add up, VouchRow names the row and highlights the line it came from on the PDF.
Arithmetic only: it verifies amounts, balances and totals, not descriptions or dates, and two errors that cancel out would pass. The source-line link covers the rest.
How the checks workRunning balance check
- POS AMAZON MKTPLACE−86.4316,604.12
- CHECK #1042−1,250.0015,354.12
- ZELLE FROM J MORALES+640.0015,994.12
Every row agrees with the balance printed beside it.
Deposits and outgoings
Bank statement review for deposits and regular payments
Most lending reviews of bank statements come down to a few questions: what comes in, how regularly, what goes out on a recurring basis, and whether anything needs an explanation from the applicant. The answers depend on reading every transaction, and that is exactly where manual review gets tired.
Once the statements are in Excel, the work becomes filtering and totalling. Credits can be sorted by amount to find large deposits that need sourcing; descriptions can be filtered to group a regular payer; debits can be grouped to see standing orders and loan repayments. You can label selected rows in bulk before export, for example marking transfers between the applicant’s own accounts so they are excluded from a deposits total.
The converter does not decide which deposit is income, compute an average, or apply an expense factor. Those are policy decisions, and they belong in your template where the method is visible. What the converter gives you is a dataset in which nothing has been silently dropped.
- Filter credits and sort by amount to review large deposits
- Total credits by month for a deposits schedule
- Label inter-account transfers so they can be excluded
- Open any row at its source line before relying on it
Completeness
Spotting gaps and missing pages through balance continuity
Applicants sometimes send incomplete statements: a page missing from the middle of a PDF, a month skipped in a sequence, a statement cut off before the closing balance. Reading on screen, those gaps are easy to miss.
Within a statement, VouchRow checks that the opening balance plus every transaction equals the closing balance, and where a running balance is printed, that every row follows from the one before. If a page with transactions is missing, that arithmetic fails and the statement is flagged. Across statements, the closing balance of one month should be the opening balance of the next; with the Reconciliation sheets side by side, a missing month shows up as a mismatch.
A failed check is a prompt for a question, not a conclusion. Poor scans produce misreads that fail the same checks. The source link lets you see which it is before you go back to the applicant.
| Situation | How it shows up | What to do |
|---|---|---|
| Page missing inside a statement | Opening plus movement does not equal closing | Ask for the complete statement |
| Month missing from the sequence | One closing balance does not match the next opening | Ask for the missing month |
| Row misread on a scan | Running balance breaks at one row | Check the source line and correct |
| Statement edited consistently | Checks pass | Not detectable by arithmetic; verify with the institution |
Analysis in Excel
Exporting to Excel for your own analysis
The Excel export is designed to be worked on. The Transactions sheet has one row per transaction with a normalised date, a description with wrapped lines joined, and a signed amount, plus the running balance where the statement printed one. The Reconciliation sheet lists the checks and their results.
From there, a pivot table by month and by credit or debit gives a first view of cash flow. Your own template can apply your policy’s rules to the deposits you accept. CSV is available if the data is going into another system; there is no API.
What this is not
Where conversion ends and underwriting begins
Lending is sold to by tools that promise income figures, risk scores and fraud flags. VouchRow is not one of them, and it is better to be clear about that on a page lenders read.
It does not compute qualifying income, classify deposits as salary, flag gambling or particular merchants, score affordability, or make a recommendation. It does not authenticate documents: a statement altered with its balances adjusted to match would pass the arithmetic checks, so authenticity questions need verification with the institution. If your process needs those outputs from software, a dedicated lending platform is the more direct answer.
What it does is narrower and still useful: it gets the applicant’s statements into a spreadsheet completely and checkably, so the judgement you apply is applied to the full record.
Applicant data
Handling applicant statements
Statements downloaded from online banking are read in the browser; their contents are not uploaded for extraction. Scanned statements are sent to the processing layer for the OCR request and discarded afterwards. Nothing is used to train models.
Retention is a setting: 24 hours, 7 days, 30 days, or store nothing at all. The security page describes the handling in detail for your compliance review.
There is no scoring, and no affordability model
Side by side
Reviewing applicant statements: the options
| Reading on screen | Generic PDF-to-Excel | VouchRow | |
|---|---|---|---|
| Gets every transaction into a sheet | Only if keyed | Usually | Yes, and checks it |
| Detects a dropped row | Rarely | No | Running balance breaks at the row |
| Detects a missing page | If you notice | No | Statement fails to reconcile |
| Trace a figure to the page | Manual search | No | One click |
| Scanned or photographed copies | Yes | Often poor | OCR plus the same checks |
| Income or risk figures | Your judgement | No | No, by design |
Who uses it
Where it fits in a lending workflow
Self-employed applicant, twelve months
Convert a year of business account statements, label transfers from the applicant’s personal account, and build the monthly deposits schedule in your own template.
Broker preparing a file
Check that every statement reconciles and that the months chain together before submitting, so a missing page is caught by you rather than by the lender.
Sourcing a large deposit
Filter credits by amount, open the deposit at its source line, and include the page reference when asking the applicant for an explanation.
FAQ
For lenders and underwriters: questions
Is this bank statement analysis software for lenders?
It is the conversion step that analysis depends on. It turns statements into checked transaction data in Excel or CSV. It does not calculate income, score risk or produce an underwriting report; that work happens in your own templates or systems.
Why do lenders need bank statements?
Lenders typically use them to see deposits, regular outgoings and balances over a period. Exactly what is required depends on the lender and the product, so check the relevant guidelines.
Can it calculate income for a bank statement loan?
No. It gives you every deposit, checked and traceable, in a spreadsheet. Which deposits count, how they are averaged and what expense factor applies are policy decisions for your template.
Will it detect a missing page?
If a missing page carried transactions, the statement will not reconcile, because opening balance plus movement no longer equals closing balance. A missing month shows up when one statement’s closing balance does not match the next opening balance.
Can it tell if a statement has been altered?
No. The checks prove the extracted figures agree with the balances on the page. An altered statement with consistent balances passes. Authenticity needs verification with the issuing institution.
Does it flag NSF fees, gambling or other red flags?
No. There is no flagging or scoring. You can filter descriptions in Excel for anything your policy looks for, and open each match at its source line.
What about photographed or scanned statements?
They are read by OCR, one statement at a time, and put through the same checks. Expect more flagged rows on poor images; each can be compared with the page.
Is there an API?
No. Output is Excel or CSV for now. If your pipeline needs an API, a tool built around one will fit better.
Keep going
Related guides and converters
Outputs for review
How the checks and trail work
Also relevant
Start every review from complete data
Create an account and convert an applicant’s statements to checked Excel. Plans start at $15 a month, metered by pages with transactions.