Why Extracted Transactions Don't Reconcile

This is a different problem from a reconciliation that won't balance because of timing or unrecorded fees. Here the source document is correct — the bank's own running balance proves it. The error was introduced *during extraction*, after the statement left the bank.

What "doesn't reconcile" means for an extracted statement

A bank statement reconciles internally when opening balance + every credit − every debit = closing balance, and the bank prints a running balance after each line to make that checkable. When you extract that statement into Excel or CSV, the closing balance and the opening balance usually survive intact — they're big, isolated numbers. What gets damaged is the rows in between.

So a converted statement that "doesn't reconcile" is telling you something precise: the transactions you now hold no longer sum to the gap between the opening and closing figures that came off the same page. Something was added, lost, or altered in transit. The bank didn't make a mistake. The conversion did.

The four extraction faults that break the balance

These are the ones we hit most when we convert statements ourselves, in rough order of how often they're the culprit.

1. A transaction dropped at a page break. Multi-page statements are where most damage happens. A line sitting right on the boundary between page 3 and page 4 — or trapped under a repeated column header — gets skipped. The spreadsheet looks complete because nothing visibly broke. But your total is now short by exactly that one transaction's amount, and every row after it inherits the gap.
2. A misread amount or a single misread digit. On scanned or photographed statements, OCR turns ink into numbers and occasionally gets one wrong. A 3 read as an 8, a 1 read as a 7, a faint decimal point that lands a place to the left. 1,240.00 becomes 1,248.00, or 52.00 becomes 520.00. The line is present and looks ordinary; only the value is off, so the balance drifts from that row onward by the size of the misread.
3. Two same-day lines merged into one. Banks often print several transactions on the same date with the date shown once. A converter that keys rows off the date column can fold two of those lines together — two card payments on the 14th become a single row, or a debit and a credit on the same day collapse into one net figure. One transaction effectively vanishes into another, and the balance won't tie.
4. A wrapped description splitting a row. Long payee descriptions wrap onto a second physical line in the PDF. A naïve parse treats that wrapped text as a brand-new transaction with no amount, or pushes the real amount onto the orphan line. One genuine transaction becomes two malformed rows, the columns shift, and the running total falls out of step.

There's a quieter cousin worth naming: a lost minus sign or a swapped debit/credit column, which flips a payment into a receipt. The amount is right; its direction isn't. The closing balance then misses by twice the transaction value, which is a useful signature in itself.

How the running-balance check pinpoints the broken row

Matching extracted lines back to the PDF one by one feels safe, but it can't catch a line that isn't there — and a dropped page-break row is exactly the fault no eyeball ever spots. The running balance can, because it doesn't rely on you noticing anything.

Take the opening balance the bank printed. Apply each extracted transaction in date order. After every row, compare your recomputed figure to the balance the bank printed on that same line. While they agree, the extraction held. The first row where your figure stops matching the bank's is the row the fault is on. Not somewhere in the statement — that row. You check one line against the PDF instead of forty.

The size and shape of the gap usually names the fault before you've even opened the source:

• A gap equal to one transaction's amount, appearing at a page boundary, points to a dropped row.
• A gap that's a clean power-of-ten multiple of a plausible amount points to a misplaced decimal from OCR.
• A gap equal to exactly twice a transaction's value points to a flipped sign or a debit landed in the credit column.
• A row that has a description but no amount, or an amount but no description, points to a wrapped line that split.

We converted a 14-page statement last quarter that reconciled to the penny on pages 1 through 9, then diverged by 2,300 at the top of page 10 — a transfer that had slipped under a repeated header at the page break. Reading the list would never have surfaced it. The balance flagged it on the first pass.

Where Export Bank Statement fits

This is the gap the tool was built around. Export Bank Statement converts the PDF — including scanned and photographed statements, via OCR — into clean Excel or CSV, then does the step most converters skip: it runs the running-balance check itself. It recomputes opening balance plus the extracted transactions against the printed closing balance and flags any statement that doesn't reconcile, so a dropped page-break row, a misread digit, or a merged same-day pair surfaces at conversion time — before you've posted a month of entries on top of it.

Getting the data into your accounting software is convert, then import the CSV. The export uses 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 producing a verified import file you bring in yourself, not a one-click sync. The point is that the file you import has already been checked against the bank's own maths. For the faults themselves, common PDF extraction errors goes wider; for the reconciliation method, see how to reconcile bank statements.