All posts

Why manual data entry ruins financial reconciliations (and how to catch PDF conversion errors)

5 November 2026

Keying a bank statement into accounting software is the most ordinary job on an accounts desk, and the one most likely to put a wrong figure in the books. Not because people are careless, but because the errors it makes are small, plausible and silent until the reconciliation refuses to balance weeks later.

The errors typing makes

• Transposed digits. 54.30 goes in as 45.30. Both look like real amounts.
• Slides. The decimal point moves, and 1,250.00 becomes 125.00.
• Missed rows. You look away, look back, and carry on one line lower. On a two hundred row statement, losing one line is easy.
• Rows keyed twice. The same slip in reverse, most often at a page break.
• Debit and credit swapped. The right amount on the wrong side, so the books are out by twice the amount.
• The wrong date. A payment on the 31st keyed on the 1st lands in the next month, and shows up as missing from one reconciliation and extra in the next.

Why they hide until reconciliation

Each of these looks fine on its own. The ledger accepts any number you give it. The keyed total quietly drifts away from the bank's, and nobody compares the two until month end, or until the auditor does at year end. By then, finding one wrong row among hundreds means going back through all of them, and that is where the hours go: an afternoon spent hunting a difference of 9.00.

The old tricks for finding them

• If the difference divides exactly by 9, suspect a transposition or a slide.
• If halving the difference gives an amount on the statement, suspect a debit keyed as a credit, or the other way round.
• If the difference equals an amount on the statement, suspect a missed row or a doubled one.

They are good tricks. But they tell you what kind of mistake you are looking for, not where it is.

A converted statement is not automatically right either

Converting the PDF instead of typing it removes the typing, and with it most of the mistakes above. It does not remove the chance of a misread. A converter can lose a faint decimal point, drop a line or read a 3 as an 8, especially on a scan. One that hands you rows without checking them has only moved the error from your fingers to the software. So check a conversion the way you would check a colleague's keying.

How to catch PDF conversion errors

1. The running balance, on every row. The balance on the line before, plus or minus this amount, has to equal this line's balance. A misread amount or a missing row breaks that chain at the exact row where it happens. Parserje runs this test on every row and records the result in the Check column of the workbook.
2. The closing balance. The last balance in the file against the ending balance printed on the statement. If those agree, nothing has gone missing, because a row cannot disappear without taking its balance with it.
3. The printed totals. Many statements print a total debit and a total credit. The converted rows have to add up to them. Parserje checks each statement against its own printed totals where the bank prints them.
4. The flagged rows. A flag marks a row the converter was unsure of. Look at those few rows against the PDF, not at all two hundred.
5. Overlapping statements. When two PDFs cover some of the same dates, the same rows turn up twice. Parserje keeps each once and lists the ones it removed on a Duplicates Removed sheet, so you can see exactly what went.

Then check what you keyed

Once the month is in your accounting software, export it back out to Excel and compare it with the Parserje workbook: the same number of rows, the same total debit, the same total credit. Three numbers, and the month is either whole or it is not. The full routine is in using the file with AutoCount, Bukku and Excel.

If you have not converted a statement yet, start with how to convert a bank statement PDF to Excel.