Missing rows are worse than wrong rows. A wrong number tends to break something visibly; an absent transaction just makes the totals a little smaller, and nothing about the spreadsheet looks incomplete. Whether you copied and pasted, used Excel’s own PDF import, or ran a converter, rows disappear in the same few places, and the checks that find them take minutes.
First, confirm it really is missing
Some things are absent from the PDF itself, and no conversion will recover them. Pending transactions do not appear on a closed statement. A transaction you remember may have posted on the first day of the next statement period. A page that was never scanned is 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, find the transaction on the PDF and note its page and position. It sounds obvious; it is the first thing to rule out and the thing most often skipped. Where it sits on the page is usually the explanation.
The only reliable defence is arithmetic: a conversion that counts the rows it read against the statement’s own totals can tell you something is missing, which reading the spreadsheet cannot.
Where rows go missing
| Where | What happens | Symptom |
|---|---|---|
| Top of each page | First row taken for part of the repeated header | Short by one row per page |
| Bottom of each page | Last row cut off with the footer or a subtotal | Short by one row per page |
| Wrapped descriptions | Undated row merged into its neighbour | Short by a few; one description looks too long |
| Separate sections | Fees, interest or payments in a block below the table | Short by a whole category |
| Scanned pages | Faint or skewed lines not recognised | Gaps clustered on certain pages |
| Copy and paste | Columns run together or a line is skipped | Rows with amounts in the description |
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. The bottom of the page fails the same way in reverse, when the last transaction is close enough to the footer to be cut off with it.
Check the first and last transaction on every page against the PDF. On a twelve-page statement that is twenty-four 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 printed without a date, as many statements do for the second and later items on the same day, gets absorbed into its neighbour and disappears.
Where your row count is short by a few, look for descriptions in the spreadsheet that are suspiciously long or contain a second amount. That is usually where a whole transaction went.
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.
- Credit card statements that split activity into sections, payments, purchases, fees and interest, each with its own heading and subtotal.
- Foreign-currency transactions printed with two amounts, where the wrong one is taken or both are rejected.
Copy and paste, and Excel’s own PDF import
Copying a table out of a PDF reader and pasting it into Excel is where many people start, and it fails in characteristic ways: a whole row lands in one cell, the debit and credit columns merge, a line that straddles a page is split or skipped, and page headers arrive in the middle of the data. None of that raises an error.
Excel for Microsoft 365 on Windows can also read PDFs through Data → Get Data → From File → From PDF. It finds tables page by page, so a statement usually arrives as one table per page, and a page whose layout differs, typically the first or the last, may be detected as a different table or not at all. Rows are lost when one of those tables is never loaded, which is easy to miss in a long list.
- 1Count the pages with transactions on the PDF.
- 2Count the tables or page blocks that reached your sheet.
- 3If they differ, find the missing page first; it accounts for many rows at once.
Scanned pages
A scan has no text to read, so the transactions are transcribed from the image by OCR. Faint print, a skewed page, a fold, or a handwritten note 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. A good scan at 300 dpi, straight and uncropped, removes most of the risk before conversion starts.
How to catch it without checking every row
- 1Compare the transaction count. Many statements print one; if yours does, it is the fastest check there is.
- 2Compare total credits and total debits against the printed totals. A shortfall on one side tells you which kind of row is missing.
- 3Check that opening balance plus credits minus debits equals the closing balance printed on the statement.
- 4Walk 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.
- 5Spot-check the first and last row of every page.
The first four are arithmetic and take a minute in a spreadsheet. 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. Arithmetic proves the numbers add up; it does not prove each description is right, so a quick read of anything flagged is still worth it.
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.
Before the data is used
- Do the count and the totals check before importing anything into accounting software. Removing rows after an import is harder than adding them before.
- Keep the PDF alongside the spreadsheet, so any row can be traced back to its page.
- Convert one statement period per file. A gap between two periods is easy to see; a gap inside a merged year is not.
- Check that each statement’s opening balance equals the previous statement’s closing balance. A mismatch means a missing statement, not a missing row.