Bank Statement Extraction, Benchmarked: 9 AI Systems on Real Lending Documents

Kita Capture is a document AI platform for lenders in emerging markets and underserved communities in the U.S. — places where a thin-file borrower’s bank statement is often the only credit history that exists. For these lenders, the useful question isn’t what the statement says line by line. It’s what the statement adds up to: the borrower’s average balance, their monthly inflow, their cash-buffer days. Those are the numbers an underwriting model runs on. So we built a benchmark that scores not just whether a system can read the page, but whether the numbers it calculates from the page can be trusted.

The result was sharper than we expected. On a clean page the frontier models look almost interchangeable — barely two points separate them on raw field accuracy. But reading every line correctly is not the same as getting the totals right: on dense statements the same models leave out transactions, and the figures they report come back wrong, sometimes by orders of magnitude. Only the Kita systems stayed accurate from the raw rows through to the final numbers. This post walks through the corpus, the methodology, the leaderboard, and the real failure cases.

62 real, de-identified consumer and SME bank and e-wallet statements, chosen to look like a production lending pipeline rather than a clean academic set: phone screenshots, scanned PDFs, multi-account statements, multilingual layouts, and European-style number formatting.

Every system gets the identical schema, document, and grader. Kita appears in two configurations — Kita, the production pipeline, and Kita Max, our highest-accuracy tier.

Every output is scored against a real answer key. PhD-level financial analysts hand-curated the correct schema and the ground-truth value of every field, and every output was graded by hand against that key. Nine systems, the same schema, the same documents, the same human graders.

1. 1

   Curate ground truth

   PhD-level financial analysts read every statement and hand-curate the correct schema and the true value of every field.

2. 2

   Extract

   All nine systems fill the identical schema on the same document. No tools, no hints. Invented fields are dropped; missing ones are null.

3. 3

   Hand-grade

   Human graders score every field of every output against the answer key. No model grades another model.

4. 4

   Check the math

   Every reported total, average, and balance is checked against the actual figure on the statement.

We start with the thing a lender actually decides on: the signals. Even when a system reads every transaction correctly, the totals it reports can still be wrong — total credits, total debits, average balance, and net cash flow coming back different from the actual figures on the statement. So every reported aggregate is checked against the true value, on every document. This is where the field falls apart.

Kita Max’s reported figures are right 99.3% of the time, and Kita’s 97.6%. The best LLM manages 83.5%; the parse-and-extract vendors fall to the high-60s. They read the statement, then report totals it doesn’t support.

What about raw reading? On field extraction the nine systems land within two points of each other, with Kita Max effectively tied for the top score. But this is the metric that flatters the frontier models most: it rewards transcribing a clean page and says nothing about whether the result is complete or the arithmetic holds up — and on dense statements, as we’ll see, the same models fall apart.

A model that reads perfectly but can’t be trusted to total a column is not a lending pipeline; it’s a very good transcriber. Kita Max gives up a tenth of a point of reading to the best frontier model and returns fifteen points of signal accuracy. That is the trade a lender wants.

The clearest way to see the problem is to take a single document and ask every system for one number a lender cares about: the average end-of-day balance. Here is a real bank statement (Security Bank) — 33 transactions, with a running-balance column printed on every row, so there is exactly one correct answer: ₱5,845.64.

Reported average end-of-day balance

Correct answer: ₱5,845.64

• Kita Max₱5,845.64
• Kita₱5,845.64
• Landing AI ADE₱5,900
• Claude Sonnet 4.6₱3,671.70
• GPT-5.5 (low)₱2,982.50
• Gemini 3 Flash₱1,127.81
• LlamaExtract₱5.00

Every system read the transactions correctly. Asked for the average of a column printed on the page, they returned answers spanning ₱5 to ₱5,900. Landing AI lands within 1% but is still off; the Kita systems compute the average in code from the extracted rows, so the reported figure matches the statement. Depending on the vendor, a lender pulling the “average balance” field would see this borrower as nearly broke or comfortably liquid — from the same statement.

