The statement is worth its lines, not its balance.

A lender asks for three months of bank statements. The file arrives, the extraction runs, and the first check passes: opening balance plus deposits minus withdrawals equals the closing balance on every page. The statement is marked as parsed and moves on. A week later an analyst notices that one of the largest deposits in March was a transfer from the applicant's own savings account, and that two payroll deposits were followed by a returned item three days later. The balance check was right. It just never looked at what the money was.

That gap is the subject of this article. A reconciling balance tells you the arithmetic on the page holds. The questions a credit, onboarding or finance team actually asks are about individual lines: which deposits recur, which payments are obligations, and which movements cancel each other out. Those answers only exist once every transaction is extracted and classified on its own.

The balance check is necessary, and it proves very little

Checking that opening balance plus movements equals the closing balance is worth doing on every statement, because it catches dropped rows, misread amounts and missing pages. It is also satisfied by any statement whose numbers were written to add up, including a fully synthetic one, which is why the generative fraud article treats a reconciling balance as the starting point for authenticity checks rather than as evidence. On a long statement split into parts, the same identity becomes the seam check described in the deep split article. Keep it as a gate, and do not read a pass as an answer to anything else.

The questions live in the lines

Take the three questions that recur across lending, tenant screening and merchant onboarding. None of them can be answered from a total.

• Recurring income — how much comes in on a predictable cadence from the same source, as opposed to a one-off deposit that happens to fall inside the window.
• Recurring obligations — which outgoing payments repeat on a schedule, such as rent, loan repayments and subscriptions, and therefore already commit part of that income.
• Returns and reversals — which movements were undone later, so that a deposit and its return are not counted as income on one side and spending on the other.

Total deposits for the month can be identical for two applicants with very different answers to all three. One has a steady salary and a rent payment. The other has a large transfer from another account, a refund from a cancelled purchase and a returned payment. The summary fields match, while the lines tell different stories.

What a transaction line has to carry

Classification is only as good as the line it starts from. Before any rule can decide what a transaction means, each row needs to arrive as a structured record rather than a string of text. On the bank statement extraction page, Cogneris describes returning every transaction with a confidence score, a source page reference and a bounding box, with multi-page statements stitched into one logical document so that transaction continuity survives page breaks.

In practice a useful line record contains:

• Posting date — normalized, so that cadence can be measured across statements from different banks.
• Description — the raw descriptor as printed, kept alongside any normalized counterparty name.
• Signed amount — direction made explicit, rather than inferred from which column the number sat in.
• Category — the platform infers deposit, withdrawal, ACH, wire, fee and interest from the descriptor.
• Evidence — confidence, page and bounding box, so a reviewer can open the exact row behind a decision.

The last item matters more than it looks. When an analyst disputes a classification, the conversation should end at a highlighted row on a page image, not at a spreadsheet cell whose origin nobody can trace. The bank statement converter exports the same transactions as JSON or CSV, but the page reference is what makes an export reviewable.

Recurring income is a pattern, not a label

No single line is "recurring". A deposit becomes recurring income only in relation to other deposits, so the classification has to run across the whole window rather than row by row. Three properties do most of the work:

• Same source — the descriptor, once normalized, points to the same payer. Payroll descriptors often carry batch numbers or dates that must be stripped before two deposits look alike.
• Regular cadence — the intervals between deposits cluster around weekly, biweekly, semi-monthly or monthly, with a tolerance for weekends and bank holidays.
• Stable amount — amounts stay within a band you define, because overtime, commissions and tax changes move a salary without changing what it is.

Two exclusions are just as important. A transfer between accounts held by the same person is money moving, not money arriving, and it should be separated before any income figure is computed. A deposit that is later returned should not count at all. Both are common enough that an income number computed without them is usually too high.

Write the tolerances down. "Monthly, within three days, amount within 15 percent of the median" is a rule someone can review and change. A model that silently decides what "recurring" means is a rule nobody can audit, and the first disputed decision will expose that.

