Counting the files answers a question nobody asked. Four independent checks that establish whether a set of statements actually covers the period, with no gaps.
Before any reconciliation can mean anything, one question has to be settled: does this set of statements cover the period continuously? It is almost always answered by counting the files, and counting the files is the one check that cannot establish it.
The reason to care is scheduling as much as accuracy. A gap discovered at intake is one email, sent on day one, naming exactly which period is missing. The same gap discovered when a reconciliation refuses to tie is an investigation, then an email, then a wait, then a resumption — with the close already in progress and the delay outside your control. The work is identical; only the position in the month has changed, and that is what turns a five-minute request into a lost week.
That pattern is why statement chasing consumes far more of a firm’s month than anyone books to it, as covered in where bank reconciliation hours actually go. Completeness is not really an accuracy problem. It is the thing standing between you and a predictable close.
Here are four checks that can settle it, in the order worth running them.
01 · The count, and why it is only a starting point
A count tells you whether the number of documents matches the number of periods expected. It is worth doing because it is free, and it catches the simple case where something was never collected at all.
It cannot catch the common case. Two independent naming faults — one file named for the wrong year, another saved as a second copy of a month already present — leave a folder with exactly the right number of files and a genuine hole in it. Each fault alone would show up in the count; together they cancel.
The check — count, but treat a matching count as “nothing obviously absent” rather than as completeness.
02 · The period printed inside each document
A file name is a claim made by whoever saved the file. The period is a property of the document, and every statement prints it on its face.
Reading the printed period and comparing it against the file name finds misnamed files immediately, and it converts the whole problem into the right shape: not “do we have twelve files” but “what range of dates do these documents actually cover”.
The check — extract the period from inside each document and list the set by that, not by filename. Any disagreement between the two is worth resolving before going further.
03 · Dates that join up
With real periods in hand, each one should begin where the previous ended.
One subtlety defeats a naive rule here, and it is worth knowing before you write it. Different account types join differently: for some, the next period opens on the same day the previous one closed, so the closing and opening dates are identical. For others, the next period opens on the following day. Demanding exact equality across a mixed set flags every document in it, which buries the one real break in noise and trains whoever reads the report to ignore it.
The check — require each period to open either on the previous closing date or the day after, and flag anything else. Allow the one-day step rather than special-casing account types.
04 · Balances that join up
This is the strongest check, and the one most often skipped.
Each statement’s closing balance should appear as the next statement’s opening balance. Where it does not, a period of activity is genuinely unaccounted for, and the size of the break tells you how much.
The reason to do this even after the dates check passes is that dates are metadata and balances are arithmetic. A break in the date chain leaves room to argue that a file was merely misnamed. A break in the balance chain cannot be argued with: money entered or left the account during a period you do not have a document for.
The check — carry each closing balance forward and compare it to the next opening balance. Report the difference where they disagree, rather than only that they do.
The trap that survives all four
A set can pass every check above and still not cover the year.
Where statement periods run to a fixed day of the month rather than to month end, a complete, continuous set of them begins after the financial year opened and ends before it closed. The days at each end are covered by no statement in the set. Nothing is missing and nothing is wrong — the set simply does not span what you assumed it spanned.
The check — state the range the set actually covers and compare it against the period you need. The correct output is not “complete” but “continuous, covering these dates”, with the uncovered days named.
Why this is worth automating
Every check here is mechanical, and every one is tedious enough that it gets skipped under time pressure — which is exactly when it matters. Running them costs seconds once written, produces a short report naming any break and its size, and turns an assumption into a stated fact at the top of the working papers.
Where a reconciliation later fails to balance, having already proved the source set continuous removes the largest and least tractable explanation from the search. That is worth more than it sounds: “a statement is missing” is the hypothesis that takes longest to eliminate by hand, and it is the one that gets tested last, after the cheaper explanations have been exhausted.
The four checks as a routine
Run at intake, on every client, before anything else begins:
- Count the files — free, and catches the case where a period was never collected. Treat a matching count as “nothing obviously absent”, never as completeness.
- Read the period printed inside each document and list the set by that rather than by filename. A filename is a claim; the printed period is a property of the document.
- Test that periods join — each opens on the previous closing date or the day after. Allow the one-day step rather than special-casing account types, or the report becomes noise.
- Carry each closing balance forward to the next opening balance, and report the size of any break. Dates are metadata and can be argued with; balances are arithmetic and cannot.
- State the range actually covered and compare it to the period you need. Name any uncovered days explicitly.
- Check account coverage against the ledger — every account referenced anywhere should have statements for every period in scope.
The output is one line per account: continuous from this date to this date, or a named break of a stated size. That line belongs at the top of the working papers, because it converts an assumption everyone was making into a fact somebody checked.
A note on what the checks are worth
None of this is sophisticated. Every step is something a competent person would do if they had the time, which is exactly the point — these are the checks that get skipped under deadline pressure, and deadline pressure is when a missing statement does the most damage.
The value of running them mechanically is not that a machine reads a balance better than a person. It is that a machine runs the check on the four hundredth document with the same attention as the first, and on the last day of the close as readily as the first. Consistency, not cleverness, is the thing being bought.
We build this as bank statement data extraction, with the continuity report produced at intake, and it feeds the exception list in month-end close automation.
Questions this raises
Does this matter if we use bank feeds?
It matters more, not less. A missing PDF is at least a visible absence in a folder; a feed that silently missed a period, started mid-month or dropped a closed account leaves nothing to notice. The balance continuity check is the one that catches it, because it tests arithmetic rather than the presence of a file.
When in the month should these checks run?
At the moment statements arrive, not at reconciliation. Everything here is a property of the statement set alone. Running it at intake means one accurate request to the client on day one naming exactly what is missing, instead of an intermittent chase that discovers the gap after the close has already started.
What is the difference between a set being complete and being continuous?
Continuous means there are no gaps between the statements you hold. Complete means the continuous range actually spans the period you need. A set can be perfectly continuous and still start after the year opened, which is the trap that survives every other check — so the honest output names the covered range rather than declaring completeness.
How do we handle accounts that were opened or closed mid-period?
They are the most common source of false alarms and of genuine gaps, and the same check handles both: the chain should start at account opening and end at closure, with those dates established from the documents rather than assumed. An account nobody remembered was opened is exactly what a coverage check against the ledger is for.