The Security Bank case isn’t a one-off. Every system does two separate things: it reads the list of transactions, and it reports the aggregate signals — total inflow, average balance — alongside them. Even when the reading is perfect, the reported totals routinely aren’t. Here is a February bank statement from BPI: the total inflow each system reported, next to the actual figure.

Several of these systems read every transaction on this statement correctly, and the total they reported is still wrong — Landing AI 21× too high, Reducto ₱0.68M short, GPT-5.5 missing a ₱330k deposit. None of them is missing the data; they all read the deposits on the page. For a lender, the reported total is the input to the credit model, and three of these five feed it a number the statement doesn’t support.

Where everyone struggles: dense, multi-page statements

The hardest documents are dense Mexican multi-account statements. This BBVA statement runs 14 pages and about 209 transactions, and completeness fractured badly. The dangerous part: every system returned perfectly well-formed JSON. It just contained half, or a seventh, of the borrower’s actual activity.

Transactions extracted (true ≈ 209)

Silent under-extraction is the most dangerous failure mode in lending.

• Kita Max209 rows
• Kita209 rows
• Claude / Gemini 3 / Reducto209 rows
• GPT-5.5 (low)111 rows
• Gemini 2.5 Flash49 rows
• LlamaExtract29 rows

LlamaExtract dropped 86% of the borrower’s transactions and reported a tidy schema anyway. Every signal computed from those 29 rows is then confidently wrong. Kita and Kita Max captured all ~209.

When a deposit reads as a withdrawal

Reading a number correctly is only half of a transaction; the other half is its direction — money in or money out. Net cash flow, the single clearest measure of whether a borrower is accumulating or depleting, depends on classifying every row as a debit or a credit and then summing with the right sign. Systems got the amounts right and the direction wrong often enough to flip the answer outright:

Across the corpus, 28 net-cash-flow figures came back with the wrong sign. A sign flip turns a saver into a spender: to an underwriting model, a borrower with a healthy positive surplus instead reads as one bleeding cash — or the reverse, which is worse. Because the Kita systems classify debit-vs-credit deterministically from the statement’s columns rather than re-deciding it mid-computation, Kita got the direction wrong on just one statement in the 62-document corpus, and Kita Max on none.

Where Kita still has work to do

We hold ourselves to the same scrutiny. Kita’s lowest-scoring documents come from over-extraction, not the under-extraction that sinks others. On this SeaBank statement it pulled rows out of an “Interest & Tax Detail” sub-table and treated them as transactions. It’s the right kind of problem — extra signal to suppress rather than missing signal to invent — and the benchmark is doing its job by surfacing it. Kita Max’s table classifier already suppresses this sub-table correctly; that fix is now rolling into the production pipeline.

If you only benchmark whether a system reads a page, every modern model looks like a solved problem — they’re all 97%+. But “read the page” is not the job. For a lender, the job is asking: what is this borrower’s average balance, their net monthly cash flow, their minimum buffer? To produce those, a system has to read every transaction and do the arithmetic correctly and not contradict itself.

That last step is where the field falls apart. The frontier LLMs are extraordinary transcribers and unreliable accountants. The parse-and-extract vendors are strong on clean docs and dangerously inconsistent on dense ones. Across 62 statements and ~2,200 transactions, only the Kita systems reported totals that hold up against the statement more than 84% of the time — because the arithmetic is never delegated to a language model. Average end-of-day balance, net cash flow, buffer days, recurring income — the features underwriting actually runs on — are computed in code from the extracted rows, so they hold up.

See Kita on your own bank statements

The signals a lender underwrites on — average balance, net cash flow, buffer days, recurring income — are only as trustworthy as the arithmetic behind them. Kita Capture extracts every transaction and computes those signals in code, so the numbers reconcile to the statement. Run it on a sample of your own borrower files and check the totals yourself.

Frequently asked questions

Related reading

Kita · Benchmark report · June 2026