Document intelligence: what it takes to read a bank statement reliably
Extracting values from a PDF is the easy half. Knowing when the extraction is wrong is what makes a pipeline usable.
By the Maple Crew team · · 5 min read
Modern models can read a scanned bank statement and return its transactions as structured data. Demonstrations of this are impressive, and they hide the real question. In production nobody asks whether the model can read a document. They ask how they will know when it read one wrong.
Step one: sort before you read
A customer file arrives as a pile: statements, payslips, an identity document, a tax notice, and a few things nobody asked for. A classifier assigns each file to a category first. Each category then gets its own extraction agent with its own schema. A reader that knows it is looking at a payslip makes far fewer mistakes than a general one.
Step two: copy, do not interpret
The extraction agent copies values as printed. It does not round, convert or guess. If a field is not on the page, the field stays empty and is flagged. Each value comes with a confidence level, and uncertain fields are marked for the analyst.
Step three: let the documents check each other
This is where reliability comes from. Documents in a file overlap, and every overlap is a free test:
- Opening balance plus credits minus debits should equal the closing balance.
- The closing balance of one month should be the opening balance of the next.
- The net salary on a payslip should appear on that month's statement.
- The name and employer should match across every document.
These controls are plain code, not AI. When one fails, either the extraction is wrong or the document is. Both are worth a human look, and the control tells the analyst exactly where to look.
Step four: make correction cheap and traceable
The analyst sees the original document next to the extracted values. Correcting a value takes a few seconds and requires a short reason. The original value is kept. Later, anyone reviewing the file can see what the machine read, what the person changed, and why.
The result
A pipeline built this way does not promise perfect reading. It promises that errors surface before anyone relies on them, which is the property you actually need. It also turns the analyst's job from typing figures into checking exceptions, and that is where the time saving comes from.
