LenderAnalyzer reads a borrower's pay stubs, pulls gross pay, net pay, deductions, pay period and year-to-date totals into structured fields, then recomputes the arithmetic and lines the net pay up against the deposits in the bank statements you already collected. Where the stub disagrees with the account, you see it. Self-serve from $99 a month, no platform contract.
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.
Pay stub verification is the step between accepting a document and believing it. A pay stub is the easiest income document in the file to fabricate: dozens of US sites will generate a convincing one in a minute for less than the price of lunch, and the result is a clean PDF with a plausible employer, a plausible salary and no obvious defect.
What a generated stub usually cannot survive is arithmetic and corroboration. LenderAnalyzer extracts the fields, checks whether gross pay minus the listed deductions actually equals net pay, whether the year-to-date figures are consistent with the pay period and the pay frequency, and whether the stated net pay shows up as a matching deposit in the borrower's bank statements on or near the pay date. Those three checks catch most of what manual review misses, because an underwriter reading a stub at four in the afternoon is checking that it looks right, not recomputing the withholding.
Scope, stated honestly: LenderAnalyzer does not connect to payroll systems and does not contact employers, so it cannot certify that an employment relationship exists. It is a document analysis layer, not a verification-of-employment service and not a decisioning engine. It reads the stubs and statements you collect, computes the checks, and shows the underlying numbers so a second reviewer can reproduce every flag. Whether a discrepancy kills the file stays with your credit policy.
Verification is a sequence of cheap checks that get progressively harder to fake. Run them in order and most fabricated stubs fail before anyone picks up a phone.
A real pay stub is generated by a payroll system that computes withholding from tables, so the numbers reconcile: gross pay minus federal, state, Social Security, Medicare and any voluntary deductions equals net pay, and Social Security lands very close to 6.2 percent of taxable wages with Medicare near 1.45 percent. A fabricated stub is usually typed by someone who picked a salary and worked backwards, and the withholding is either a round percentage, a suspiciously tidy number, or missing entirely. Recomputing the line items takes a machine no time and an underwriter several minutes per stub, which is why it gets skipped on a busy pipeline. It is also the check that costs a forger the most effort to defeat.
Year-to-date figures are where fabricated stubs come apart, because they have to be internally consistent with three other things at once: the pay period shown, the pay frequency, and the date. If a stub covers the tenth semi-monthly period of the year, the year-to-date gross should sit near ten times the period gross, allowing for overtime and bonuses. A stub dated in March showing year-to-date earnings that imply eight months of work is not a rounding error. The same logic applies across a sequence: two consecutive stubs from one employer should show year-to-date totals that differ by exactly one period of gross pay, and when they do not, either a stub was edited or one of them was invented.
Document checks tell you whether a stub is internally sound. They do not tell you whether the money moved. The deposit record does. A salaried borrower paid by direct deposit produces a recurring credit that matches net pay, arrives on a predictable cadence, and carries a descriptor naming the employer or its payroll processor. When the stub says $3,180.44 every other Friday and the account shows $3,180.44 every other Friday from a descriptor that matches the employer, the income is corroborated by a source the borrower did not author. When the stub says $3,180.44 and the account shows irregular cash deposits, or nothing, the stub is the only evidence you have and it is evidence the applicant produced. That is the single most useful cross-check in income verification and it is the one LenderAnalyzer is built to run.
Plenty of honest files produce a stub that does not tie neatly to the account. Net pay can be split across two accounts, so only part of it lands where you are looking. A garnishment, a 401(k) loan repayment or a mid-period benefits change moves the number. Someone paid partly in commission has stubs that vary by design. A borrower who switched banks in month two has a gap that looks like missing income and is not. The right response to a flag is a question, not a decline: ask for the second account, the prior stub, or the offer letter. The value of automating the checks is that the questions get asked on every file instead of on the ones where an underwriter happened to look closely.
What each approach proves, how long it takes, and what it costs. Last updated August 2026.
Swipe sideways to see the full comparison
| Approach | What it proves | Time per file | Typical cost |
|---|---|---|---|
| LenderAnalyzer This page | Extracts gross, net, deductions, employer, pay period and year-to-date, recomputes the arithmetic, and matches net pay against bank statement deposits; every flag links to the numbers behind it | Minutes, self-serve | Transparent, $99 to $399/mo |
| Manual underwriter review | Whatever a trained reader catches by eye: obvious formatting defects, wrong employer details, implausible figures. Rarely includes recomputing withholding or tying net pay to deposits | Ten to thirty minutes per file | Free, but inconsistent under pipeline pressure |
| Payroll-connection API (Truv, Argyle, Pinwheel type) | Income and employment read straight from the payroll provider, which is the strongest evidence available and removes the document entirely. Only works when the borrower consents and the employer's payroll provider is supported | Seconds when coverage exists | Per-verification pricing, quote-based |
| Document forensics tool (Ocrolus Detect, Inscribe type) | PDF metadata, font and pixel-level tampering signals that catch an edited original a math check can miss. Strong on document authenticity, not built to reconcile income against deposits | Minutes | Quote-based, often per document |
Comparison compiled by LenderAnalyzer from public vendor materials; see the date noted above each table. 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.
Pay stubs are verified three ways, usually in combination. First, the arithmetic is recomputed: gross pay minus the listed deductions should equal net pay, and year-to-date totals should agree with the pay period and frequency. Second, the net pay is matched against deposits in the borrower's bank statements. Third, for high-stakes files, employment is confirmed directly with the employer or through a payroll data provider. Document checks alone prove consistency, not truth.
Yes, but only indirectly unless you go to the payroll source. A pay stub carries no signature, no watermark and no central registry, so nothing about the document itself proves it is genuine. What you can verify is whether it is internally consistent, whether it agrees with the borrower's other documents, and whether the money it claims was paid actually appears in the bank account. Direct confirmation requires contacting the employer or connecting to their payroll provider.
The reliable ones are mathematical: deductions that do not reconcile to net pay, Social Security or Medicare withholding that is far off 6.2 and 1.45 percent, perfectly rounded gross or net figures, and year-to-date totals inconsistent with the pay date. Presentation flags matter less than people think but still count: missing employer address, mismatched fonts, no check or advice number, a stub delivered as an image rather than a PDF, and misspelled personal details.
By matching net pay to deposits. A salaried borrower on direct deposit produces a recurring credit equal to net pay, on a predictable cadence, with a descriptor naming the employer or its payroll processor. The underwriter lines the stub's net pay and pay date up against that deposit. If the amounts and dates agree across two or three cycles, the income is corroborated by a record the borrower did not create. If they do not, the stub needs explaining.
Most US lenders ask for the two most recent stubs, covering roughly 30 days, alongside 60 to 90 days of bank statements. Two consecutive stubs are more useful than one because their year-to-date totals should differ by exactly one pay period of gross pay, which is a check a single stub cannot provide. Files with variable pay, commission or overtime usually need a longer history, and many lenders add the prior year's W-2 for the same reason.
Yes. Submitting fabricated income documents to obtain credit is loan application fraud, and where the lender is federally insured it can be prosecuted as bank fraud under federal law. Beyond the criminal exposure, the practical consequences arrive faster: the application is denied, the lender records the fraud attempt, and an approved loan discovered later can be called due. Lenders are also required to report suspected fraud in many circumstances.
No. LenderAnalyzer analyzes the documents you already collect. It reads pay stubs and bank statements, extracts the fields, recomputes the checks and reports where the numbers disagree. It does not place verification-of-employment calls and does not connect to payroll providers, so it cannot confirm that an employment relationship exists. If you need that, pair it with a payroll data provider or a written verification of employment.
It depends on the model. Document analysis platforms sold to enterprise lenders are usually quote-based, priced per document or per seat, and typically involve an implementation project. Payroll-connection providers charge per successful verification. LenderAnalyzer is self-serve with published pricing from $99 a month, so a small credit team can start on the same day without a procurement cycle or a demo call.
How credit teams run these calculations by hand, so you can see exactly what the software automates.
The nine checks an underwriter can run by hand, with the math.
The same problem one document over, where recomputing balances is the tell.
Where stub review sits in a fast, thin-file consumer workflow.
Turning verified stubs into a qualifying income figure.
Analyze your first statements free, plans from $99/month, 50% off billed annually.
