Why do converters fail on combined statements?

Because the PDF carries several account sections — checking, savings, sometimes a money market — each with its own opening balance, transaction list, and closing balance. Template-based converters read 'the' transaction table, so they either grab one account and drop the rest, or concatenate everything into one list where the balances can't possibly reconcile.

How can I tell my conversion mixed accounts together?

Reconciliation math. For any single account: opening balance + all transactions = closing balance. If the converted total doesn't close against either account's printed balances — or the transaction count roughly equals both sections combined — you're looking at a merged list. A converter that verifies balances will refuse to call that a success.

Do I import checking and savings as one account into QuickBooks?

No. Each bank account in the real world is its own account in QuickBooks (and Xero). Import one file per account, into the matching account register. A merged import makes both registers unreconcilable and is painful to unwind after the fact.

What about statements that also include a credit card section?

Same principle, plus a sign trap: credit card sections state amounts from the card's perspective (a charge is positive there, money out for you). Convert the card section separately and check the sign convention against a known transaction before importing.

Converting a combined checking + savings statement

Published August 28, 2026

The short answer: a combined statement is several statements sharing a PDF, and it must come out as several files — one per account, each reconciling against that account's own printed opening and closing balances. Any output that mixes the sections into one list is wrong even if every individual row is right.

Why this breaks tools that handle single accounts fine

Banks (community banks and credit unions especially) mail one document covering the customer's checking, savings, and sometimes CDs or money market accounts. Each section restates its own header, balances, and table — often with identical column layouts. A parser that pattern-matches "the transaction table" has no concept of section boundaries, so the classic failures are:

The merge: all sections concatenated into one list. Detectable because the math can't close — no single account's opening/closing pair explains the combined total.
The silent drop: the first (or largest) section converts; savings quietly vanishes. Detectable only if you know the section count going in — or if the tool reports pages it couldn't attribute.
The balance bleed: the savings section's running balance column gets read as checking's, producing rows that "exist" but break the running-balance chain.

The working procedure

Count the sections first. Skim the PDF and note each account's number (last four digits), opening balance, and closing balance. Two minutes, and it turns silent failures into visible ones.
Convert with per-account verification. Run the statement through a converter that reconciles — each account's transactions must close against that account's own printed balances, and a section that doesn't close must be flagged, not shipped. Our accuracy method checks both the period totals and each row's running balance, so a bled-in row from another account breaks the chain exactly where it happened.
Export one file per account. Then import each into its matching register — .qbo or QuickBooks CSV for QuickBooks, OFX or CSV for Xero.
Verify counts and closings account by account after import, against the notes from step 1.

If a section is a scan (banks often archive combined statements as images), the OCR guide covers how verification catches misread digits there too. And if you're clearing a multi-year backlog of these, the 90-days-and-older import guide covers batching and duplicate handling for the whole run.

Questions people ask

Why do converters fail on combined statements?: Because the PDF carries several account sections — checking, savings, sometimes a money market — each with its own opening balance, transaction list, and closing balance. Template-based converters read 'the' transaction table, so they either grab one account and drop the rest, or concatenate everything into one list where the balances can't possibly reconcile.
How can I tell my conversion mixed accounts together?: Reconciliation math. For any single account: opening balance + all transactions = closing balance. If the converted total doesn't close against either account's printed balances — or the transaction count roughly equals both sections combined — you're looking at a merged list. A converter that verifies balances will refuse to call that a success.
Do I import checking and savings as one account into QuickBooks?: No. Each bank account in the real world is its own account in QuickBooks (and Xero). Import one file per account, into the matching account register. A merged import makes both registers unreconcilable and is painful to unwind after the fact.
What about statements that also include a credit card section?: Same principle, plus a sign trap: credit card sections state amounts from the card's perspective (a charge is positive there, money out for you). Convert the card section separately and check the sign convention against a known transaction before importing.

This guide is about file conversion and bookkeeping tooling — it isn't tax, accounting, or legal advice. Verify converted data against the source statement before filing or posting it.