Three parsers. One statement. Three different transaction totals. Each tool returned its output with a clean success status — no errors, no warnings, no indication that anything had gone wrong.
That's the failure mode that doesn't announce itself. The parser doesn't crash. There's no exception to catch. The data just comes back wrong, quietly, and then flows into whatever system is downstream — a loan model, an accounting ledger, a forensic audit — where it gets treated as ground truth.
That test is why stmtly exists. And it's why we built a math engine instead of another AI wrapper.
What we were actually trying to solve
The obvious framing for a product like this is speed. "Automate your bank statement processing. Save hours." That framing is fine as far as it goes, but it misses what actually matters.
Faster wrong answers are useless. Worse — they're dangerous. Financial data extracted from PDFs doesn't get re-verified downstream. Once it's in the accounting system, it's assumed correct. Nobody checks the parser's work. The data just becomes part of the record.
So the real problem isn't throughput. It's the trust gap: the space between "the parser ran successfully" and "the data is actually correct." That gap is where professional liability lives. It's where a misread decimal in a loan underwriting model becomes somebody's problem six months later.
A parser that's 98% accurate on a statement with 200 transactions produces, on average, 4 wrong entries. In a spreadsheet, that's a minor annoyance. In a forensic audit, it's a liability.
Closing that gap was the actual design problem. Speed was secondary.
Why we looked at AI first — and what we found
We weren't anti-AI from the start. The obvious architecture was an LLM — they handle messy layouts, infer context, and get bank statement structure right most of the time. So we tested them seriously.
LLMs read statements the way a smart person does
Contextually. Impressionistically. They infer that a number in a certain column position is probably a debit. They recognize that a negative sign usually means an expense. For clean, well-formatted PDFs from major banks, accuracy is high.
High accuracy compounds badly at scale
At 500 documents a month, a 98% accuracy rate means 10 documents with errors — errors that look identical to correct outputs because the parser doesn't know it made them. At 5,000 documents, it's 100. The user has no way to know which outputs to trust and which to verify, so they either check everything (defeating the point of automation) or check nothing (accepting systematic risk).
The deeper problem: no concept of financial proof
This is what actually closed the door on pure AI parsing for us. An LLM has no native understanding that a bank statement must balance. It doesn't know that opening balance + all transactions = closing balance. It can't verify its output against the document's own arithmetic. When it gets something wrong, it gets it wrong silently — with the same confidence it gets things right.
AI / LLM Parser
Infers debit/credit from context and position. High accuracy on clean PDFs. No internal verification. Errors are silent — every output looks the same.
Math Engine
Proves debit/credit by testing every sign combination against printed running balances. Errors are detected and flagged. Output includes a verifiable valid status.
Silent errors were a non-starter. We needed a system that could tell the difference between a correct parse and an incorrect one — not as an afterthought, but as a core design constraint.
The insight that changed the approach
A bank statement isn't a document to be read. It's a mathematical proof to be verified.
Every legitimate bank statement has a property that almost no other document type has: it must balance to the penny. Opening balance, plus every transaction with the correct sign applied, equals the closing balance. That's not a convention or a best practice — it's how the document works. The bank's printed totals are an audit trail embedded directly in the PDF.
That property is a gift to a parser, if you're willing to use it.
Instead of asking "what does this text mean," you can ask "what is the only mathematical arrangement of these numbers that satisfies the document's own constraints?" That question has a provable answer. And it has a detectable failure mode: if no arrangement satisfies the constraints, the output is flagged — not guessed, not approximated. Flagged.
The math either closes or it doesn't. That's a harder standard than "the AI feels confident about this" — and for professional financial data, it's the right one.
What a math engine actually does differently
It reads position, not meaning
Every token on a bank statement PDF gets mapped to an X-Y coordinate grid. Column assignments — date, description, debit, credit, running balance — are reconstructed from where numbers appear spatially, not from what they say. A Chase statement and a Bank of America statement have completely different layouts. To a spatial parser, both are geometry problems. The approach is the same; the column coordinates are different.
It proves signs, not guesses them
Whether a transaction is a debit or credit isn't determined by keyword matching or column position alone. The engine groups transactions into chunks between consecutive printed running balances, then tests every possible combination of positive and negative signs for the amounts in that chunk. One combination produces the correct next balance. That's the answer — not the most likely answer, the only answer that works.
It knows when it fails
The final output includes a valid flag. If the reconstructed ledger matches the statement's opening and closing balances to the penny, it's valid: true. If it doesn't, it's valid: false — and the user knows, before the data goes anywhere, that this document needs review.
// Example validation output
{
"bank": "Chase",
"period": "2024-03",
"transactions": [ ... ],
"validation": {
"opening_balance": 12400.00,
"closing_balance": 9873.41,
"computed_balance": 9873.41,
"delta": 0.00,
"valid": true
}
}
// When something's wrong, you know immediately
"validation": {
"computed_balance": 9831.00,
"delta": -42.41,
"valid": false,
"error": "math_drift_detected"
}
The tradeoff we made — and why it was worth it
Honest caveat
The math engine is narrower than an LLM. It won't summarize a document, answer questions about it, or handle arbitrary financial document types. It does one thing: extract transaction data from bank statement PDFs with mathematical certainty.
For most document processing use cases, that narrowness is a weakness. For this specific use case — financial data that feeds professional workflows — it's the point.
The market has plenty of AI-powered document tools that do many things reasonably well. It has very few tools that do one thing and can prove they did it correctly. We made a deliberate choice to be the latter.
Precision instruments are less exciting to demo than general-purpose AI. They're also the tools that professionals actually rely on when the stakes are real.
What this means for the people using it
The practical outcome of a math engine is a workflow that wasn't possible before: automate 95% of your statement processing and know, with confidence, which 5% needs human review — not because you randomly sampled outputs and got lucky, but because the tool tells you.
For forensic accountants, that means not auditing every automated output hoping to catch errors. The flagged documents are the ones with errors. Review those. Trust the rest.
For lenders, it means bank statement data that enters the underwriting model has been verified against the bank's own printed totals — not parsed by a model that was confident but couldn't check its work.
For bookkeepers processing high volumes, it means a predictable, bounded manual review load instead of a vague sense of unease about whether the automation is getting it right.
That's not a feature. That's the difference between a tool you can build a professional process around and one you use for drafts.
The AI wave has made it easy to build tools that appear to understand financial documents. The harder problem — less glamorous, less fundable, less tweetable — is building tools that can prove they got it right.
That's the problem we chose. Not because AI parsing is wrong. Because for data that professionals stake their reputation on, "probably correct" isn't a standard you can build on. The math either closes or it doesn't.