Convert Multi-Account Bank Statements Without Mixing the Rows

We have tested two combined statements, over five runs each. One is a credit union statement with a savings account and a checking account under one member number, born-digital and short. The other is a Wells Fargo combined statement of accounts with a business checking account and a business savings account, a scanned PDF with no text layer, with one account's transaction history running across four pages. Both reconciled on every run, on both accounts. Statements with three or more accounts, and loan or card accounts printed beside deposit accounts, have not been tested, and this page makes no claim about them.

The two differ in almost every detail and share one shape. Each account is introduced by its own section header, each prints its own opening balance and closing balance, and each prints its own transaction history under that header. One summarises every account up front in a table with the page each section starts on; the other simply runs the sections one after another. One prints a running balance on every row; the other prints a balance once per day.

The risk on a combined statement is attribution, not arithmetic: rows that are each correct and attached to the wrong account, or a second account's section read as a continuation of the first. Both produce a spreadsheet in which every row is right and the totals are wrong, and nothing downstream notices until something fails to balance.

So the section headers are transcribed exactly as printed, each row is recorded under the section it was printed under, and the accounts are kept in printed order. Nothing decides which account a row should belong to; the statement already says. On the review screen the accounts are shown as groups, each with its own label and its own reconciliation result, before you get to the rows.

A transfer between two accounts on the statement is printed twice, once as a withdrawal and once as a deposit, and is kept as two rows. Removing one as a duplicate would take a real transaction away from each account and break both balance chains.

Reconciliation runs per account: that account's opening balance, plus its deposits, minus its withdrawals, against its own printed closing balance. One account reconciling says nothing about another, and the document's verdict is taken from its worst account, never from a sum in which one account's shortfall cancels another's excess.

Where an account prints its own deposit and withdrawal totals, its rows are summed and compared with them. Where it prints a running balance, each amount is compared with the change in balance, on that account's own chain from its own opening balance. Where an account prints none of those figures, the check is reported as one that could not run, never as a pass.

Two things are reported at document level because they are about reading rather than arithmetic. A section that was read with no rows under it means transactions on that account are missing from the export, and the document says so. A heading read as an account that prints no balance or summary of its own cannot be verified, so its rows are kept under their own heading and marked as unverified rather than folded into a neighbour.

Nothing is adjusted to make the accounts balance. Where an account's rows do not reach its printed closing figure, both are shown as they were read and the account is flagged. A converter that moved a row between accounts to make two of them reconcile would be inventing the attribution it was supposed to report.

A long transaction history breaks across pages, and on a combined statement the rows after the break still belong to the account whose section started before it. On the Wells Fargo statement we tested, one account's history ran across four pages while the second account's section came later in the document, and every row stayed with its account on every run.

Every page number is read and compared with the count the statement declares. Pages with no transactions, such as a summary of accounts, fee tables or a balance worksheet, are expected and are not reported as a problem. A declared page that was not read is, because a page that went unread may be the one with the second account on it.

A combined statement is one document however many accounts it prints, and each account is checked against its own printed figures. A PDF that holds two statement periods is a different thing. StackExtract reads one statement period and one set of printed totals per upload, so a second period's rows would be checked against the wrong figures or not read at all. Upload each statement period as its own file.

Where a combined statement is important enough that you would rather a person checked the attribution than check it yourself, Assisted Review can be requested on that document.

StackExtract is an independent tool and is not affiliated with, endorsed by, or connected to any bank or credit union. It reads a document you already have.

XLSX and CSV both carry an account column holding the section header as printed, so the rows can be sorted or filtered by account and nothing has to be split by hand. In XLSX, rows that need review are tinted.

The QuickBooks-ready CSV has only the three columns that import expects, date, description and amount, and no account column. QuickBooks imports one account per file, so a combined statement exports one CSV per account, downloaded together as a zip and named by account and its last four digits. Use XLSX or CSV where you want every account in one file with an account column. All three are files you download; there is no connection to your accounting software or to the bank.