LenderAnalyzer exposes its bank statement analysis engine as a REST API. Upload a statement PDF, poll or receive a webhook, and get back structured transactions plus the computed underwriting metrics: true revenue, average daily balance, NSF counts, negative days, recurring deposits and existing debt payments, all as JSON your underwriting flow can act on. API keys, no sales call, self-serve from $99 a month.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Uploading...
Upload a bank statement and watch the analysis run live, free, no signup required.
If you are building a lending product, the bank statement is the hardest input you have to deal with. It arrives as a PDF, every bank formats it differently, some are scanned images rather than text, and the numbers your credit logic actually needs, monthly revenue, average daily balance, NSF hits, days negative, existing loan payments, are nowhere in the document as fields. They have to be computed from hundreds of individual transactions. A bank statement analysis API turns that PDF into machine-readable data your code can use. There is an important distinction to make here, because two different kinds of API get called the same thing. A bank statement OCR or parser API gives you the transactions: date, description, amount, balance, in a structured list. That is extraction, and it is only half the job. Your team still has to write and maintain the logic that classifies each transaction, separates real revenue from transfers between the borrower's own accounts, finds the recurring debits that are somebody else's loan, and computes the ratios your credit box is written against. An analysis API returns the computed metrics alongside the transactions, so the underwriting math is already done. LenderAnalyzer is the second kind. You POST a statement to the upload endpoint, run an extraction, and retrieve a JSON result containing both the transaction-level data and the derived analytics: true revenue net of transfers, average daily balance, NSF and overdraft counts, negative-day counts, recurring income streams and the existing debt service the borrower is already carrying, including signals of loan stacking. Register a webhook and your service is notified the moment an extraction finishes instead of polling. The same engine also reads tax returns and financial statements, so one integration covers the document set most lenders underwrite on. Pricing is published and self-serve, from $99 a month on the plans that include API access, which means a developer can get a key and have the first statement parsed the same afternoon rather than waiting on a procurement cycle.
Most teams underestimate this integration, because parsing a statement looks like a solved problem until you meet the tenth bank format. Here is what the work actually involves and how to evaluate an API against it.
A parser API hands you transactions. An analysis API hands you conclusions. The gap between them is where lending engineering teams lose months. Once you have a list of transactions you still need to decide which deposits are real revenue and which are the borrower moving money between their own accounts, which debits are a competitor's daily loan payment, how to compute average daily balance across a period with gaps, and how to count NSF fees separately from days the account actually ran negative. That logic is not hard to write once; it is hard to keep correct across thousands of banks and edge cases. If you buy extraction only, budget for building and owning that layer yourself. If you buy analysis, check the vendor returns the specific metrics your credit policy is written against, not just a generic cash flow summary.
Document analysis is not a request-response operation you can hold a connection open for. A 24-month statement package can be hundreds of pages, and scanned files take longer than digital ones. Any credible API is asynchronous: you upload, you get an identifier back immediately, and the result arrives later. LenderAnalyzer works that way. POST the document to the upload endpoint, call extract to start the job, then either GET the extraction by its hash until the status shows complete, or register a webhook endpoint and receive the extraction.completed payload when it lands. Build the webhook path if you can. Polling works and is simpler to ship, but it wastes calls against your rate limit and adds latency to the borrower experience for no benefit.
Test with your own worst documents, not the vendor's sample file. Every API demos well on a clean, digitally generated statement from a large national bank. The files that break integrations are the ones a small business actually sends: a phone photo of a printed statement, a credit union format nobody has seen, a business account with three hundred card-settlement deposits a month, a statement with the first page missing. Run twenty real files from your own pipeline and check three things: did it read every page, are the transaction amounts and running balances arithmetically consistent, and can you trace each computed figure back to the transactions behind it. A number you cannot trace is a number you cannot defend in a credit file or an audit.
Document APIs in this category price in one of two ways. Enterprise vendors meter per document or per page with unpublished rates that depend on document type, volume and contract term, which makes the unit cost of a loan application impossible to model until you are already negotiating. Self-serve vendors publish a subscription with an included volume. Neither is automatically cheaper: at very high volume a negotiated metered rate can beat a subscription, and at low or spiky volume a published plan almost always wins because you are not committing to a minimum you may not hit. The surprise for most teams is the reprocessing cost. Statements get re-uploaded, applications get re-underwritten, and a per-document meter charges every time. Model your real volume including retries before you compare a metered quote against a flat plan.
What each type of API actually returns, and who it fits. Last updated July 2026; enterprise rates are quote-based, so confirm current figures with each vendor.
| API | What it returns | Computed underwriting metrics | Self-serve key | Pricing |
|---|---|---|---|---|
| LenderAnalyzer This page | Transactions plus computed analytics as JSON, with webhooks on completion | Yes: true revenue, average daily balance, NSF, negative days, recurring income, existing debt and stacking signals | Yes, no sales call | Published, from $99/mo on plans with API access |
| Ocrolus | Classification, extraction, fraud signals and cash flow analytics over an HTTP JSON API | Yes, with a broad analytics and fraud suite aimed at larger lenders | Self-serve signup with a trial page limit, then a quote | Metered per document, rates not published |
| Plaid and open banking APIs | A live feed of transactions after the borrower logs into their bank | Balance and income insights, but only for accounts the borrower connects | Yes for sandbox, quote for production | Quote-based |
| Generic OCR or parser APIs | Text and a transaction list from the PDF | No, you build the classification and the ratio math yourself | Usually yes | Low per page, plus your engineering time |
Comparison compiled by LenderAnalyzer from public vendor materials, June 2026. Competitor names are trademarks of their respective owners; figures may change, so verify current details with each vendor.
Computed deterministically from every extracted transaction, every figure traceable to its source line.
Computed across the full statement period, carried forward day by day.
Deposits vs withdrawals and net flow, broken down month by month.
Every insufficient-funds and overdraft incident counted, with fees totaled.
Recurring deposits grouped into income streams with estimated monthly amounts.
Debits to other lenders and funders detected and totaled per month.
Days below zero across the period, a direct stress signal.
The biggest credits with dates and sources, concentration flagged.
Automatic red and yellow flags your analysts can review in seconds.
Drop in PDFs, scans or photos, one statement or a multi-month package, from any bank.
Every transaction is extracted, then cash flow, balances, income streams, NSF activity and debt payments are computed.
Read the underwriting snapshot, download the Excel report, or pull structured JSON into your LOS via API.
28 lending document types extracted out of the box, build the complete picture of an applicant's financial situation.
Common questions from lending and credit teams.
A bank statement analysis API takes a statement PDF and returns structured data your software can act on. A basic parser API returns the transactions. An analysis API also returns the computed underwriting metrics: revenue net of transfers, average daily balance, NSF counts, negative days, recurring income and existing debt payments. LenderAnalyzer returns both, as JSON, so your credit logic reads numbers instead of parsing a document.
POST the file to an upload endpoint, start an extraction job, then retrieve the result when it completes. With LenderAnalyzer you upload the document, call the extract endpoint, and either poll the extraction endpoint by its hash or register a webhook to be notified on completion. The response is JSON containing every transaction with date, description, amount and running balance, plus the computed analytics derived from them.
Yes. Statement analysis takes longer than an HTTP request should stay open, especially on long or scanned packages, so the API is asynchronous. You get an identifier back immediately and retrieve the result when the job finishes. Registering a webhook endpoint is the better pattern: your service receives the extraction payload as soon as it is ready, instead of polling and burning rate limit while you wait.
Yes. The engine handles digitally generated PDFs and scanned or photographed statements, which matters because small business borrowers routinely send a phone picture of a printed statement. Quality still affects results, as it does with any document AI. The right way to judge this is to run twenty of your own real files, including the bad ones, and check that every page was read and the transaction balances reconcile.
It depends on the model. Enterprise document APIs meter per document or per page at rates that are not published and vary by document type, volume and contract term. LenderAnalyzer publishes its pricing and includes API access from $99 a month, with about 50 percent off annual billing. Model your real volume including reprocessing before comparing a metered quote to a flat plan, because re-underwritten files get charged twice on a meter.
OCR gets the text and transactions off the page. Analysis decides what they mean. An OCR or parser API leaves you to build the logic that separates revenue from internal transfers, identifies recurring loan payments, computes average daily balance and counts negative days. That logic is the expensive part to build and maintain across thousands of bank formats. An analysis API returns those metrics already computed and traceable to the underlying transactions.
Yes. API access is included on the Pro and Elite plans rather than the entry tier, and you authenticate with an API key you generate in your account. There is no sales call and no contract to sign first: create the key, and you can send the first document through the upload endpoint straight away. Full request and response examples, error codes and rate limits are on the API documentation page.
Yes. The same extraction pipeline reads tax returns and financial statements, not just bank statements, so a single integration covers most of the document set a lender underwrites on. That matters for business lending, where the file is usually statements plus returns plus a financial statement, and you would otherwise be integrating and maintaining separate vendors for each document type.
Analyze your first statements free, plans from $99/month, 50% off billed annually.
From the same family of tools
