Applicant statement bundles, reconciled before you read them.

What this is built for

Mortgage underwriting and pre-qualification, SBA 7(a) and 504 DSCR analysis, alternative-credit underwriting where bank statements substitute for a thin credit file, equipment-finance and merchant-cash-advance qualification, commercial loan renewals, hard-money draw verification, and the income-and- cashflow workpapers that sit behind every approval memo. Any workflow where the difference between "a clean spreadsheet" and "a clean spreadsheet that actually ties to the statement" matters at file level.

Why lenders pick pdftoexcel

• Reconciliation is the underwriting check that matters. Every export is checked against the statement's printed beginning and ending balance. Verified means the row set you are reading actually sums to what the bank printed — eliminating the most common source of approval-memo errors: a missed transaction, a sign flip, or a page-break gap that the original PDF extractor didn't flag.
• DSCR and cash-flow models start from clean data. Export to XLSX with the Description column intact and the signed amounts already typed correctly. Filter on originator name to see employer ACH cycles, NSF clusters, large-cash- deposit patterns, and irregular wire transfers without re-typing 200 rows from a PDF preview.
• Bundles process in one pass. Upload up to 10 statements at once. Three months of personal checking plus three months of business operating plus the SBA-required tax-year-prior copy all run in the same batch and download as a single ZIP, organized by month and account for the file binder.
• Scanned and password-protected files supported. Borrowers email mobile photos of mailed paper, faxed copies, and password-protected PDFs from their bank portal. All three paths produce the same Verified-or-flagged output — the borrower's file format isn't an excuse for a delayed underwriting decision.
• 77+ banks, plus an AI fallback for the rest. Hand-tuned fast-paths for the major US banks (Chase, Bank of America, Wells Fargo, Citi, Capital One, US Bank, PNC, TD, American Express, Discover, Navy Federal) and an LLM fallback that handles the regional banks, credit unions, and online-only banks that appear in actual borrower files.
• Audit trail you can attach to the file. Every conversion produces a reconciliation result — Verified or Unverified-with-flagged-row — that becomes part of the workpaper record. If a regulator or QC reviewer later asks how the income figure on line 3 of the approval memo was derived, the answer is in the converted file.
• Confidentiality you can put in writing. No LLM provider trains on your borrower data — both Anthropic and Google contractually exclude API inputs from model training under their commercial terms. Source PDFs are deleted on successful conversion. We sign a DPA on request — /legal/dpa.

What "Verified" means in underwriting context

The reconciliation check is intentionally narrow. It tells you one thing: the row set you are reading sums to what the statement printed at the bottom. It does not tell you the statement is genuine, that the borrower hasn't altered the source PDF, or that the income they claimed is sustainable — those are downstream judgements you and your QC team make.

What it does eliminate is the "quiet error" class: an OCR pass that drops a $4,800 ACH on page 6 of a 12-page statement, a sign flip on a single Zelle credit, or a missed row in a multi-section layout. Those errors are invisible at review time because the resulting spreadsheet looks clean — and they show up in the approval memo or the post-funding QC cycle as understated income, missed overdrafts, or a DSCR that doesn't reproduce. Verified rules them out at ingestion.

When verification fails, the export shows the first row where our reconstructed balance diverges from the printed balance. That is the row to look at before declining the file or requesting a clarifier — sometimes the divergence is a real error in the borrower's prep (combined statement, missing page), sometimes it is a layout edge case worth clearing up.

How a typical underwriting workflow runs through this

1. 1. Receipt. The borrower's 60- or 90-day packet arrives — usually as a single combined PDF, occasionally as separate per-month files, sometimes one or two pages obviously missing. Drop the bundle into the upload zone.
2. 2. Conversion. Each file parses in 2–10 seconds depending on length. Digital PDFs go through the bank-specific fast-path; scans and tricky layouts route through the LLM with the same reconciliation guarantee. Watch the queue; flagged files surface within the same batch.
3. 3. Verification check. Each export carries a Verified badge or a flagged-row pointer. Verified files are ready for the cash-flow model. Flagged files are the ones to review — the row pointer tells you exactly where to look before deciding whether to request a corrected statement from the borrower.
4. 4. Cash-flow analysis. Open the XLSX in your underwriting workbook. Filter by originator, run the DSCR formula, identify NSF and overdraft clusters, trace large deposits against the income statement. The data ties to the printed balance, so the model output reproduces.
5. 5. Workpaper attach. Both the original PDF (for compliance and audit) and the reconciled spreadsheet (for analysis) sit in the file binder. The reconciliation result is the audit trail connecting the two.

The plan most lending practices land on

FAQ for lending practices

Does this replace asset-verification services like Plaid or Yodlee?

No. Aggregator-based asset verification (Plaid, MX, Finicity, Akoya) gives you live read access to accounts when the borrower agrees to it. pdftoexcel converts the PDF artifact — what the borrower or their bank actually produces in writing. Both have a place: aggregator data is fastest when the borrower consents and their bank is supported; statement-PDF conversion is the fallback when they don't consent, the bank isn't in the aggregator network, or the file requires an audit-trail-able PDF (which most regulator-facing files do).

Can it detect a doctored PDF?

The reconciliation check catches one specific class of manipulation: a doctored statement where the inserted or deleted transactions don't balance against the printed beginning/ending figures. That is the most common form of crude alteration. Sophisticated alteration that also re-balances the statement summary requires a separate check — see the forensic accountant detection guide for the layered protocol.

What about borrowers who only have scanned statements?

Scanned files (mobile photos of mailed paper, faxed copies, low-DPI rescans) flow through the vision-OCR path instead of the direct text extractor. The same row-by-row reconciliation runs against the printed balance, so the Verified / Unverified outcome is the honest signal — scan quality affects whether the math closes, not whether the badge is real. If a scan is too poor to verify, the file is the right one to send back to the borrower for a cleaner copy.

Multi-originator pricing — can the LO pay vs the broker?

Today the subscription is per-account. Most small shops run a single firm-level account; Stripe receipts are issued in your firm's name. SSO and per-originator billing land on the Enterprise plan — email hello@bankpdftoxls.com if that's what you need.

Will you sign a DPA?

Yes. Standard DPA at /legal/dpa — covers most US lender QC and compliance requirements out of the box. Sub-processor list at /legal/subprocessors for vendor-management review.

What about non-US banks for cross-border lending?

Hand-tuned fast-paths for 24+ banks across the US and UK; LLM fallback handles EU, Canadian, Australian, and Latin American banks. Currency formats (1.234,56 vs 1,234.56), date formats (DD/MM vs MM/DD), and Portuguese / German / French / Spanish statements parse correctly — useful for cross-border SBA and commercial-loan files where the borrower has overseas accounts.

Banks we see most often in lending portfolios

Borrower bundles cluster around a few banks — the major US retail and SMB names dominate any 90-day origination batch. Each link below covers the bank's statement format, the parser quirks that break naive extraction, and the running- balance specifics that matter for DSCR and cash-flow workups.

Further reading for lending workflows

What borrowers actually do (and don't do) when prepping their statements, what underwriters specifically look for in the layout, and the SBA-side specifics that turn a clean cash-flow workup into an approval-ready memo.

About the operator

pdftoexcel is built and operated by Matrizexplícita Lda, a Portuguese limited-liability company. The product, the support queue, and the manual-review queue are run by Kyr Poskonoff — a single founder, intentionally. If you have a question about a difficult statement layout, a regulator-facing audit requirement, or a feature that would unlock your origination workflow, the email address answers within one business day.