Income verification software proves the income, employment and identity an applicant stated, from the documents in their file, and hands an underwriter a figure with a source for every dollar of it. That is a higher bar than reading documents, which is what most tools in this market actually do, and the difference shows up six months after signature — when an examiner asks why a loan was approved at a particular income and the answer has to be a page, not a confidence score. Botminds’ Income and Document Verification is built around that question: six agents line up a referred consumer loan or card file, every figure they produce opens at the document and page behind it, and a named person decides and signs.
This page is the evaluation, written as if you were running it. It names what to ask, what to test, what to measure afterwards and where this kind of software does not belong. The figures from the solution are from its own fictional sample files and are marked as such; the research and the rules are linked under each figure.
What Income and Document Verification does on its sample files
72s
for six agents to read, check and line up a 12-document, 31-page file
14min
median time from a complete file to a decision, against 2.6 days by hand
100%
of verified figures tied to the document and page they came from — the design target
What income verification software is, and what it is not
Four different products get sold under this name, and conflating them is how evaluations go wrong.
A document reader extracts fields from a stub or a statement. Useful, and not verification: it tells you what the document says. A payroll data provider answers a query about an employee from an employer’s payroll system. That is verification, of one fact, for the employers it covers. A bank data provider returns transactions from the applicant’s institution. Also verification, of a different fact. Income verification software, properly so called, is the layer that uses all three plus the documents, applies your credit policy to produce a verified income and a ratio, and reports every disagreement between sources with the evidence attached.
The reason the distinction matters is that only the fourth kind produces a decision input. The first three produce data, and somebody still has to reconcile it — which is the hour you were trying to buy back.
What income verification software should do, and in what order
Six jobs, in a fixed order, because each depends on the one before it.
The six jobs, and why the order is not negotiable
- Sort and read every page
A referred file is a dozen documents in no particular order. Nothing downstream works until each page is identified and read, with the position of every figure kept.
- Test each document against itself
Gross to net, statutory tax percentages, year to date against the pay calendar, carried balances. Cheap, and it finds most forgeries.
- Compare the documents with each other
The stub against the W-2, the stub’s net pay against the deposit, the application against the recurring debits, the identity across all six sources.
- Apply your income-counting rules
Salary, overtime, bonus, commission, side income — each with its own history requirement. This is policy, not arithmetic, and it has to be yours.
- Produce a verified figure and a ratio
With the stated figure beside it, the difference as a percentage of stated, and every monthly obligation that went into the ratio.
- Draft what has to be asked for
The missing document, the dates, the reason, how to send it and by when — in plain words, for a person to send.
The nine questions to ask a vendor
Ask these on a file you bring, with the vendor driving and you watching the screen. Each one has a wrong answer that sounds fine.
Nine questions, the answer to listen for, and the answer to worry about
| The question | What a good answer looks like | What should worry you |
|---|---|---|
| Show me the page behind this figure. | One click opens the document at the right page with the value highlighted. | “It’s in the extraction output.” A reference is not a page. |
| What did you do with the figures you could not read? | They are listed as unread, with the page, and the file is marked incomplete. | A complete-looking answer with no unread count. Something was guessed. |
| Whose income-counting rules are these? | Settings the buyer owns: history required per income type, tolerances, ratio limits, approval limits. | A fixed model, or “we’ll configure it for you” with no screen to show. |
| What does it do when documents disagree? | Shows both, names the gap, and leaves the decision to a person. | Picks one silently, or returns a single blended figure. |
| Can it decline an application? | No. It produces findings; a named person decides. | Any version of yes, including “auto-decline on high fraud score”. |
| How do you handle an unbanked applicant? | The deposit match reports “no account provided” rather than a failure, and the file proceeds on other records. | A fraud signal, or a hard stop. |
| Show me a case where you were wrong. | A real example, with what changed afterwards. | There isn’t one. |
| What goes on the audit trail? | Every step with who, what and when; every rule change versioned. | Logs for support purposes only. |
| What does an adverse action reason look like? | A specific reason naming the figure and the record it rests on. | A model score or an internal code. |
The acceptance test: open any figure at its page
One test decides whether a product belongs in a credit process, and it takes thirty seconds. Pick any number on the screen — verified income, a monthly payment, a year-to-date total, the debt-to-income ratio — and ask to see where it came from. The right outcome is the document, open at the right page, with the value marked. Not a field name. Not a JSON path. The page.
It is a hard test because it constrains the whole architecture: every figure has to carry the document, page and position it was read from, through every calculation, including the derived ones. A ratio is three layers removed from the paper, and each of its inputs still has to be openable. That is why the solution reports the count beside the figure — on the sample file, 14 of 14 figures tied to a document — rather than reporting a confidence number. A count of untied figures is a measure a buyer can argue with; a confidence score is not.
The reason this is the acceptance test, rather than accuracy, is that accuracy is unverifiable at purchase and traceability is verifiable in the demonstration. A tool that is traceable can be measured on your own files afterwards. A tool that is accurate on the vendor’s files and opaque on yours cannot be measured at all.
Signing a verified figure: the decision in Income and Document Verification
The three prohibitions to write into the contract
Three things it must never do, and a lender should write them into the contract rather than hope for them.
It must never decline an application. A tamper signal is a reason to look, and it has innocent explanations — a payroll correction, a reprinted stub, a partial scan. In the solution any signal holds the file for a fraud analyst with the evidence attached, and clearing a signal takes a written reason that a second person reads. A system that declines on a signal will decline people whose documents were fine and will do it invisibly.
It must never send anything to the applicant on its own. A request for a document is a communication from the lender, and Regulation B shapes it: a notice of incompleteness has to specify “the information needed”, designate “a reasonable period of time for the applicant to provide the information”, and inform the applicant “that failure to provide the information requested will result in no further consideration being given to the application” (12 CFR 1002.9(c)(2)). Drafting that is useful. Sending it without a person is not.
And it must never count income without a document. The temptation is to fill a gap with an estimate so the file can proceed — an annualised two months, a plausible bonus, a rounded salary. The research on what rounded figures are worth is pointed: a study of marketplace consumer lending found that an index built partly from the roundness of stated income “predicts the likelihood of default, and the additional default risk is not compensated by higher interest”, in a sample where 29% of borrowers stated an income divisible by $10,000 (Pursiainen, Review of Corporate Finance Studies).
How to test income verification software on files you have already decided
Run it backwards. Take files whose outcome you know, feed them in, and read every case where the software disagrees with the person who decided at the time. This is the only evaluation that produces a number you can defend to a credit committee, and it needs no live traffic.
A back-test that produces a defensible number
| Design choice | What to do | Why |
|---|---|---|
| The sample | 200–400 referred files across at least two quarters, including every confirmed fraud case you hold | Seasonality moves document mix; confirmed cases are the only ground truth you own |
| The comparison | The software’s verified income and monthly obligations against the figures the analyst used | Two numbers, not a verdict. Verdicts hide where the difference came from |
| The pass line | Set it before you run: for example, agreement within 2% on verified income on 95% of files | A line set afterwards is a line fitted to the result |
| The disagreements | Read every one, and classify it: software right, analyst right, or unresolved | The ones where the software is right are the business case; the unresolved ones are the risk |
| The fraud cases | Check each confirmed case is flagged, and count how many clean files are flagged too | A detector that flags everything is not a detector. Count both sides |
| The stop test | Include files with missing pages, unreadable scans and unbanked applicants | What a tool does when it cannot answer matters more than what it does when it can |
Two published findings are worth reading before you set the pass line, because both are about the gap between what applications say and what is true. A study of mortgage applications in the 2002–2005 expansion measured income overstatement as the difference between income growth reported on applications and income growth reported to the IRS, and found the correlation between the two “goes to zero in the non-GSE market during the 2002 to 2005 period” (Mian and Sufi, NBER working paper 20947). And the Federal Reserve’s household survey found that 30% of US adults had income that varied at least occasionally through 2025 (Federal Reserve). The first says stated figures drift when nobody checks. The second says a single verified figure is a simplification of a moving thing, so expect disagreement with your analysts and read it rather than tuning it away.
The five numbers to report afterwards
Once it is live, a verification programme is reported in five numbers. Any one of them alone is misleading.
The five numbers, how to measure each, and how each can mislead
| Number | How to measure it | How it misleads on its own |
|---|---|---|
| Median time from a complete file to a decision | Clock starts when the last required document arrives, stops at the signature | Improves if you simply define “complete” later. Report the definition with it |
| Share of figures tied to a document | Count untied figures per file; target zero | Can be gamed by producing fewer figures. Report the figure count too |
| Files decided at verified rather than stated income | Count files where verified fell outside the tolerance and the decision used verified | A rise can mean better verification or a worse applicant mix. Trend it against stated-income distribution |
| Findings by type | Side or bonus income overstated, debt not on the application, a missing page or stub, an altered document | A single total hides whether you are finding fraud or finding paperwork. Keep the types apart |
| Confirmed altered documents | Only cases a fraud analyst confirmed, never raw signals | Signal counts flatter the tool. A signal is not a finding |
Note which number is missing: fraud losses avoided. Nobody can measure it on their own book, because the loans you declined do not default and the loans you funded at a verified figure would have performed differently at the stated one. The nearest honest public anchor is the volume of impersonation reaching lenders at all — 176,400 identity theft reports in the loan or lease category in 2024, of which 95,689 concerned a business or personal loan, up 18% on the year before (FTC Consumer Sentinel Network). Use that to size the problem, not to size a saving.
What it costs, and what it saves
Build the business case on the hour, because the hour is the only term you can measure. Everything else is directional.
The business case for verification software, term by term
Analyst time returned
referred files × minutes saved per file × loaded hourly cost
The one term you can measure before and after. Measure the minutes on your own files first; do not accept a vendor’s figure
Operations
Decisions taken at the right income
files where verified ≠ stated × the decision that changes
Some approve at a lower figure, some decline, some gain a condition. Value it at your own loss rate, and say it is an estimate
Credit risk
Applications that complete
files lost while waiting × contribution per funded loan
A referred file that takes days loses applicants to faster offers. Your own abandonment data is the input; ours would be a guess
Consumer lending
Software and integration
per-file or per-seat price + the work to connect your application system
Include the credit policy configuration and the time to agree tolerances internally, which is usually the longer job
Finance and IT
Process change
retraining + the second-signature workload + fraud analyst time on signals
A tool that finds more raises work before it lowers it. Budget the fraud analyst hour explicitly
Operations
A referred file by hand, and the same file through Income and Document Verification
By hand: Opening and reading a dozen PDFs, then comparing them by eye, line by line.
With the agents: The file arrives lined up, with the gaps numbered; the analyst spends the time on the decision.
By hand: The salary, the deposits that are easy to find, and whatever the queue allows.
With the agents: Every page, every pay date, every recurring debit, every identity field.
By hand: A judgement, and a note in a file.
With the agents: A verified figure, a ratio, a numbered list of what does not add up, and a page behind each.
By hand: The analyst.
With the agents: The analyst. This does not change, and should not.
By hand: A decision, and a reconstruction after the fact.
With the agents: Each step with who, what and when, and versioned rule changes.
By hand: The structural checks are the first to be dropped.
With the agents: The same six checks on the eleventh file as on the first.
Where it does not fit
Four situations where this software is the wrong purchase, said plainly because a vendor who cannot name them has not thought about it.
Where nothing is referred. If your decision engine approves or declines almost everything without documents, there is no file to verify and the gain is a rounding error. Buy it when the referred queue is a real queue.
Where the applicant has no documents. A thin-file applicant with cash income and no bank account cannot be verified from paper, and a tool that produces a signal in that situation is actively harmful. The requirement is that it reports “cannot verify” rather than “failed”, and that your policy has a path for those applicants that does not run through this software.
Where income is not the question. Small-ticket credit decided on credit history, and card limit increases on seasoned accounts, are governed by Regulation Z’s instruction to consider ability to pay (12 CFR 1026.51(a)), which many issuers satisfy without documents at all. Verification belongs where the amount justifies it.
Where the policy does not exist yet. If how side income counts, what tolerance applies between stated and verified, and who may approve at what amount are not written down, software will not supply the answers — it will freeze whichever answer somebody typed during implementation. The OCC’s expectation runs the same way: policies should define the expectations for obtaining and assessing borrower information, and policy exceptions in retail lending are tracked in three categories, one of which is “credit policy: loan-to-value (LTV), debt-to-income, pricing, verification, etc.” (OCC, Retail Lending, version 2.0). Write the rules first; the software is how they get applied the same way every time.
What a verification programme reports: the results screen
If you are running this evaluation, the two pages worth reading alongside are the ones that describe what the software has to do on the documents themselves: the arithmetic checks in how to identify fake pay stubs, and the six statement checks in bank statement verification software. The records a lender may rely on at all, and which of them settles a disagreement, are in how do lenders verify income.
Questions people ask
Can income verification software decline an application?
It should not, and you should contract for that. A tamper signal has innocent explanations — a payroll correction, a reprinted stub, a partial scan — and an automatic decline turns a reason to look into a decision nobody made. The arrangement that holds up is the one in the solution: a signal holds the file for a fraud analyst with the evidence attached, clearing it needs a written reason a second person reads, and a named person approves, declines or refers and signs.
How much does income verification software cost?
Pricing is usually per file, sometimes per seat, and the figure only means something next to the hour it replaces. Measure the minutes an analyst spends on a referred file today, on your own files, before you accept any vendor’s estimate — and include the costs most cases omit: the credit policy configuration, the integration with your application system, the retraining, and the fraud analyst time that a tool which finds more will create.
What is the ROI of income verification software?
The measurable part is analyst time returned and applications that complete rather than ageing out. The part everyone quotes and nobody can measure is fraud avoided, because the loans you declined never default. Build the case on the first two, label the third as an estimate with your assumptions written beside it, and report the five numbers afterwards so the case can be checked against what actually happened.
Does income verification software work for self-employed applicants?
Partly, and less well than for salaried ones. Tax returns, 1099s and bank deposits can all be read and compared, and the annualising arithmetic can be applied consistently — but the question with self-employment is continuance rather than amount, and continuance is a judgement about a business. Expect the software to assemble the evidence and expect a person to decide, and be careful about annualising one quarter of deposits as if it were a year.
What should we ask for in a vendor demonstration?
Drive it on a file you bring, and ask for four things: open any figure at the page it came from; show the figures the tool could not read; show the screen where your own income-counting rules live; and show a case where the tool was wrong. A vendor who can do the first three and has an answer to the fourth is worth a pilot. One who cannot open a page is selling a document reader.
How long does a verification pilot take?
Plan for a back-test before any live traffic: 200–400 referred files you have already decided, spanning at least two quarters, with the pass line agreed in writing before the run. Reading the disagreements is the slow part and the valuable part, and it is usually where a lender discovers that the useful findings are undeclared obligations and miscounted income types rather than forgeries.