Six structural causes of a folder-to-ledger discrepancy, in the order worth checking them — with the specific test for each.
A folder of supplier invoices totals differently from the ledger for the same period, and the difference is not a round figure that points at anything obvious.
The instinct is to treat this as one missing transaction and go looking for it. That instinct is what makes the search expensive, because the difference is almost never one large mistake. It is usually several small structural causes stacked together, some pushing the total up and some pulling it down, which is precisely why the residual is an untidy number that does not resemble anything in either record.
The cost of getting this wrong is not the reconciliation. It is that five of the six causes below are systematic — a duplicate channel, a tax convention, a cut-off rule, a sign convention. Each one recurs every period, unnoticed, for as long as the difference is plugged rather than diagnosed. The half-day someone spends hunting a phantom transaction is the visible cost. The invisible cost is a year of the same error compounding quietly behind a ledger that ties.
Here are the six, in the order worth checking, each with a test that either fires or does not.
01 · The same expense is in the folder twice
Where documents arrive through more than one channel — emailed PDFs, scanned paper, photographs — the same expense will eventually arrive through two of them. Nothing about the two files matches: different names, different dates received, one crisp and one photographed at an angle. Deduplication by filename or file hash cannot find them, because they genuinely are different files containing the same fact.
The check — group by supplier and amount with a few days’ tolerance on date, and review every group with more than one member. Match on the amount, not the filename.
02 · Something in the folder is not an invoice
A folder named for invoices collects whatever looks financially relevant: payment confirmations that restate a paid invoice, quotes and pro-formas for work that may never have happened, and occasionally a document from a different transaction entirely — a closing statement or loan schedule carrying a figure far larger than any invoice present.
The check — before summing, sort by amount descending and open the top ten documents. Anything an order of magnitude above a typical invoice deserves examination.
03 · Tax is handled differently on each side
Invoice totals usually include tax; ledger expense figures usually exclude it, because recoverable tax sits in its own account. Comparing a tax-inclusive folder total against a tax-exclusive ledger figure produces a difference of roughly the tax rate — frequently the entire discrepancy, hiding in plain sight.
The check — compute the difference as a percentage. If it lands near your tax rate, this is the cause.
04 · Cut-off — period boundaries differ
An invoice dated the 29th, received on the 3rd, entered on the 7th and paid on the 20th has four plausible dates, and four answers to which month it belongs in. The folder is organised by one of those dates and the ledger by another, shifting documents across the boundary in both directions.
The check — pull everything dated within a week either side of the boundary and compare individually. The discrepancy is usually a handful of documents.
05 · Credit notes counted as costs
A credit note is a negative invoice. It looks like an invoice and is filed with the invoices; if its sign is not read correctly it is added rather than subtracted, distorting the total by twice its value.
The check — search for “credit”, “refund” and “adjustment”, and confirm each entry is negative in the total.
06 · The label on the document is imprecise
A field marked as a total may be a pre-discount total. A figure beside a tax label may be a registration number. A “balance” may be a running account balance unrelated to the invoice. Extraction that reads by label alone produces plausible, incorrect data — which is why dependable processes validate arithmetic instead: subtotal plus tax must equal total, and line items must sum to subtotal.
The check — for a sample of invoices, verify subtotal + tax = total from the extracted figures. Failures identify the documents where a label misled the extraction.
Why the order matters
Work through them in sequence rather than jumping to whichever feels likely, because the causes interact and the interactions are what make an unsystematic search so slow.
Duplicates and non-invoices inflate the folder side. Credit notes counted positively inflate it further, by twice their value. Tax treatment inflates one side by roughly the tax rate. Cut-off moves documents in both directions at once. Two of these present together will partially cancel, leaving a residual that resembles neither, and someone hunting a single explanation will test each hypothesis against the net figure and reject all of them — including the correct ones.
Eliminating them in order removes that interference. After duplicates and non-invoices are cleared, what remains is a smaller and more legible difference, and the tax test in particular only works on a figure that has not been contaminated by the others.
The order as a checklist
Run against the folder, before comparing to anything:
- Group by supplier and amount, with a few days’ tolerance on date. Review every group of more than one. Match on content, never on filename or hash.
- Sort by amount descending and open the top ten. Anything an order of magnitude above a typical invoice is probably not an invoice.
- Search for “credit”, “refund”, “adjustment” and confirm each is carried negative.
- Recompute subtotal + tax = total on every document. Failures mark where a label misled the extraction, before any of those figures reach the ledger.
- Pull everything within a week of the period boundary and place each document deliberately.
- Express the remaining difference as a proportion of the ledger figure. Landing near the tax rate identifies the cause immediately.
Only then compare totals. Most of what looked like a reconciliation problem will have resolved as a document-handling problem, which is where it originated.
What should not happen
An adjustment on either side without knowing which cause produced it.
A reconciliation that balances because the difference was plugged is worse than one that does not balance, because it stops anybody looking. The mechanisms above do not stop when the ledger ties; they carry on, and the next period’s difference gets plugged too, and eventually the accumulated error is large enough that finding it means reconstructing a year.
Two of these causes are worth reading about separately, because they are the ones most often misdiagnosed: settling an ambiguous invoice date covers the cut-off case, and detecting duplicate invoices when receipts arrive as photographs covers the first.
Where the folder is too large to check by hand every month, that is the point at which running these checks mechanically justifies itself — the arithmetic does not tire on document four hundred, and it does not decide that this one is probably fine. That is what invoice data entry automation is for, and the same validation sits inside month-end close automation.
Questions this raises
How long should we spend on a difference before writing it off?
Long enough to know which of these causes produced it, which is usually far less time than firms spend hunting it unsystematically. The reason to care about a small difference is not its size — it is that most of these causes are systematic, so a small difference this period is often the visible edge of the same mechanism running across every period.
Is it ever acceptable to post a balancing adjustment?
Only once you know what it represents. An adjustment posted to make a reconciliation tie removes the single signal that something is wrong, and the underlying mechanism carries on. A documented adjustment with a known cause is fine; a plug is a decision to stop looking.
Which of the six causes is most common?
Duplicates and non-invoices account for most of the value in most sets, and tax treatment accounts for most of the rest. But the order matters less than the discipline of testing each one rather than pattern-matching on the size of the difference, which is what leads people to hunt a missing transaction that never existed.
Can these checks run before month end rather than after?
They are better run at intake, when the documents arrive, than at reconciliation. Every one of them is a property of the folder alone and needs no ledger comparison. Catching a duplicate or a credit note at intake costs minutes; catching it through a failed reconciliation costs the investigation as well.