Missing Transaction Detection Guide

This is the error people miss most, and the one with the highest cost. A duplicate you can usually spot by reading — there are two of something. A missing line is invisible, so the only honest test is the arithmetic.

How a missing transaction shows up in the balance

Every bank statement prints a running balance after each transaction. Apply each line in date order from the opening balance, and your total should equal the bank's figure at every row. When a transaction is missing, your running balance stops moving where the bank's did — so from that point your figure sits adrift by exactly the dropped amount. The direction of the gap tells you what's gone. If a *payment out* is missing, your balance is too high, because you never subtracted it. If a *deposit in* is missing, your balance is too low. The gap is constant: it appears at one row and holds steady for every row after. That flat, persistent offset is the signature of a single missing transaction — different from a duplicate (which overshoots) or a transposition (gap divisible by 9).

We reconciled a statement last year that looked perfect. Forty-eight rows, every figure plausible — and the closing balance was short by 2,300. The two columns agreed down to row 31, then split: a 2,300 transfer had never made it into the records. Nothing on the page hinted at it. The balance found it on the first pass.

Why transactions go missing in a PDF conversion

A lot of missing transactions don't come from human carelessness. They come from the conversion itself, when a statement is pulled out of a PDF, a scan, or a phone photo and turned into rows. Three patterns recur.

• Page-break clipping. The last transaction on a page often sits against the footer, or the first row of a new page tucks under a repeated header. Read column by column, that boundary row gets clipped — taken as header text, or skipped as whitespace — and isn't in the output. Multi-page statements lose lines at the seams more than anywhere else.
• Dropped rows in dense tables. Where two transactions share a date, or rows are packed tightly with no ruling lines, a parser can merge two into one or skip the one between. The page still looks complete; one line's worth of money has quietly vanished.
• Wrapped descriptions read as their own row. A long payee reference wraps onto a second visual line. A naive extractor treats the wrap as a new transaction with no amount, or shunts the real amount onto it and leaves the original line empty. Either way a genuine transaction loses its figure.

Copy-paste by hand adds a fourth: during a long manual transfer, it's easy to skip a row or drop the last line of a block. None of these announce themselves. The spreadsheet looks finished; only the balance disagrees.

How to detect a missing transaction, step by step

This is the order we'd actually work in — cheap checks first, the definitive one last.

1. Compare opening and closing balances first. Add every transaction you have to the printed opening balance and see whether you land on the printed closing balance. If you're short, money is missing somewhere in the period — you've confirmed the problem before hunting for the row.
2. Recompute the running balance row by row. Apply each line in date order from the opening figure. Mark the first row where your total stops matching the bank's printed balance. That row is the location; you don't need to inspect anything above it.
3. Read the size and direction of the gap. A gap equal to one transaction amount that then stays flat points to a single missing line. If your figure is *below* the bank's, a deposit is missing; if *above*, a payment out is missing. (A gap divisible by 9 is a transposition, not a missing line.)
4. Look at the page boundary nearest the gap. Find which PDF page the mismatch falls on, then check the last transaction on the previous page and the first on the next. Clipped boundary rows are the most common place a real transaction disappears.
5. Add the missing line from the source statement. Open the original PDF at the mismatch row, find the transaction the bank recorded that your records don't have, and key it in.
6. Re-run the balance to zero. If it now ties at every row through to the closing figure, you've found the one missing line. If a gap remains, there's a second issue — repeat from the new first-mismatch row.

When the gap doesn't behave like a single missing line

Not every shortfall is one dropped transaction. If the difference equals the opening balance, your brought-forward figure is wrong. If it's divisible by 9, suspect a transposed amount (54 keyed as 45). If your figure is *over* the bank's by one line, you're looking at a duplicate, not something missing — the guide on detecting duplicate transactions covers that. And if the gap shifts at more than one row, you've got several issues stacked: fix the first and re-run before judging the rest. The wider taxonomy lives in common reconciliation errors. Read the shape of the difference before the rows; it usually tells you what you're chasing.

Where a converter with a reconciliation check fits

Here's the honest workflow. Export Bank Statement converts the PDF — including scanned and photographed statements, via OCR — into clean Excel or CSV, which removes the page-break clipping and copy-paste slips that drop lines in the first place. What matters for missing transactions is what it does next: it runs the running-balance check, recomputing opening balance plus transactions against the printed closing balance and flagging any statement that doesn't reconcile. A dropped line breaks that check by its own amount, so the statement is flagged before you trust the numbers. There's no separate "missing-transaction button" — the gap surfaces because the balance won't tie, the same mechanism that catches duplicates and misread digits.

Getting it into your accounting software is convert, then import the CSV. The tool exports in the native bank-import format for Xero, QuickBooks, and Zoho Books, so the lines arrive as reconcilable statement lines. It does not push transactions through a live bank-feed API — that's a separate, certified integration — so treat it as a verified import file you bring in yourself. For the full method, see how to reconcile bank statements.

A quick worked example

A statement opens at 12,400 and closes at 10,150. Your records close at 12,450 — you're 2,300 *over*, which points to a missing payment out. Walking the running balance, your total agrees with the bank's down to a 2,300 outgoing transfer dated the 22nd, the last line on page two; below it, your figure stays 2,300 high to the end. The transfer was clipped at the page break. Add it back at the 22nd, re-run, and the balance ties to zero — the running balance told you the missing line lived at the page-two seam, so you didn't re-read fifty rows for it.