Missing transactions after a PDF to Excel conversion

Page boundaries

The most common place to lose a row is the top of a page. Statements repeat their column headers on each page, and a parser deciding what is a header and what is a transaction has to make that call from layout alone. Called wrongly, the first real row of each page is discarded as part of the header.

Check the first transaction on every page against the PDF. On a twelve-page statement that is twelve comparisons and it finds this immediately.

Wrapped descriptions

A long description wraps onto a second line with no date and no amount of its own. That continuation line has to be merged upward into the transaction above it. Treated as its own row it becomes a phantom transaction of zero; merged too eagerly, a genuine transaction that happens to be missing a date gets absorbed into its neighbour and disappears.

Where your row count is short by a few, look for descriptions in the PDF that run over two lines.

Rows that do not look like rows

• Reversals and corrections, often printed with different alignment or in a different weight.
• Fees bundled onto the same line as the transaction they relate to.
• Interest and charges in a separate block below the main table, which a parser reading only the table will not see.
• Foreign-currency transactions printed with two amounts, where the wrong one is taken or both are rejected.

Scanned pages

A scan has no text to read, so the transactions are transcribed from the image. Faint print, a skewed page, or a handwritten annotation across the table can cost a row. Where a statement is part digital and part scanned — a common shape when someone has photocopied one page — the scanned pages are where to look first.

How to catch it without checking every row

1. 1Compare the transaction count. Many statements print one; if yours does, it is the fastest check there is.
2. 2Compare the total credits and total debits against the printed totals.
3. 3Walk the running balance. A missing transaction breaks it at exactly the row where it should have been, which finds the row as well as the fact.
4. 4Spot-check the first row of every page.

The first three are arithmetic and take a minute. They are also the checks a converter can do for you — and a converter that does them will tell you which row is wrong rather than only that something is.

Subtotals and continuation lines

Statements that run over several pages often print a subtotal at the foot of each and repeat it at the head of the next, labelled brought forward or carried forward. These are not transactions, and a parser that treats them as such adds the running balance to itself once per page.

The symptom is the opposite of a missing row: the balance drifts further from the statement with every page. If your total is too large rather than too small, look at the page boundaries for this rather than for dropped rows.

What a converter cannot see

Some things are absent from the PDF itself, and no conversion will recover them. Pending transactions do not appear on a closed statement. Transactions on a page that was never scanned are not there to find. And a statement covering one account will not contain another account’s activity, however much the totals suggest something is missing.

Before assuming a conversion lost something, confirm it is present on the PDF. It sounds obvious; it is the first thing to rule out and the thing most often skipped.