A word doing more work than it can carry
In most organisations, "the bank is reconciled" functions as a general reassurance. It ends the conversation. It is what gets reported upward when someone asks whether the numbers are in order, and it is heard as a statement about the quality of the books as a whole.
It is not that statement. Reconciliation is a narrow and rather beautiful procedure that establishes one specific thing very firmly, and establishes nothing else at all. The gap between what it proves and what people hear is where a surprising number of problems live comfortably for years.
This is not an argument against reconciling. It is one of the highest-value controls available for the effort involved, and it should be done every period without exception. The argument is that knowing its precise scope tells you what still needs covering — which is a far more useful thing to know than a vague sense that the books have been checked.
What it does prove
Stated carefully, a completed reconciliation supports two claims. First, that the transactions you recorded, summed, carry the balance from the opening figure to the closing figure the bank printed. Second, that your record and the bank's record describe the same set of money movements for that account over that period, once genuine timing differences are listed.
Both are strong claims, and the first is a proof rather than an opinion. Arithmetic either holds or it does not; there is no judgement in it and no confidence interval around it. That is exactly why the procedure has survived unchanged for centuries while almost everything around it has been rebuilt.
It is also genuinely powerful against a whole class of failure. Invented transactions cannot survive it, because the bank has no matching movement. Rows lost in transit cannot survive it, because the sum falls short. Typing errors cannot survive it, because the total moves. Against mechanical failure, reconciliation is close to decisive.
The claim, stated exactly
Mapped onto the assertions
Auditors decompose "are these numbers right" into separate assertions, and the decomposition is useful well beyond audit because it makes the boundaries of any single procedure visible.
Existence — did the recorded transactions really happen? Reconciliation addresses this well. The bank is an independent party confirming the movement.
Completeness — is everything that happened recorded? Addressed within the period covered by the statement, and not at all beyond it. If a period is absent from both records, no comparison between them can reveal it.
Accuracy — are the amounts right? Addressed in aggregate. Individual amounts can still be wrong if the errors offset.
Classification — is each item in the right account? Not addressed at all. Reconciliation never reads the category.
Cut-off — is it in the right period? Partially, through timing items, and only for cash movements rather than for the underlying obligations.
Rights and obligations — should this money have moved at all? Not addressed. The bank confirms that it did move, which is a different question entirely.
| Assertion | Addressed by reconciliation? | Scope of the coverage |
|---|---|---|
| Existence | Yes, strongly | An independent party confirms the movement |
| Completeness | Partly | Within the statement's period only, never beyond it |
| Accuracy | Partly | In aggregate; offsetting errors survive |
| Classification | No | The category is never read |
| Cut-off | Partly | Cash movements via timing items, not obligations |
| Rights and obligations | No | Whether it should have moved is a different question |
Completely silent on category
A supplier payment of 3,400 coded to the wrong expense account reconciles perfectly. The date is right, the amount is right, the direction is right, the bank agrees. Every attribute the reconciliation examines is correct, and the one that is wrong is not one it reads.
This matters more than it first appears, because classification is where most of the consequential errors actually are. Deductibility, VAT treatment, capitalisation versus expense, which cost centre carries the charge, whether something is a cost of sale or an overhead — none of it touches the cash total, and all of it changes what the accounts say.
So classification needs its own review, and it looks nothing like a reconciliation. It reads categories rather than balances, and the useful techniques are comparative: this month against last, this supplier against its usual account, this class of cost against its expected proportion. Anomalies in category show up as pattern breaks, never as differences.
Silent on whether the document is genuine
A reconciliation compares your books to a document. It therefore inherits, completely, whatever that document says. Books built from a falsified statement will reconcile against that statement without a murmur, because the two records were constructed to agree.
Making a statement balance is the easy part of fabricating one. The arithmetic is mechanical, and anyone capable of producing a convincing document is capable of making the columns add up. So the balance holding is not evidence of authenticity; it is evidence that whoever produced the file was competent.
What actually addresses authenticity is provenance. Obtain the statement from the bank rather than from the party being examined. Use direct confirmation where the stakes justify it. Look at the file's own properties rather than only its contents. This is precisely why lenders and auditors care so much about how a document arrived, a preference that can seem like bureaucracy until you notice which assertion it is protecting.
Silent on the month that is missing from both sides
Reconciliation compares two records. If a period is absent from both, the comparison succeeds — there is nothing to disagree about. An entire month can be missing from a year while every individual month reconciles beautifully.
This is the largest hole the procedure leaves, and the cheapest one to close. The fix is a comparison of a different kind: each statement's closing balance against the next statement's opening balance, across the whole series. In an unbroken run they are identical every time, and the first disagreement is exactly where a period is unaccounted for.
It costs one comparison per document and is almost never done, because it feels too simple to be necessary. We gave it a whole article — the missing month problem — because the failure is so quiet and the test is so cheap.
Errors that cancel each other out
Two mistakes of equal size in opposite directions leave no trace in a reconciliation. An expense overstated by 500 alongside a receipt overstated by 500 produces a perfectly balanced account containing two wrong numbers.
There is no clever version of the reconciliation that catches this, because the procedure examines a net figure and the net figure is correct. It is not a matter of running the check more carefully; the information simply is not present in what the check looks at.
What surfaces compensating errors is examination of individual entries — sampling, review of unusual amounts, comparison against supporting documents. In other words, the thing reconciliation is often used to avoid doing. That is a reasonable trade for routine work, as long as nobody believes the trade is free.
Coverage at a glance
Everything above, condensed. The right-hand column is the useful one: it names what to run instead when the answer is no.
| Question | Does reconciliation answer it? | What does |
|---|---|---|
| Did these transactions really occur? | Yes — the bank confirms them | — |
| Is anything missing from this period? | Yes, within the statement's own range | — |
| Do the amounts total correctly? | Yes, in aggregate | Sampling, for individual entries |
| Is each item in the right account? | No — it never reads the category | Classification review, month-on-month comparison |
| Should this payment have been made? | No | Approval workflow, segregation of duties |
| Is the statement genuine? | No — it inherits the document | Source delivery, direct confirmation |
| Is a whole period missing? | No — absent from both records | Continuity of balances across the series |
| Are there two errors cancelling out? | No — the net is correct | Entry-level review and sampling |
| Is the VAT treatment right? | No | Tax review, separate from balancing |
The green tick problem
Accounting software presents reconciliation as a state — an account is reconciled or it is not, and the interface marks it with a symbol that reads as general approval. The software is not overclaiming, exactly. But a tick is a very broad signal for a very narrow proposition, and users reasonably read it as broader than it is.
The problem compounds when the tick is the last checkpoint in a workflow. Everything upstream — extraction, import, categorisation — gets treated as validated by the fact that the final step passed, even though the final step examined none of it. A category assigned wrongly upstream sails through, because the only thing tested downstream was a total.
A more honest interface would say what was compared and what was not. That is a design position we hold about our own product too, and it is why our checks report which specific rows a difference implicates rather than showing a verdict on the document as a whole.
Confidence is not proof, and the difference is not academic
Document-processing tools report confidence scores: this field was read with 98% certainty. Reconciliation reports a proof: this identity holds or it does not. Treating the two as the same currency causes real mistakes.
A confidence score is a model's estimate of its own reliability, and a model can be confidently wrong. High confidence on a misread amount is a completely ordinary occurrence, because the misreading and the confidence come from the same process. The score cannot step outside the model to check.
An arithmetic identity can. Opening balance plus every transaction against the printed closing balance is an external test: it uses information the reader did not generate, so it can contradict the reader. That is why we lean on the identity rather than on a percentage — not because scores are useless, but because only one of the two can catch the model being wrong.
It is also why a completeness check beats an accuracy claim. A tool can read everything it finds perfectly and still miss a tenth of the rows, and no per-field confidence will ever mention the rows that were never seen.
| A confidence score | An arithmetic identity | |
|---|---|---|
| What it is | A model's estimate of its own reliability | A test against information the model did not produce |
| Can it be confidently wrong? | Yes — routinely | No — it holds or it does not |
| Sees rows that were never read? | No | Yes — the sum falls short |
| Output | A percentage per field | A gap, in currency, and the rows implicated |
| Useful for | Ranking what to review first | Deciding whether the document is complete |
We will not promise you 99 % — we will show you which rows to check
Every converter in this market advertises a number: 99 %, 99.5 %, 99.8 %. None of them publishes how it was measured or on which documents — and none of them can tell you which rows fall in the remainder. That is the part you find out later, when two amounts have been glued into one, a column has slid one place to the left, and a reconciliation will not close.
Our extraction is strong. It is also not magic — and neither is anyone else’s.
Reading a PDF is not a solved problem. A layout nobody has seen before, a faded thermal receipt, a bank that marks credits in its own way — each of those can produce a row that looks perfectly ordinary and is wrong. We build hard against that, and we still refuse to sell you a number, because the number is not the thing that protects you. Knowing exactly where to look is.
What actually goes wrong when a PDF is read
These are not hypotheticals. Every one of them is a defect we have found in real documents, reproduced, and built a check for — which is precisely why we can now point at them instead of averaging them into a percentage.
| The defect | What you see in the export | What it costs |
|---|---|---|
| Two amounts glued into one | One plausible-looking figure instead of two rows | A total that is short by a whole transaction |
| A column slides one place | Dates in the description, amounts in the balance | Every row after it is wrong, and none looks wrong |
| A reference number read as the amount | “Payment 910015” booked as 831.00 | A five-figure hole on a long statement |
| A credit sign dropped | An expense recorded as income | The error is twice the amount, in the wrong direction |
| A summary box counted as bookings | “Previous balance / New balance” added as rows | Totals inflated by exactly the closing balance, twice |
| A page silently skipped | A month that is simply shorter | Nothing to see — that is what makes it the worst one |
So we built the layer that catches them
A second engine, deterministic — ours, and it runs on every document
After the AI reads the document, a separate layer re-does the document’s own arithmetic. Opening balance plus every transaction must equal the closing balance the bank printed. Each row’s running balance must follow from the one above it. Line items must sum to the invoice total. No AI, no confidence score, no guessing — these are proofs, and a document that fails one is provably misread.
It names the rows, not a percentage
When a check fails you do not get a lower score. You get row 48, row 133, row 1 902 — highlighted in place, red where a check proved the reading wrong and amber where it could not confirm it, with the column the check named brighter still. Open the Rows or JSON view, fix those, export. That is the whole loop, and it usually takes under a minute.
The document is the judge, not us
A bank statement carries its own proof: it can catch an error with no human, no reference data and no opinion from us. That is why we lead with it. Where a document genuinely cannot check itself — no running balance, no printed total — we say so, plainly, instead of letting silence imply that everything is fine.
Why the percentage is the wrong number to buy on
| Statement size | What “99 % accurate” quietly allows | What that means for you |
|---|---|---|
| 300 rows | 3 wrong rows | An afternoon — if you find them |
| 1 200 rows | 12 wrong rows | A reconciliation that will not close |
| 3 400 rows | 34 wrong rows | A six-figure error, in cases we have seen |
Money work rewards being picky
Please read the flagged rows before you export. That is not a disclaimer — it is the one step that turns a good extraction into a correct one, and we have spent our engineering effort on making it short and precisely targeted rather than on rounding a number up. Anyone can print 99 %. Telling you exactly where the other 1 % is, is the harder promise, and it is the one we are willing to make.
What to run alongside it
Four additions cover most of the gap, and none of them is expensive.
Continuity across the series. One comparison per statement. Closes the missing-period hole, which is the biggest one, for almost no effort.
A classification pass. Separate from balancing, and comparative rather than arithmetic: this month against last, this supplier against its usual account. Look for pattern breaks, not for differences.
Provenance discipline. Know how each statement arrived. Source-delivered documents and forwarded ones support very different conclusions, and it costs nothing to record which is which.
Sampling on entries. A small number of individual items checked against their supporting documents each period. It is the only thing that catches compensating errors and misclassification at the item level.
| Addition | Effort | Hole it closes |
|---|---|---|
| Continuity of balances across statements | One comparison per document | A period missing from both records |
| Classification review | An hour a month | Right amount, wrong account |
| Provenance discipline | Recorded at collection | Documents that cannot be relied on |
| Entry-level sampling | A handful of items | Compensating errors, unauthorised payments |
| Ageing reconciling items | Minutes | Timing items that quietly became errors |
How lenders and auditors actually read it
It is instructive that the parties with the most at stake rely on reconciliation least. A lender assessing an application does not ask whether the applicant's bank account reconciles. They read the statements directly, looking at continuity, pattern and plausibility, and they frequently want the documents delivered from the source rather than forwarded.
That is not distrust of the procedure. It is recognition that they are asking a different question — is this a true picture of the account — which reconciliation does not answer, because it compares a record to a document rather than testing the document.
Auditors use reconciliations as evidence, but as one input among several, and they test around it: direct bank confirmations, cut-off testing at the period boundary, examination of unusual items, and sampling of individual entries. The reconciliation supports existence; the other procedures cover the assertions it leaves untouched.
Both patterns point the same way. Reconciliation is a strong local proof embedded in a larger structure of evidence, and it was never designed to carry that structure by itself.
Where we stand on this
We build a converter, and the temptation in this category is to imply that a passing check means the document is correct. We try not to, and it shapes concrete decisions in the product.
When a statement covers more than one account, the totals identity cannot be evaluated — one opening and closing pair cannot span several running-balance chains. In that situation our check stands down and says it could not be run, rather than showing a tick. A check that reports success when it did not actually execute is worse than no check, because it manufactures confidence out of nothing.
When a document contains no total, we do not produce one. A spreadsheet carrying a sum that never appeared in the source is more dangerous than one without a sum, precisely because it looks authoritative. And when the identity fails, we report the gap and the rows worth examining rather than silently adjusting something to make it close.
None of that makes our reading infallible. It makes the failures visible, which is a different and more useful property — and it is the same argument this whole article makes about reconciliation itself.
Key takeaways
Reconciliation proves that the money moved as recorded: the transactions you have sum from opening to closing balance, and your record agrees with the bank's for that account and period. Within those limits it is a proof, not an estimate, and it is decisive against invented entries, lost rows and arithmetic errors.
It is structurally silent on classification, authorisation, document authenticity, periods absent from both records, and errors that cancel. Those are not gaps in how carefully you reconcile — they are outside what the procedure examines, and no amount of rigour in the procedure will reach them.
The useful response is not to trust reconciliation less, but to state its conclusion precisely and then name what covers the rest. Continuity across the series, a classification pass, provenance discipline and a little sampling close most of the distance for very little work.
Frequently asked questions
Checks that tell you what they checked
Every statement we convert is tested against its own arithmetic. When it holds, you know precisely what that means. When it does not, you get the gap and the rows worth examining — and when the test cannot run at all, we say so rather than showing a tick.