Obligations are recurring too, and harder to name

Outgoing payments follow the same logic with messier descriptors. A rent payment might appear as a transfer to an individual, a property management company or a payment app. A loan repayment might carry the lender's name, a servicer's name or an abbreviation of either. Subscriptions change descriptors when the merchant changes payment processors.

Cadence is therefore the stronger signal for obligations, and the counterparty name is supporting evidence. A payment of a similar amount leaving on a similar day each month is a candidate obligation even when the descriptor is unfamiliar. The classification should say so explicitly, with the lines that formed the pattern, rather than guessing a category name from an abbreviation.

Fees deserve their own treatment. Overdraft and returned-item fees are short, frequent and easy to lose inside total withdrawals, yet they describe how the account behaves. The sample output on the extraction page includes an nsf_count field for exactly this reason: a count is easier to act on than a fee buried among forty other debits.

Returns and reversals have to be paired

A reversal is two lines that describe one event. A payment is made and then returned. A deposit arrives and then bounces. A purchase is refunded. If the pair is not recognized, the statement overstates both income and spending, and the net effect on the balance hides the problem entirely, because the two lines cancel out in the arithmetic.

Pairing works on amount, counterparty and proximity in time, supported by descriptor keywords such as return, reversal or refund when the bank prints them. The output should link the two lines rather than delete either, so that a reviewer can see what happened and a later model can decide how to treat it. A returned incoming payment shortly after a deposit is not just a correction. For a lender it may be one of the more informative lines on the statement.

Make one statement concrete

Consider six lines from a single month, and how each is classified once the whole window is visible:

Every line reconciles, and the balance identity holds. The deposits for these rows total 6,270.00, but the recurring income they support is 2,450.00 per pay period. The rest is a transfer the applicant already owned and a deposit that did not clear. None of that is visible from the summary block at the top of the statement.

Confidence belongs to the line, not the statement

A statement-level confidence score hides where the doubt is. A 47-transaction statement can be read almost perfectly except for one smudged amount on page three, and that one amount might be the largest deposit of the month. A single score for the whole document either approves the error or sends 46 good lines to manual review along with it.

Line-level confidence lets the workflow route precisely. Lines above your threshold flow into classification. Lines below it go to a reviewer with the bounding box already highlighted. The converter page lists low-confidence line items among its validation checks, alongside balance math, duplicate pages and date ranges, and those checks are most useful when each one points to a specific row or page rather than failing the whole file.

Apply the same discipline to classifications. An income pattern built from three high-confidence deposits is stronger than one built from three deposits where one amount was uncertain. Carry the weakest line's confidence into the pattern, so that the decision downstream knows how solid its input was.

What extraction does not decide

Classifying lines produces evidence. It does not produce a credit decision, and it should not pretend to. How much recurring income is enough, how obligations are weighed and how a returned item affects an application are policy questions that belong to the lender, the screening provider or the finance team. Extraction makes those policies applicable to real statements. It does not choose them.

It also does not settle whether the statement is genuine. A fabricated statement can contain a plausible payroll pattern and a plausible rent payment, exactly because the person who generated it understood what reviewers look for. Authenticity checks are a separate layer with separate signals. The fraud article covers that layer, and the line-level record described here is one of its inputs rather than a substitute for it.

Before you wire statements into a decision

Five checks turn a parsed statement into evidence a team can act on:

• Gate on the balance — reject or review statements whose identity fails, and treat a pass as a precondition only.
• Extract every line with evidence — date, descriptor, signed amount, category, confidence, page and bounding box.
• Write the pattern rules down — cadence, amount band and source matching for income and obligations, owned by a named person.
• Pair before you total — separate own-account transfers and link returns and reversals before any income figure is computed.
• Route by line — send low-confidence rows to review with the page region attached, instead of approving or rejecting the whole statement.

A statement that adds up is a good start. The value for everyone downstream is in knowing, line by line, what the money was and how sure the extraction is about each row.