Self-employed borrowers do not fail underwriting on the strength of their deposits. They fail on the construction. A file arrives saying the borrower earns a monthly figure, the underwriter opens the statements, picks three months, and finds a deposit that looks like a transfer between the borrower's own accounts. Now nothing in the file is trusted, including the parts that were right.
That is avoidable, and not by arguing harder. Build the number so the reviewer can rebuild it: every exclusion listed, the factor stated, every month tied out, the covered period named. This is the shape that survives a second reader.
What proof of income means when there is no pay stub
For a salaried borrower, income is a document: a pay stub, a W-2, a verification of employment. For a self-employed borrower, income is a calculation performed on business activity, and the only independent record of that activity is the bank account. Everything in the file exists to make that calculation reproducible by someone who was not there when you made it.
The calculation has four parts: the period, the qualifying deposits, the factor, and the monthly conversion. Three of the four are decided by the programme, not by you. The part that is yours is the evidence trail.
Twelve months or twenty-four
In bank statement lending these are not a light and a heavy version of one rule; they are two credit boxes with different floors, different leverage and different pricing. Twelve months is faster to assemble and stricter elsewhere. Twenty-four months shows seasonality properly and usually prices better. Neither is universally better for the borrower, and the answer depends on what the file can actually support — a business with one strong quarter looks better on twelve months and worse on twenty-four, which is exactly why the choice belongs to the programme.
Whichever period applies, the months must be consecutive and complete. Two missing months do not turn a twelve-month file into a ten-month file; they turn it into a file with a question in it.
Which deposits count
The recurring question is not "is this a deposit" but "is this revenue". These are the categories that come up on almost every self-employed file:
| Deposit type | Usually counts | Evidence to carry | Where people go wrong |
|---|---|---|---|
| Recurring receipts from customers or clients | Yes | Counterparty name in the description; recurring months | Counting a processor settlement and its underlying sales twice |
| Transfer between the borrower's own accounts | No | Both sides of the transfer, matched by date and amount | Counting the incoming leg and never seeing the outgoing leg |
| Proceeds of a loan or merchant advance | No | The funding deposit and the matching debt service | Treating new borrowing as trading income |
| Refund, chargeback, reversal | No | The original charge it reverses | Netted quietly into revenue without a note |
| Owner contribution or capital injection | No | The source account | Indistinguishable from a customer payment without the statement trail |
| Cash deposit with no traceable source | Programme-dependent | Deposit slips, invoices, sales records | Assuming cash is accepted because it is frequent |
| One-time spike (asset sale, settlement, insurance) | Only if the rules allow | The document behind it | Averaging it across twelve months silently |
Each exclusion gets its own line with a date, an amount and the statement page. A single "adjustments" figure is worse than no figure, because it asks the reviewer to trust an arithmetic step they cannot see.
The expense factor has to be visible
The factor is the programme's assumption about the cost of producing those deposits. It is usually different between the twelve-month and twenty-four-month boxes, and business statements normally carry a larger deduction than personal ones because business activity includes cost of goods and payroll. None of that is your number to choose.
What is your responsibility is putting it somewhere visible. Two preparers using the same statements and different factors will produce qualifying incomes far enough apart to change an approval, and when the difference cannot be located in the file, the reviewer assumes the worse of the two.
Tie out every month before it counts
On each statement: opening balance plus total deposits minus total withdrawals equals closing balance. This is the check that catches a misread digit, a skipped page and a dropped row, and it is the only independent test available on a bank statement. If a month does not tie, do not net the difference and move on — the rows that produced the income figure are precisely the rows in doubt.
Month Opening Deposits Withdrawals Closing Printed totals
Jan 18,204.55 41,882.10 39,004.77 21,081.88 tie
Feb 21,081.88 38,442.19 37,910.06 21,614.01 tie
Mar 21,614.01 52,300.00 39,776.42 34,137.59 tie
Detail rows for March, as read:
03/06 DEPOSIT 26,500.00
03/11 DEPOSIT 26,500.00 <-- the same figure twice; the page says 12,300.00
03/14 ACH DEBIT -39,776.42
03/20 DEPOSIT 13,500.00
Deposits as read 66,500.00
Deposits as printed 52,300.00 difference 14,200.00 = the misread row
21,614.01 + 66,500.00 - 39,776.42 = 48,337.59, not the printed 34,137.59The size of the break names the row: 14,200 is exactly the difference between what the page prints and what was read in its place. That is why the check is worth running per month rather than on the file as a whole — on a six-month file the total can absorb one bad month and still look plausible.
A month can also tie on totals and still be wrong line by line, if two amounts were swapped between rows: the arithmetic closes, the individual running balances do not, and the income figure is untouched while the row you would point at when challenged is the wrong one.
The ninety seconds a reviewer actually spends
- Three random months, opened in the statement. They are looking for a month where the deposits in the file do not match the page.
- The largest single deposit. Named counterparty, or a transfer with a plausible story.
- NSF and overdraft counts. Absent from the file reads as not checked, not as zero.
- The factor and the period, in the header. Missing either turns a calculation into a claim.
Put those four things where they can be found without scrolling. A file that answers them at the top gets read; one that makes the reviewer hunt gets returned.
When not to use us
- You need a tax return or a CPA letter. Deposit analysis does not replace a programme that requires a return, and no deposit reconstruction should be presented as one.
- The cash never hits the bank. If revenue is mostly cash and unbanked, statements are the wrong evidence and the file needs sales records or a different programme.
- You want a guaranteed qualifying income. The factor and the exclusions are decisions with a rationale, not a formula that always gives the same answer.
Where SheetParser fits
Upload the months, and the deposits are separated into operating receipts and the categories above, with each exclusion listed by date, amount and source page instead of subtracted invisibly. Every month is recomputed against its own opening and closing balance, so a missing page or a doubled deposit is caught before the packet is sent rather than by the underwriter. The workbook keeps the printed text of each cell alongside the numeric value, and the review list travels into the export.
What it does not do is pick the factor or decide which deposits qualify — those are the programme's rules and your judgement. It makes sure the arithmetic underneath them can be checked line by line, which is the part that keeps the file from being rebuilt. The proof of income packet is the output; if the same statements are also going into a bookkeeping system, start with the deposit analysis guide.