How Accountants Verify Imported Transactions

Verifying transactions is not the same as importing them. Plenty of imports look clean and aren't. A line read as 180 instead of 150 will sit there quietly until something downstream refuses to tie out.

Verification versus a tidy-looking import

A transaction that imported without an error message has not been verified. The software accepted the row; it didn't check the row against reality. Those are different events, and conflating them is where most rework starts.

Verification answers a narrower, more useful question: does each imported line still say what the bank statement says? Same amount, same direction, same date, same counterparty. An import can succeed in full and still carry a handful of lines that drifted during conversion. We've opened spreadsheets that balanced perfectly and still had a supplier payment dated a day late, which threw a VAT quarter out by one transaction. The maths was fine. The data wasn't.

So the job has two halves. The running balance proves the set is complete and the totals are right. Sampling proves the individual lines are right. You need both, because each is blind to what the other catches.

Step one: run the balance check as the first line of verification

Before anyone looks at a single transaction by eye, recompute the running balance. Take the opening figure printed on the statement, apply each credit and debit in date order, and confirm your total matches the bank's balance column at every row. The first row where your number and the bank's diverge is the exact location of the error — a missing line throws everything below it out by the same amount, a misread figure throws everything below it out by the difference.

This is why the balance check earns its place at the front. It's the only test that catches an entry that isn't there. You can eyeball a list of two hundred transactions and never notice the one payment that dropped off a page break, because there's nothing on screen to draw your eye to an absence. The running balance flags it on the first pass. We've reconciled a statement that looked immaculate until row 58, where a 4,100 transfer had quietly gone missing — sampling alone would probably have skipped right over it.

A quick read of the gap tells you what you're chasing. A difference divisible by 9 usually means a transposition (54 keyed as 45). A difference equal to one transaction amount means a line is missing or duplicated. A difference equal to your opening figure means the brought-forward balance is wrong. You often know the type of error before you've found the row.

If the statement reconciles, you've cleared the completeness and totals hurdle in one move. Now you sample.

Step two: sample and spot-check individual lines

The errors that survive a balance check are the ones that net to the right number. A duplicated 120 line paired with a 120 amount sitting in the wrong column will still total correctly. A misclassified transfer, a garbled description, a date one day out — none of these break the running balance, and all of them matter. Sampling is how you find them.

Here's the method that works in practice, without checking all two hundred lines:

1. Always check the anchors. Verify the opening balance, the closing balance, and the first and last transaction of the period by hand, every time. These frame everything else.
2. Check every large transaction. Set a threshold that matters for the account — the top 5–10% by value, say — and match each one fully to the source: amount, date, direction, payee. A single wrong digit on a big number does the most damage.
3. Take a random sample of the rest. Pull a spread of ordinary lines from across the period, not just the top of page one. Twenty to thirty lines on a typical month is enough to expose a systematic extraction fault if one exists.
4. Match four fields, not one. For each sampled line, confirm the amount, the date, the money-in/money-out direction, and the payee or description against the statement. People check the amount and stop; the direction and the date are where extraction slips hide.
5. Widen the sample if a sample fails. One bad line is a one-off. Two bad lines from a sample of twenty means the extraction has a pattern — pull more lines until you understand it, then fix the source rather than patching rows.

The point of sampling is leverage. If a converter misreads, say, every transaction that wraps onto a second line, that fault repeats throughout the file — so a modest random sample will almost certainly land on it. You're not trying to inspect every row. You're trying to prove, with reasonable confidence, that no systematic error is hiding in the rows you didn't open.

The misreads worth sampling for

Some errors show up far more than others, so weight your sample towards them. These are the ones we catch most often when transactions come out of a PDF rather than a clean export.

• Transposed digits. 1,290 read as 1,209, or 54 as 45. The figure looks plausible, so the eye slides past it. The balance check flags the total; the spot-check confirms which line.
• Wrong direction. On statements that use a single signed amount column rather than separate money-in and money-out, a credit can land as a debit. The amount is right, the sign is wrong, and the running balance catches it only if the column logic flipped consistently.
• Date drift. A transaction posted on the 31st that gets pulled in dated the 1st of the next month. Harmless to the balance, quietly damaging to a period-end or VAT cut-off.
• Garbled payees. A wrapped or merged description that turns one transaction into two phantom rows, or splices two payees into one. This is the field people skip in a hurry, and it's the one that breaks later categorisation.
• OCR slips on scans. A 3 read as an 8, an O read as a 0, on a scanned or photographed statement. Weight your sample towards low-quality source pages; that's where character misreads cluster.

Where the converter fits — convert, verify, then import

This is the part that decides how much manual verification you're left holding. Most converters and copy-paste hand you rows of numbers with no idea whether those rows are complete or accurate. You get a tidy spreadsheet that might be missing two lines and carrying a transposed figure on a third, and nothing on screen tells you — so the entire verification burden lands on you.

Export Bank Statement changes the starting point. It converts the PDF — including scanned and photographed statements, via OCR — into clean Excel or CSV, then does the part most converters don't do: it runs the running-balance check itself, recomputing opening balance plus transactions against the printed closing figure and flagging any statement that doesn't reconcile. So step one of verification is already done when you open the file. If it reconciles, you start straight at sampling. If it's flagged, you know exactly which statement needs eyes before anything reaches your books.

Getting the data 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 you can match inside the software. It does not push transactions through a live bank-feed API — that's a separate, certified integration — so treat it as producing a verified import file, not a one-click sync. For the errors that originate in extraction specifically, common reconciliation errors and the missing transaction detection guide go deeper.

A quick reference: what to check and how