Reconciliation & review
The question BankStmt asks of every statement is not "did it look right" but "does it add up". This page explains how statements are read, what Completed means, and what to do with a statement that stays Incomplete.
How a statement is read
- Text PDFs are read deterministically from the page's own coordinates. No templates: the first statement from a new bank builds a profile for that bank, country and account type, and later statements reuse and refine it.
- Scans and photos go through OCR first, then the same structuring step.
- A language model is used only for pages the deterministic parser cannot structure. Its output is held to the same standard — it still has to reconcile before it is accepted.
- If the first pass does not reconcile, known-good parsing variants for that bank are tried automatically (date order, decimal separator), and the variant that reconciles is kept for next time.
Merchant names and categories are then applied: a built-in merchant registry and your own learned aliases and rules run first, and the model fills the gaps.
When a statement is Completed
A statement is marked Completed only when all of the following hold:
| Check | Rule |
|---|---|
| Balance equation | opening balance + credits − debits = printed closing balance |
| Printed totals | where the bank prints total debits and credits, the extracted sums match |
| Printed count | where the bank prints a transaction count, the extracted count matches |
| Running balances | every row's running balance follows from the previous row and its amount |
Where a check cannot be made — the bank prints no totals, say — it is skipped, not faked. A statement with no opening and closing balance can never be marked complete automatically.
If any check fails the statement is Incomplete, and its detail view names the failing checks and shows the balance-equation breakdown. Nothing is hidden: the transactions are in the app, flagged.
Reviewing an Incomplete statement
Open the statement's reconcile view. The left pane lists the rows; rows whose running balance does not reconcile are flagged red, with a count. Click a row and the right pane jumps to the exact line on the statement page (or the source line for a CSV or text file) and highlights it.
- Fix a misread figure in place. Amounts are signed — credits positive, debits negative — and the flag count falls as each row is corrected.
- Direction flips are repaired automatically. When a row's amount already matches the movement in the running balance but its credit/debit direction contradicts it, the direction is corrected from the balance column. Magnitudes are never guessed; a row whose amount and sign are both wrong stays flagged for you.
- Mark as complete when the source itself is inconsistent — a statement whose printed closing balance does not match its own ledger, for example. The override is recorded and the discrepancy stays visible; it is an honest note, not a way to make the numbers pass.
Duplicates and transfers
- Exact re-uploads are rejected and their pages refunded.
- Overlapping rows — bank exports overlap at period boundaries — are quarantined with evidence rather than added twice, and the statement still completes.
- Transfers between your own accounts are matched with evidence (ownership, reference, amount, date, currency) and a confidence. Confirm or reject each match; confirmed transfers are kept out of income and spending on every screen.
- Opening-balance lines stay visible in the transaction list but are flagged and never counted as income.
Integrity score
Separately from reconciliation, each statement receives an integrity score out of 100 with a LOW / MEDIUM / HIGH level, built from running-balance continuity, duplicated rows, round-number clustering, leading-digit distribution and future-dated postings. Every finding carries a count and example values. See Fraud.
Automated output can still be wrong. Reconciliation catches arithmetic, not intent — review figures before relying on them for filings or lending decisions.