Feature · Reconciliation
Bank statement reconciliation, checked row by row
Every statement you convert is reconciled against its own arithmetic before you export it. When a number does not add up, you see the row where it stopped adding up, not a total that is quietly a few hundred out.
- Five checks on every conversion
- The failing row is named and linked to the PDF
- Exact arithmetic with zero tolerance
- Falls back to totals when there is no balance column
Running balance check
- POS AMAZON MKTPLACE−86.4316,604.12
- CHECK #1042−1,250.0015,354.12
- ZELLE FROM J MORALES+640.0015,994.12
Every row agrees with the balance printed beside it.
The short answer
What bank statement reconciliation means in a converter
Bank statement reconciliation, in a converter, means proving that the rows extracted from a PDF add up to what the bank printed. VouchRow checks every converted statement row by row against its running balance, then against page subtotals, opening plus movement against the closing balance, the printed credit and debit totals, and the printed transaction count.
That is a different job from reconciling in QuickBooks, Xero or Tally, which assumes the imported statement is right. This one makes sure it is, so a dropped row or a misread digit shows up as a break at a named row, not as an unexplained difference at month end.
The checks are arithmetic only. They confirm that amounts, balances and totals agree. They do not confirm descriptions or dates, and two errors that cancel each other out will pass. The same scope statement is shown in the app and written into the exports.
Step by step
How a converted statement is reconciled
All of this runs automatically on every conversion. Your part is the last step.
- 1Rows are cleaned before they are checkedWrapped description lines are merged into the transaction they belong to, and brought-forward and carried-forward lines are removed as balances rather than counted as transactions.
- 2The running balance is walked pair by pairEach row is marked OK or break against the balance printed on the row before it. A row without a printed balance is skipped rather than given one, so nothing is checked against a number the bank never printed.
- 3Pages and the whole statement are comparedEach page’s last balance must equal the previous page’s last balance plus the page’s net movement. Then the opening balance plus every transaction must equal the closing balance. If the statement does not print an opening balance, it is worked back from the first row and labelled as derived, so an inference is never presented as something the bank printed.
- 4Printed totals and the count are matchedWhere the summary box prints total credits, total debits or a number of transactions, the extracted rows are summed and counted against those figures.
- 5You review what failed and what was skippedThe reconciliation panel lists every check as passed, failed or skipped, with the reason for each skip. A break highlights its row. Click it and the PDF page opens with the source line marked, so you can see what the bank printed beside what was read.
- 6The result travels with the exportExcel files carry a Reconciliation sheet listing each check with its expected and actual figures and the difference. The full CSV adds a per-row reconciliation column and a closing note with the result and its scope.
The five checks, strongest first
They run in order of how much evidence each provides, and each one is skipped rather than failed when the statement does not carry the data it needs. That distinction matters more than it sounds: "we could not check this" and "this does not add up" mean completely different things to the person signing off the books, and collapsing them into one amber warning is how a tool teaches people to ignore its warnings.
- Row-by-row running balance. For every consecutive pair that both print a balance: the previous balance plus this row’s amount must equal this row’s balance. The strongest check there is, because it localises the error to a single row.
- Page subtotals, where the statement prints them. Catches a row lost at a page boundary even when no running balance exists.
- Statement balance. Opening plus the net of every transaction must equal the printed closing balance.
- Printed totals. Total credits and total debits as the bank printed them, against the sum of what was extracted.
- Transaction count, where the statement states one. The cheapest check and the fastest way to notice a dropped row.
Zero tolerance, deliberately
Every amount is held as an integer number of minor units — cents, pence, paisa — and never as a floating-point number. So the arithmetic is exact, and the tolerance for a mismatch is zero rather than a cent.
Tools that work in floating point have to allow a small tolerance because their own arithmetic drifts. That tolerance then hides real errors of the same size. Keeping the numbers exact removes the need for it.
What a failure looks like
The row is highlighted in the grid, and clicking it opens the page it came from with the printed line marked. You see what the bank actually printed beside what was read from it, which turns "the balance is out by 198,000" into "row 47 says 22,000 and the statement says 220,000" in about two seconds.
That pairing — the check that finds it and the source line that proves it — is the whole product. Neither half is much use alone.
Where credit cards fit
Most credit card statements have no running balance column at all, so the strongest check cannot run. That is exactly why there are five rather than one: the statement balance and the printed totals still catch a missing or misread transaction, just without localising it to a row.
The result says which checks ran and which were skipped, so a card statement is never presented as more thoroughly verified than it was.
What reconciliation cannot tell you
Why it works
What row-level reconciliation gives you
Breaks are named, not averaged
A total that is 198,000 out tells you something is wrong somewhere in 400 rows. A running-balance break tells you it is row 47.
Proof is one click away
Every flagged row opens the statement page with the printed line highlighted, so confirming or rejecting a break takes seconds, not a hunt through a PDF viewer.
Skipped is never shown as passed
A statement with no running balance is reported as balanced on the checks that could run, with the skipped ones listed, never as fully verified.
Credit cards are covered too
Card statements rarely print a running balance. The statement balance, printed totals and count still run, so a missing or misread charge is still caught.
Mechanism
What each check compares, what it catches, and when it is skipped
The five checks overlap on purpose. Each catches a failure the others can miss, and each is skipped rather than failed when the statement does not print the figure it needs. The table is the same logic the app runs, in the order it runs it.
| Check | Compares | Best at catching | Skipped when |
|---|---|---|---|
| Running balance | Previous balance + this amount vs this balance | A misread amount or sign, localised to one row | The statement has no balance column, or fewer than two rows print one |
| Page subtotals | Last balance of page n−1 + net of page n vs last balance of page n | A whole row lost where two pages join | There are fewer than two pages, or no page carries a balance |
| Statement balance | Opening + net of all rows vs closing | Any net error across the statement | No opening or closing balance is found |
| Printed totals | Sum of credits and of debits vs the summary box | A missing or misread row on statements with no balance column | The statement prints no credit or debit totals |
| Transaction count | Rows extracted vs the printed count | A dropped or duplicated row, cheaply | The statement prints no count |
Diagnosis
Reading a break: the size of the difference tells you the cause
Because each row is checked against the balance printed on the row before it, one misread amount produces exactly one break, and the rows after it check out again. The difference on that row is not random. Its size and shape usually say what went wrong before you even open the PDF.
Selecting several rows in the review grid shows their count and their combined sum, which makes the last pattern quick to test: select the candidates and see whether they add up to the difference.
| What you see | Likely cause | What to do |
|---|---|---|
| One break; difference is a round multiple of the amount (×10, ×0.1) | A digit dropped or added, or a decimal point misplaced | Open the source line and confirm the printed figure |
| One break; difference is exactly twice the row’s amount | Direction read backwards: a credit taken as a debit, or the reverse | Flip the row’s Cr/Dr in the review grid |
| Two adjacent breaks with equal and opposite differences | The balance on the first row was misread; both amounts are fine | Check the printed balance, not the amounts |
| One break; difference matches no row in the grid | A transaction was not extracted between the two rows | Look at the source page between the two lines |
| Difference divisible by 9 | Two digits transposed, such as 1,540 read as 1,450 | Compare the digits on the source line |
| Page subtotal fails but every row passes | A row lost exactly at the page join, leaving both sides internally consistent | Check the first and last lines of the two pages |
No balance column
Reconciling a statement that prints no running balance
With no balance beside each transaction, the row check is skipped and the result reads "balanced on the checks we could run", with the skipped checks counted. If a statement prints no balances or totals of any kind, the result says there is nothing to verify rather than pretending otherwise.
To find an error the totals have caught, use the difference the failed check reports. A difference equal to one amount on the statement points at a dropped row. A difference equal to twice an amount in the grid points at that row’s direction. On a card statement, payments and refunds are the usual suspects for a reversed sign, so filter to credits first.
Page joins
Carry-forward lines and suspected duplicates
Page breaks are where most extraction errors live. A statement repeats the running balance at the top of each page as "balance brought forward", "b/f" or a bare "continued". Left in, that line double-counts at every join. It is removed only when it looks like a balance line and carries no amount of its own, so a real transaction that mentions "forward" in its description still counts.
A row with the same date, amount and description as a row on the previous page is flagged as a possible duplicate. It is never removed automatically, because the same coffee bought twice in a day is normal. You decide, and an excluded row stays visible in the grid while being left out of every export.
Scope
What a passing reconciliation does not prove
A statement that reconciles has amounts and balances that agree with each other and with the printed totals. That is strong evidence the numbers were read correctly. It is not evidence about anything else.
- Dates. Day-first or month-first order is decided once for the whole statement, which avoids the worst case, but a single misread day moves a transaction without changing any balance.
- Descriptions. A payee name read wrongly balances perfectly.
- The statement itself. Reconciliation checks the extraction against the document, not whether the document is genuine, which matters when statements come from someone else.
In your books
How this connects to reconciling in QuickBooks, Xero or Tally
Your accounting software reconciles the register against the statement’s ending balance. If the converted statement reconciled here, the import should land on that same ending balance, provided the account’s starting balance in your software matches the statement’s opening balance.
When it does not, the cause is usually on the import side: a bank feed that already brought in the same dates, the same statement imported twice, or a starting balance from a different period. The guides below cover each.
Side by side
Statement-total check vs row-level reconciliation
Many converters, and most manual spreadsheets, stop at opening plus movement against closing. Here is what the row check adds.
| Opening + movement = closing only | Row-by-row running balance (plus totals) | |
|---|---|---|
| Tells you something is wrong | Yes | Yes |
| Tells you which row | No | Yes, where a balance column exists |
| Dropped row | Caught, location unknown | Caught at the row after the gap |
| Sign read backwards | Caught, location unknown | Caught at the row, difference = 2 × amount |
| Misread balance, correct amounts | Not caught unless it is the closing balance | Two adjacent breaks |
| Two errors that cancel | Not caught | Not caught |
| Statement with no balance column | Works if opening and closing print | Falls back to totals and count, and says so |
Who uses it
Who relies on it
Catch-up bookkeeping
Eighteen months of client PDFs, each reconciled on conversion, so the import ties to every closing balance and the month-end reconciliation goes through first time.
Accountants preparing a proof of cash
The Excel Reconciliation sheet documents opening, movement, closing and any break for each statement: a sound starting schedule for a review file.
Lenders summarising applicant statements
Deposits and withdrawals that tie to the printed totals before they reach your own analysis, with every row traceable to its page.
Forensic and family-law work
A passing running balance and transaction count show no row went missing between the PDF and the schedule.
FAQ
Reconciliation that names the row: questions
What is bank statement reconciliation?
Comparing two records of the same account and explaining every difference. In accounting software it means matching your books to the statement. In a converter it means checking that the extracted transactions add up to the balances and totals the bank printed.
How do I reconcile a bank statement in Excel?
Start from the opening balance, add a column of previous balance plus amount, and compare it with the printed balance on each row. The first row where they differ is the error. A converted Excel file here has had that done already, with the result on its Reconciliation sheet.
Why does my converted statement not reconcile?
Usually a misread digit, a debit taken as a credit, a row missed at a page break, or a balance line counted as a transaction. The size of the difference at the break usually tells you which.
Does reconciliation work on credit card statements?
Yes, with less precision. Most card statements have no running balance, so the row check is skipped and the statement balance, printed totals and transaction count are used instead. They catch a missing or misread charge but cannot name the row, and the result says which checks were skipped.
Can a statement reconcile and still be wrong?
Yes. Reconciliation is arithmetic only. A wrong date, a wrong description, or two errors of the same size in opposite directions all pass. It is a strong detector of misread and missing amounts, not a guarantee.
What does "opening balance derived" mean?
The statement did not print an opening balance, so it was worked out from the first row: that row’s balance minus its own amount. It is labelled as derived so it is never mistaken for a figure the bank printed.
Does it remove duplicate transactions?
It flags rows with the same date, amount and description on consecutive pages as possible duplicates and leaves the decision to you. Repeated identical charges are normal, so nothing is deleted automatically.
If I change a row in review, does the reconciliation change?
No. The result always describes the extraction against what the bank printed. Your changes, such as flipping a sign or excluding a row, are kept separately and applied to the export, so an export that deliberately leaves a row out is not turned into a failure.
Keep going
Related guides and converters
Related features
When the numbers do not match
Related
Other features
Convert a statement and see where it breaks, if it breaks
Create an account, upload a PDF and read the reconciliation before you export. Plans start at $15 a month for 300 pages, and only pages with transactions count.