A bank statement converter should return the statement's header facts and every transaction as its own row, with debits and credits kept apart and a running balance where the statement shows one. Before trusting one, run eight kinds of statement through it and check that each output ties to the statement's ending balance.
What a bank statement converter should return for each statement
A bank statement converter should return two things for each statement: the header facts that identify it and the transactions that make up its balance. Header facts are the bank, the account, the period and the opening and closing balances. Transactions are one row each, with date, description, amount, and check number where there is one.
The header matters as much as the rows. A sheet of transactions with no account number and no period is a loose list. Once it is saved, nobody can say which account it came from or whether it covers the whole month. The post on header fields in bank statement extraction lists the fields worth capturing and why.
For the transaction rows, expect at least these columns:
- Date as a real date value, not text.
- Description as one cell, even when the statement wraps it over two lines.
- Debit and credit, either as two columns or one signed amount column with a stated convention.
- Running balance, when the statement prints one.
- Check number, for checks.
- Source page, so a reviewer can find the line in the PDF.
The output format matters less than its contents. Some firms want a workbook with one sheet per month; others want a CSV per account for import into another tool. The post on when a bank statement CSV beats an Excel workbook covers that choice. Either way, a converter that cannot return the header facts alongside the rows leaves the reviewer to type them in.
A last item many converters skip is the statement's own summary: total deposits, total withdrawals and, on some statements, item counts. These are what the output is checked against. A converter that returns them saves a trip back to the PDF for every tie-out.
Testing a bank statement converter on your own statements
Testing a bank statement converter means running real statements from your own clients through it and checking each output against the statement it came from. Vendor samples are chosen to convert cleanly. Your clients' statements include the scans, odd layouts and long months the tool will meet in practice.
Build the test set once and reuse it for every tool you look at. Eight statement types cover most of what a firm receives. Each needs a pass condition you can check in a few minutes.
Test checklist: eight statement types
| Statement type | Why it is in the set | Pass condition |
|---|---|---|
| Digital, single page | Baseline: if this fails, stop | Every row present; beginning balance plus credits minus debits equals ending balance |
| Scanned paper statement | Tests OCR on an image-only file | Same tie-out to the cent; no digit misreads in amounts |
| Multi-page, 8 or more pages | Tests rows at page breaks | Row count matches the statement's item counts; no row repeated at the top of a page |
| Multi-account (checking and savings in one PDF) | Tests whether accounts are kept apart | Two separate outputs, each tying to its own ending balance |
| Credit card statement | Tests sign handling on a liability | Purchases and payments on the correct sides; new balance reproduced |
| Loan statement | Tests principal, interest and escrow lines | Payment split matches the statement; principal balance reproduced |
| Statement with check images | Tests whether images become false rows | Check images ignored as rows; check numbers and amounts captured from the list |
| Statement spanning a year boundary (December 15 to January 14) | Tests date years | Every date carries the right year; January rows not dated in the earlier year |
The year-boundary case catches a quiet error. Many statements print dates as month and day only. A converter that assumes the statement's closing year will date the December rows a year late. Sorting by date then puts them in the wrong place, and any period cut-off is off by those rows.
The statement with check images is worth including because those images carry details reviewers need. IRS Publication 583 says that without a canceled check, payment may be shown with certain financial account statements, and that they must be highly legible and show details such as the check number, amount and payee. A converter that turns the images into garbage rows, or drops the check list, loses those details from the output.
Record the results in a grid with one row per statement type and one column per tool. Mark each cell pass or fail, and for a fail, write the dollar difference and the cause you found, such as "dropped last row on page 3" or "December rows dated in the wrong year." A tool that fails one case with a clear cause may still suit a firm whose clients never send that kind of statement. A tool that fails the baseline digital statement does not.
Run the same set again after any major update to a tool the firm already uses. Converters change how they read layouts, and a statement that passed last season can fail this one.
Use redacted or test statements where you can, and only run real client files through tools the firm has vetted. The page on free bank statement converters and client data covers that risk.
Does the bank statement converter keep debits and credits apart?
A bank statement converter keeps debits and credits apart when every withdrawal lands on the debit side and every deposit on the credit side, with no row losing its sign. A converter that flattens signs returns every amount as a positive number in one column. The total then means nothing until someone sorts it by hand.
Flattening is easy to spot. Sum the amount column of a converted month. If the sum is close to total deposits plus total withdrawals, rather than deposits minus withdrawals, the signs were dropped.
A subtler failure is signs that are present but wrong. Statements show withdrawals in several ways: a minus sign, parentheses, a trailing "DR", a separate column, or a red font that vanishes in conversion. A converter tuned to one bank's convention can misread another's. Check a statement from each bank your clients use, not just one.
Credit card and loan statements reverse the meaning of the signs. On a card statement, a purchase increases what the client owes and a payment reduces it. The test is whether the converter's output reproduces the new balance from the previous balance, the purchases and the payments. If it treats payments as purchases, the new balance will be off by twice the payments.
Watch for fees and interest. They are often printed in a separate section near the end of a statement, and a converter can skip that section entirely or read its lines as credits. A month with a monthly service fee is a good test.
Where bank statement converters lose rows
Bank statement converters lose rows in predictable places: at page breaks, in descriptions that wrap over two lines, and in summary sections that look like transactions or hide them. They also double rows, most often when a "balance forward" line at the top of a page is read as a new transaction.
Page breaks. The last transaction on a page often sits just above a footer, and the first one on the next page sits just below a repeated header. Either can be read as part of the header or footer and dropped. In a multi-page test statement, look at the first and last row of every page.
Multi-line descriptions. A wire transfer or an ACH payment with a long reference can wrap onto two or three lines. A converter can return the extra lines as separate rows with no amount, or join them to the wrong transaction. Neither changes the total, so the balance check alone will not catch it. Read the descriptions of the longest rows.
Summary sections dropped. Some statements print checks in a separate "checks paid" grid, sometimes three across. A converter that reads only the main transaction table misses the whole grid, and the debits come up short by exactly the checks.
Summary sections doubled. The opposite failure reads a daily balance table or a deposit summary as transactions, adding rows that are already counted elsewhere.
When rows go missing across a run of statements rather than within one, the cause is often a missing statement, not the converter. The guide to finding gaps in a run of bank statements covers that check.
Should a bank statement converter flag statements that do not balance?
A bank statement converter should flag any statement whose output does not reproduce the ending balance, because that flag tells the reviewer exactly which statements need opening. Without it, someone has to tie out every statement by hand to find the few that failed. A converter that reports its own check turns review into an exceptions list.
The check is simple arithmetic. Beginning balance plus credits minus debits should equal the ending balance. The walk-through of how to prove a converted bank statement is complete shows a worked month, including a dropped row found by the difference.
A good flag says more than "does not balance." It gives the difference in dollars, because a difference equal to a single transaction points to a dropped row, and a difference equal to twice a transaction points to a flipped sign. It also says which statement, so the reviewer opens one file instead of twelve.
The flag should cover the gap between statements too. One month's ending balance should equal the next month's beginning balance. A break there means a missing statement or a statement from the wrong account. Schema CPA ties each statement's balances out against the month before and calls out gaps in the run, so a missing April shows up before anyone builds the sheet; the workflow overview shows where that check sits.
Ask any tool you test what it does when a statement fails its own check. Silent output that looks complete is the worst case. A tool that says "March does not tie by 412.00" is easier to trust than one that never says anything. Firms comparing tools across many clients will find more on batch work and review flags in the guide to bank statement to Excel software for accounting firms.