Good bank statement extraction captures more than transaction rows. It also pulls the header: bank, account number, statement period, beginning balance, ending balance, and total deposits and withdrawals. Those fields identify which statement the rows came from and prove the rows are complete, because beginning balance plus credits minus debits must equal the ending balance.
Header fields in bank statement extraction: account, period, balances
The header fields on a bank statement are the values printed once per statement, usually on the first page: the bank's name, the account holder, the masked account number, the statement period and the summary balances. Extracting them turns a pile of rows into a statement you can identify, file and check for completeness.
Transaction rows alone cannot tell you which account they belong to or whether any are missing. A spreadsheet of 214 rows looks the same whether the statement had 214 transactions or 230. The header fixes that. The beginning balance, the ending balance and the summary totals give you a sum to test the rows against.
The table below lists the fields worth capturing. The example values come from a fictional checking statement for a fictional client, Larkspur Design Studio, at a fictional bank.
| Field | Where it sits on the statement | Example value | What it is used for |
|---|---|---|---|
| Bank name | Top of page 1, logo or letterhead | Example Community Bank | Groups statements by issuer |
| Account holder | Address block, page 1 | Larkspur Design Studio LLC | Confirms the statement belongs to this client |
| Account number | Header, usually masked | XXXX-4821 | Separates accounts at the same bank |
| Account type | Header or section title | Business checking | Splits checking, savings and loan files |
| Statement period | Header, "for the period" line | 03/01/2026 to 03/31/2026 | Places the statement in a monthly run |
| Beginning balance | Account summary box | 18,402.17 | Start of the tie-out |
| Total deposits and credits | Account summary box | 9,860.00 | Checks the sum of credit rows |
| Total withdrawals and debits | Account summary box | 11,245.39 | Checks the sum of debit rows |
| Ending balance | Account summary box | 17,016.78 | End of the tie-out, and next month's beginning balance |
| Page count | Footer, "page 1 of 6" | 6 | Confirms no pages were dropped |
In this example, 18,402.17 plus 9,860.00 minus 11,245.39 equals 17,016.78. If the extracted rows sum to anything else, a row is missing, doubled or carries the wrong sign.
The ending balance has a second job. It should equal the beginning balance on the next month's statement. When it does not, a statement may be missing from the run. The post on finding gaps in a run of bank statements covers that check in detail.
Some fields are worth capturing even if no one reads them every day. The page count catches a scan that skipped a page. The account type keeps a savings account from being merged into checking. Interest paid year to date, when printed, is useful at year end, though what a firm does with it is a tax question this post does not answer.
Extracting transactions from a bank statement page by page
To extract transactions from a bank statement, read each page's transaction table in order and carry two things across page breaks: the section the rows belong to, and any row that starts on one page and finishes on the next. A row is complete when it has a date, a description and one signed amount.
Statements split transactions into sections. A common layout lists deposits and other credits first, then checks paid, then other withdrawals and debits. Each section may run over several pages. The heading often appears only once, with "continued" printed on later pages, or with no label at all. An extractor that resets on each page loses the section, and then cannot tell whether 412.50 on page 3 was a deposit or a withdrawal.
Signs matter more than anything else here. Many statements print every amount as a positive number and let the section heading carry the direction. Others use a minus sign, parentheses or a trailing "CR". Decide on one convention for the output, such as credits positive and debits negative, and convert every row to it.
Dates often print without a year, as "03/14" or "Mar 14". Take the year from the statement period in the header. A statement that runs from December 16 to January 15 needs care: rows dated in December belong to the earlier year, and rows dated in January to the later one. Getting this wrong puts a whole half-month in the wrong year.
Long descriptions wrap. A wire transfer may print the sender name on one line and a reference on the next two. Those extra lines have no date and no amount. Join them to the row above, not into rows of their own.
Running balances, when the statement prints them, are a free check. Each row's balance should equal the previous balance plus the row's amount. If a balance column jumps by more than the row explains, a row was skipped.
The rows themselves should land in a fixed set of columns. Which columns, and in what order, is the subject of the post on bank statement CSV format. How a program finds these rows on the page, with templates or without, is covered in the bank statement parser post.
How does bank statement extraction handle several accounts in one PDF?
Multi-account bank statement extraction means splitting one combined statement into one output per account. Banks often send a single PDF that covers a checking account, a savings account and sometimes a loan or line of credit. Each account has its own header, its own balances and its own transactions, so each should become its own sheet or file.
The split point is the account header. When a new masked account number appears with a new beginning balance, a new account has started. Everything until the next header belongs to it. Do not split by page: one account may end halfway down page 4 and the next start below it.
A combined statement often opens with a relationship summary listing every account and its ending balance. That summary is useful for checking that every account was found. It is not a transaction list, and its balances should not be read as rows.
Transfers between the client's own accounts appear twice, once as a debit in checking and once as a credit in savings. Both rows are real. Keep them in their own account's sheet. Flagging matching pairs helps the reader, but deleting one side breaks that account's tie-out.
Using the same example client, a combined March statement might hold:
| Account | Masked number | Beginning balance | Ending balance | Rows |
|---|---|---|---|---|
| Business checking | XXXX-4821 | 18,402.17 | 17,016.78 | 48 |
| Business savings | XXXX-7730 | 25,000.00 | 26,011.04 | 3 |
Each line here becomes a separate sheet, and each sheet ties out on its own.
What happens to check images during bank statement extraction?
Check images in bank statements are pictures of the front, and sometimes the back, of paid checks, printed on extra pages after the transactions. Bank statement extraction should not read them as transaction pages. The check number, amount and date are already in the checks-paid section. The image adds the payee, which the transaction row usually lacks.
Not every bank includes the images in the statement file. TD Bank lists enlarged check images among its alternate statement formats. Whether images arrive depends on the bank and the account.
When the images are there, treat them as a lookup, not as rows. Match each image to its row by check number and amount. The payee written on the check can then fill a payee column for that row. Handwritten payees are hard to read reliably, so mark them for review rather than trusting them blindly.
Image pages also break page-based extraction. A page of twelve small check images contains numbers, dates and dollar amounts in no table at all. An extractor that tries to read it as a transaction table produces nonsense rows. The safest rule is to recognize image pages and skip them for row extraction.
A check that appears in the checks-paid list with no image is normal on many statements. A check image with no matching row is not, and it is worth a second look.
Bank statement extraction errors from summary tables
The most common bank statement extraction error is counting a summary table as transactions. Statements print several tables that look like transaction lists but are not: a daily balance table, an interest summary, a fee summary and a year-to-date box. Each has dates and amounts in columns, so a careless extractor turns them into rows.
The daily balance table is the worst offender. It lists a date and an ending balance for every day the balance changed. Read as transactions, a month with 20 active days gains 20 phantom rows, each worth thousands, and the tie-out fails by a large and confusing amount.
Interest and fee summaries cause smaller errors. An interest summary may repeat the interest credit already shown in the deposits section, along with the annual percentage yield earned. A fee summary may list the month's service charges a second time, with year-to-date totals beside them. Counting either one doubles a real amount.
These tables give themselves away. A daily balance table has dates and one amount per line with no description. Summary tables carry labels such as "total for this period" or "year to date". Their amounts match rows or balances found elsewhere on the statement. When in doubt, run the tie-out from the header fields. Extra rows from a summary table show up as a difference that no single transaction explains.
The tie-out is also the right test for any tool that claims to do this work. The post on what to check in a bank statement converter lists what a converter should return for each statement. Schema CPA reads checking, savings and loan statements, ties each statement's balances to the next month, calls out gaps in a run, and exports the results to Excel or CSV; the document types Schema CPA reads are listed on the homepage.
Where extraction connects to other files
Bank data rarely stands alone. Rows from a statement are later matched to a general ledger or a trial balance, and the statement's ending balance is compared with the balance the books show. The posts in the financial statements and ledgers category cover those documents. Some banks also deliver statements as structured files rather than PDFs. The MT940 to Excel post explains one such format, where the header fields above arrive as tagged lines.