What is the problem?
Reading a bank statement PDF with a language model is easy to demonstrate and hard to trust. The model returns rows. Most of them are right. In accounting, “most” is a failed job: one wrong amount means the books do not tie, and somebody spends an evening finding it.
What is the rule?
A bank statement prints its own numbers: the opening balance, the closing balance, and usually total deposits and total withdrawals. Those numbers are on the document. They are not our numbers.
So the rows pulled from a statement are trusted only when they agree with the numbers printed on that same document, to the cent:
- The gate is the balance. Opening balance plus deposits minus withdrawals must equal the printed closing balance, exactly.
- The printed totals are a second check. The deposit rows should add up to the printed total of deposits, and the withdrawal rows to the printed total of withdrawals. If they disagree, a person looks.
Off by one cent, and the statement is not verified. There is no “close enough”, and there is no confidence score. A confidence score is the model grading itself.
Where is the model, and where is it not?
For most statements the model has a small job. The first time a statement layout is seen, it works out how to read it: which column is the date, where the amount sits, how the sections are split. That reader is saved.
Next month the same statement’s rows are read by plain code replaying the saved reader. When a bank changes its layout and the footing check fails, the model is asked to repair the reader, and the repaired reader has to pass the same check. On this path the row amounts are not taken from a model’s answer. They are pulled from the document by plain code.
There is one exception, and it is better said plainly. For a bank whose layout no reader can be built for, the model reads the rows itself. The same check then runs on what it read. If the rows tie to the document, they are verified. If they do not, they are marked unverified and wait for a person.
Why not ask the model to be careful?
Because you cannot audit care. You can audit arithmetic. When the rows foot to the document’s own numbers, you have a proof that does not depend on which model was used. When they do not foot, you know before the number is in a ledger, which is the only cheap moment to know.
What does it cost?
Statements that print no totals are harder, and some scanned statements never foot. Those are marked unverified, and a person sees why. That makes a worse demonstration and a better month-end.
Where does this run?
This check is part of LedgerDock’s statement import. Reading a statement never posts anything by itself: the lines go to review, and a commit cannot be finalized into the books until its total ties to the statement. The one way past that is a person recording the difference with a written reason, which is sealed with the commit. You can watch it in the Import a statement tutorial, and read what happens next in how a close works.