"AI-powered bank statement conversion" is doing a lot of work in a lot of marketing copy right now, including some of ours. This piece is an attempt to say precisely what happens, which parts are reliable, and which parts are the reason a person still signs off at the end.
The pipeline, honestly
There are four distinct stages, and only two of them involve a language model at all.
Stage 1 — OCR
If the statement is a scanned image, something has to turn pixels into characters first. This is document-intelligence OCR, a mature and unglamorous technology. It is very good on clean scans and degrades predictably on bad ones — skewed pages, fax-quality reproductions, a phone photo taken at an angle. If your input is a native digital PDF from online banking, this stage is trivial and near-perfect.
Stage 2 — Extraction
Turning a page of text into structured rows: date, posted date, check number, description, amount, and whether it is a debit or a credit. This is the stage where a language model earns its place, because bank statement layouts are wildly inconsistent and rule-based parsers break on every new institution.
It is also where the interesting engineering problems live. Long statements are the main one. A statement with 400 transactions produces a large response, and a naive implementation with a fixed request timeout simply fails past a few hundred rows — which is exactly the point at which manual entry hurts most. The fix is streaming: extract incrementally, report progress as it goes, and give the operation a generous ceiling rather than a fixed short timeout.
Stage 3 — Reconciliation
Pure arithmetic, no AI. Beginning balance plus deposits minus deductions should equal the ending balance for a bank account. For a credit card the signs flip: previous balance plus charges minus payments equals the new balance.
This stage is the quality gate for the one before it, and it is the most valuable part of the whole system. If extraction misses a transaction or misreads an amount, the statement will not balance, and you find out immediately rather than three months later during a review. A well-built converter refuses to accept an out-of-balance statement at all.
Why reconciliation matters more than extraction accuracy
An extractor that is 99% accurate with no reconciliation check is more dangerous than one that is 95% accurate with a check that catches every discrepancy. The first quietly produces wrong books. The second stops and tells you.
Stage 4 — Categorization
Mapping each transaction to an account in that client's Chart of Accounts. This is where most of the perceived "intelligence" lives, and where the design decision that matters most is how little of it you hand to the model.
A sensible hierarchy tries the cheap deterministic options first:
- A memorized payee rule. If you taught the system last month that "SQ *BLUE RIDGE SUPPLY" is Materials for this client, that is the answer. No model call, no cost, no variance.
- An exact account match. The cleaned payee name matches an account name exactly.
- A fuzzy match. Close enough to an account name to be confident.
- An AI suggestion. Only now, and only from this client's own Chart of Accounts — never from a general notion of what a landscaping business might spend money on.
Most transactions on a recurring client never reach the fourth tier after the first month or two. That is the intended behavior: the system should be getting cheaper and more deterministic over time as it learns your clients, not calling a model on every row forever.
What it reliably gets right
- Structure. Finding the transaction table, distinguishing it from the summary and the fine print, handling multi-page statements with repeated headers.
- Dates and amounts on legible input. Near-perfect on native PDFs.
- Debit versus credit, including the sign inversion on credit card statements — which trips up a surprising number of simpler tools.
- Recurring payees. Once the rule exists, forever, at zero marginal cost.
- Consistency. It does not get tired at 9pm in March, which is not nothing.
The four cases worth knowing about
Ambiguous payees
"AMAZON.COM" could be office supplies, equipment, a software subscription or an owner's personal purchase that should not be in the business books at all. No model can resolve this from the statement line, because the information required is not on the statement — no tool, and no person, can read it off that row. This is exactly what the low-confidence band exists to surface: it lands in front of the one person who does know.
Bad scans
A 6 misread as an 8 in an amount produces a statement that does not reconcile, which is the good outcome — you get told. A misread in a description produces a miscategorization, which is the quieter failure. Both argue for pulling statements from online banking as native PDFs wherever possible.
Unusual statement types
Brokerage statements, loan statements and merchant processor settlements do not follow the bank or credit-card arithmetic. A system that tries to force them into one of those two shapes will produce confident nonsense; a system that admits it does not know the type and asks the operator to confirm totals manually is behaving correctly.
Transactions that simply are not there
A row lost in a page break is invisible to any check except reconciliation — which is, again, why reconciliation is the load-bearing part. When it happens, you need a way to add the missing transaction by hand and have the batch re-reconcile immediately.
Confidence bands, and why they should be visible
Any categorization engine has an internal confidence value. Hiding it is a choice, and it is the wrong one, because it forces the operator to review everything or trust everything. Exposing it in bands lets them do neither:
- Auto — above roughly 95%. Spot-check, do not review line by line.
- Suggested — 80 to 94%. Worth a look; usually right.
- Unknown — below 80%. Must be categorized by a person.
On a typical 180-transaction statement for an established client, that might be 170 auto, 8 suggested and 2 unknown. Ten rows of real attention instead of 180 rows of data entry — but ten rows of real attention, not zero.
Ten minutes against thirty-five
That is the real number, and it is worth stating precisely: a converted statement costs about ten minutes — confirm the reconciliation, resolve the unknowns, spot-check the suggested band, accept. Thirty-five minutes of keying becomes ten minutes of judgment.
It is the difference between a bookkeeper handling twenty clients and handling sixty. Treat any tool promising zero review time with suspicion: it is either not reconciling or not showing you its confidence, and both of those surface later, in front of a client.
What actually leaves your tenant
A fair question, and the answer should be short. In Kveldo: account numbers are masked before anything is transmitted, only extracted transaction text and account names are sent — not full client PII — and every call is logged with surface, model, token count and cost. AI output is a suggestion requiring staff approval; it is never treated as source-of-truth data.
See the conversion workflow →
Read next: getting a clean QuickBooks import →