You convert a bank statement to CSV. The opening balance plus the transactions equals the closing balance, so the file appears ready to import. Yet two transactions are missing. Can both things be true? Yes: the missing amounts can cancel each other out.
A balance check is useful evidence about the total. It cannot, on its own, prove that every transaction was captured correctly. This worked example shows the gap and gives you a short review sequence to use before a converted statement reaches the books.
What a matching balance establishes
Under a consistent sign convention, opening balance plus the sum of movements should equal closing balance. That checks the net movement. It does not independently verify transaction count, dates, descriptions or the completeness of the rows.
A CSV with two missing rows can still balance
Consider a fictional EUR current account with an opening balance of €1,000.00. Money received is positive and money paid out is negative. The original statement contains these four transactions:
| Date | Description | Amount | Running balance |
|---|---|---|---|
| 1 August | Customer receipt | +€500.00 | €1,500.00 |
| 2 August | Supplier payment | −€200.00 | €1,300.00 |
| 3 August | Card purchase | −€75.00 | €1,225.00 |
| 4 August | Card refund | +€75.00 | €1,300.00 |
The correct net movement is €300.00. Now suppose the converter misses the card purchase and its refund. The two remaining rows still sum to €300.00, and €1,000.00 + €300.00 still equals the closing €1,300.00. The balance check passes even though half the rows are absent.
Checking total money in and total money out would expose this example. The statement has €575.00 in receipts and €275.00 in payments. The incomplete CSV has €500.00 and €200.00. Both totals are €75.00 short, while their difference remains identical.
Other errors that a closing balance will not reveal
- Two incorrect amounts offset. A €120 payment read as €170 and a €50 receipt read as €100 introduce opposite €50 errors. The combined net movement stays the same.
- The dates are wrong. Reading 5 August as 8 May changes the period assignment without changing the amount.
- A description is attached to the wrong row. The total stays correct while the information used to identify a payment becomes misleading.
- An equal receipt and payment are duplicated. The extra pair contributes zero to the net movement, even though both transaction count and gross totals are inflated.
These are reasons to combine checks, not to discard reconciliation. Each check tests a different property of the file. Read our explanation of auto-reconciliationfor the balance-checking stage of the conversion workflow.
Five checks before importing a converted statement
1. Confirm the account, currency and statement period
Compare the PDF heading to the file you intend to import and its destination account. A correct EUR export is still the wrong file for a GBP account. Check the full date range, especially where a statement crosses a month or year boundary. Keep different accounts separate.
2. Compare transaction counts and page boundaries
Count transaction entries rather than physical lines of text: one description can wrap across several lines. Exclude opening balances, page totals and repeated table headings from the count. Where the statement provides a transaction count, compare it with the extracted rows.
If there is no printed count, inspect the transaction sections page by page. Pay particular attention to the last transaction on one page and the first on the next. Check that a continued description has not become a second transaction and that a row near a footer has not disappeared.
3. Compare receipts and payments separately
When the PDF supplies totals for money in and money out, compare them separately with the export. Under the positive-in, negative-out convention, these spreadsheet formulas calculate the two totals for an amount column in D2 through D101:
Money in: =SUMIF(D2:D101,">0",D2:D101)
Money out: =-SUMIF(D2:D101,"<0",D2:D101)
Net: =SUM(D2:D101)Adjust the range to include all transaction rows and exclude totals. The amount cells must contain numbers; currency symbols or formatting imported as text can cause values to be ignored. Some spreadsheet locales use semicolons as formula separators.
Gross totals add evidence, not certainty
Separate totals catch the missing purchase-and-refund example. They still cannot prove dates or descriptions are right, and errors can offset within the receipts or payments group too.
4. Review running balances and individual rows
If the statement supplies running balances, check them in the bank's printed order. With the convention used above, each previous balance plus the next amount should produce the next balance. A break helps narrow down where to inspect the source.
Also compare dates, signs and descriptions for the largest payments, refunds, fees and any flagged rows. A sample can reveal a problem but cannot certify every unchecked row. For an unfamiliar layout or a poor scan, widen the review; if the source is illegible, request a better copy.
5. Check what is already in the destination account
A CSV can perfectly represent a statement and still duplicate an earlier import or bank feed. Compare the intended upload with existing records. Same date and amount alone do not establish a duplicate: two legitimate purchases can share both.
Intuit's duplicate-transaction guidance advises comparing suspected duplicates with the statement and checking details such as payee and how the entries were created. For Xero users, its explanation of reconcile perioddescribes using a defined period and balance comparison to help identify missing, duplicate or incorrect transactions.
What to do when one of the checks fails
Keep the original PDF and a copy of the unedited export. Identify the affected page or row, compare it with the source, and document any correction. Recalculate counts and totals after editing. If the underlying statement is incomplete, obtain the missing pages before treating the export as complete.
Do not force the total to match
Adding a balancing row or deleting an unexplained difference conceals the extraction problem. Correct a value only when the source supports that correction. Leave unresolved items visible for review.
StatementEdge can help with PDF extraction and balance checks; review the resulting rows before importing them. A matching conversion balance does not establish that payments are correctly categorised or matched to records in your accounting software.
Gathering files for a new client? Use our statement-request checklistto establish complete coverage before starting. You can also open the converter when a PDF-only period is ready for review.