Reading a bank statement line by line

The bank statement is the most informative document in most retail and small business loan files. It shows what actually came in and what actually went out, month by month. Salary, existing EMIs, cheque returns, cash deposits and transfers to related accounts are all there, if you read it properly.

It is also the document most often summarised badly.

The temptation to summarise

It is now easy to give a language model a statement PDF and ask, "What is the average monthly salary and how many EMIs does this person pay?" The answer comes back in seconds, in fluent prose, with figures that look right.

The trouble is in what you cannot see. A language model reading a long statement does not work through it like a ledger. It can skip rows, merge two rows into one, misread a debit as a credit, or produce a transaction that is not on the statement at all. On a long statement with many pages, these errors are hard to spot from the summary, because the summary is all you are shown.

A credit decision built on a summary inherits every one of those errors, and nobody can tell which figures are affected.

Take every transaction from the statement itself

Sound statement analysis starts from a different place. Before any interpretation, every transaction is read from the statement as a row: date, narration, cheque or reference number, debit, credit and balance. Nothing is inferred or filled in at this stage. If a row cannot be read, it is marked, not guessed.

Most bank statements are tables with predictable columns, and a parser that understands the column layout of a statement reads them faithfully. This step does not need a language model at all, and is better without one: it should be repeatable, so the same statement gives the same rows every time.

Check the running balance on every line

A bank statement carries its own proof. Each row's balance should equal the previous balance, plus the credit or minus the debit. The opening balance carried through every transaction should arrive at the closing balance.

Checking this on every line does three things:

• It proves that no row was dropped or invented during reading. A missing transaction breaks the chain at that point.
• It catches misread amounts, such as a decimal point in the wrong place or a debit read as a credit.
• It exposes edits. If someone changes a credit to make salary look larger but does not adjust every balance after it, the arithmetic fails.

When the balance chain holds from the first row to the last, you know the transaction list is complete and correct as printed. Every figure you derive later rests on that.

Working out salary, EMIs, obligations and bounces

With a verified transaction list, the analysis becomes a matter of clear, reviewable rules rather than impressions.

• Salary. Look for credits that recur around the same date each month, from the same remitter, with narrations that indicate salary. Show the reviewer each credit counted, with its row, so they can see that a one-off transfer or a reimbursement was not included.
• EMIs and other obligations. Look for recurring debits of similar amounts, typically through NACH, ECS or standing instructions, and group them by payee. Match them against the obligations the borrower declared and the bureau report. An EMI on the statement that appears nowhere else is worth a question.
• Bounces. Identify return entries, such as cheque and NACH returns, and the charges that usually follow them. A return followed by a successful re-presentation tells a different story from repeated returns on the same mandate.
• Other patterns. Cash deposits just before the statement period ends, round-tripping between accounts, and large credits from individuals can all be listed with their rows for the reviewer to judge.

Every derived figure should link back to the rows that produced it. If the system says the average salary is a certain amount, one click should show the credits that were averaged.

What to do when a statement does not reconcile

Sometimes the balance chain breaks. The causes vary: a page is missing, two statements were merged, the bank's own format has a quirk, or the document was edited.

The wrong response is to analyse the statement anyway and hope the break does not matter. The right response is to stop and say where the chain broke, on which page, between which rows. Then a person decides what to do:

1. Check whether a page is missing or out of order, and ask for the complete statement if so.
2. Ask for a fresh copy straight from the bank, or fetch the data through the Account Aggregator framework, which moves financial data between institutions on the customer's instruction and consent.
3. If the break coincides with a suspicious change, such as a larger salary credit, treat the document as possibly altered and escalate under the lender's fraud policy.

A statement that does not reconcile should never feed figures into a credit decision without someone signing off on why.

This is how Parse, Inferova's document layer, reads statements: transaction by transaction, with the running balance checked line by line, and salary, EMIs, obligations and bounces worked out from the verified rows, each linked to its source.

If you would like to see your own statements read this way, you can request beta access at inferova.com/demo.

Sources