Bank statement data extraction turns each transaction line on a statement into structured fields: a posting date, a description, a debit or credit amount and a running balance, plus account and period details from the header. Most fields come back reliably. Dates near year end, wrapped descriptions and scanned pages are where errors cluster.
Which fields does bank statement data extraction return?
Extraction returns two groups of fields: header fields that describe the statement as a whole, and line fields that describe each transaction. A bookkeeper needs both, because the header tells you which client and account a line belongs to, and the lines carry the money.
Header fields
Header fields come from the top of the first page, and sometimes from a summary box. They are read once per statement:
- Bank name, used to group statements and to pick the right reading of the layout.
- Account holder, which on a business statement is usually the legal entity name, not a person.
- Account number, normally masked to the last four digits on the statement itself.
- Statement period, a start date and an end date.
- Opening balance and closing balance, the two numbers every later check depends on.
Line fields
Line fields repeat once per transaction:
- Date, the posting date in most layouts, sometimes with a separate transaction date.
- Description, the merchant or payer text the bank prints.
- Debit and credit, either as two columns or as one signed amount.
- Running balance, printed after each line on many, but not all, statements.
- Reference or check number, when the bank prints one.
A sample row, field by field
The table below is an example of what one extracted statement looks like as data. The values are made up for illustration.
| Field | Example value | Where it came from |
|---|---|---|
| Account | Example Bakery LLC, checking ending 4417 | Statement header |
| Statement period | 2026-03-01 to 2026-03-31 | Statement header |
| Date | 2026-03-14 | Date column on page 2 |
| Description | SQ *FLOUR SUPPLY CO 03/13 | Description column, one printed line |
| Debit | 412.80 | Withdrawals column |
| Credit | (empty) | Deposits column |
| Balance | 9,318.27 | Balance column, same row |
Read across that row and every field has one job. The account and period say which books the line belongs to. The date and amount say what happened. The balance lets you prove nothing was skipped. The description is the raw material for automatic transaction categorization with client rules, which turns "SQ *FLOUR SUPPLY CO" into a supplies account.
Banks redesign their statements from time to time, and a new layout can move these columns without warning. Keeping automation running through bank statement layout changes covers how to spot and handle that.
Extracted dates across a statement period that spans new year
Dates are the field most likely to come back wrong without any visible error, and a statement period that crosses January 1 is the usual cause. Many banks print transaction dates as month and day only, so the year has to be inferred from the statement period in the header.
Consider a December statement for a period of December 15 to January 14. A line printed as "01/03" belongs to January of the following year, while a line printed as "12/28" belongs to the year the period started. A converter that stamps every line with the year of the period start will file the January lines a full year early. Those lines then land in the wrong fiscal year, and nothing looks broken until a reconciliation or a year-end report fails to tie.
A sound extraction does three things with dates:
- It reads the period start and end from the header first.
- It assigns each month-and-day line the year that places it inside that period.
- It flags any line whose date still falls outside the period, rather than guessing.
There is a second date trap worth knowing. Some statements print both a transaction date and a posting date. Card purchases made on the last day of a month often post a day or two later. Which date your books should use is a policy choice for the practice, but the extracted data should keep the posting date as the default, because that is the date the running balance reflects.
Running balance columns in extracted statement data
The running balance is the field that makes the rest of the extraction checkable. Opening balance plus every credit, minus every debit, should equal the printed balance on each line and the closing balance at the end. When it does, you know no line was dropped or doubled.
This is the check AutoBankConvert runs before it treats a statement as done: the opening balance plus the transactions must equal the closing balance. A statement that fails is held back for review instead of being exported.
A worked check
Here is an example of how a balance check catches a missed line. The figures are illustrative.
| Line | Debit | Credit | Printed balance | Computed balance |
|---|---|---|---|---|
| Opening | 10,000.00 | 10,000.00 | ||
| Deposit | 2,500.00 | 12,500.00 | 12,500.00 | |
| Rent | 3,200.00 | 9,300.00 | 9,300.00 | |
| Card payment | 650.00 | 8,650.00 | 8,650.00 | |
| Closing | 8,410.00 | 8,650.00 |
The computed closing balance is 240.00 higher than the printed one. That gap is exactly one debit the extraction did not return. On a real statement, the gap usually points to a line that sat at the bottom of a page, a fee printed in a separate box, or a row that wrapped onto two lines and was read as a description continuation.
Statements without a running balance
Some statements, especially credit card statements, print no running balance on each line. The check still works at the statement level: opening balance, plus purchases and fees, minus payments and credits, must equal the new balance. It just cannot point to the exact line where the difference starts. In that case the useful output is a clear flag and the size of the gap, so a person can find it quickly.
Why do extracted descriptions look truncated?
Extracted descriptions often look cut short because the bank printed them that way, not because the extraction lost text. Banks limit how many characters a description column can hold, and card processors add their own prefixes, dates and location codes. A line such as "SQ *FLOUR SUPPLY CO 03/13" is the full description the bank provided.
Real truncation does happen, and it has a recognizable shape. A long description that wraps onto a second printed line can be split in two ways that cause trouble:
- The second line is dropped, so a payee name loses its last word.
- The second line is read as a new transaction with no amount, which then fails validation.
Good extraction treats an indented line with no date and no amount as a continuation of the line above. When you review output, look for descriptions that end mid-word, or for empty-amount rows directly under a normal row. Either one points to a wrap that was misread.
Descriptions matter more than they appear to. They are the input for every categorization rule, so a payee name that is cut differently from month to month can stop a rule from matching. Consistent extraction of the same text is worth more than a cleaner-looking string.
Scanned pages and extraction confidence
Scanned pages are statement images rather than text, so every character has to be recognized optically before any field can be read. That step adds uncertainty. Digital PDFs carry the exact characters the bank printed, while a scan of a paper statement can blur a 3 into an 8 or lose a decimal point.
The risk is not spread evenly across fields:
- Amounts are the most sensitive. A misread digit changes the money, but it also breaks the running balance, so the balance check usually catches it.
- Dates can shift by a digit and still look valid, which is why checking each date against the statement period matters even more on scans.
- Descriptions tolerate small errors for reading, but a changed letter can stop a categorization rule from matching.
A review checklist for scanned statements
When a client sends photographed or scanned statements, a quick review catches most problems:
- Confirm the opening and closing balances were read correctly from the page.
- Confirm the balance check passed. If it failed, find the gap before anything else.
- Scan the dates for anything outside the statement period.
- Look for unusual characters in descriptions, such as a zero in place of the letter O.
- Check the transaction count against the number of lines on the page for one sample page.
AutoBankConvert reads scanned and digital PDFs in the same run, and a statement that fails its balance check is flagged instead of exported. A good scan still beats a bad one, so it is worth asking clients for the bank's downloaded PDF whenever they can get it.
When not to rely on extraction alone
Some statements should go to a person regardless of how clean the output looks. A statement with handwritten notes over the transaction area, a page photographed at a steep angle, or a statement where the client has cut out pages are all poor inputs. Extraction will still return fields, but the confidence you can place in them is low, and a manual look takes less time than unwinding a wrong entry later.
Before you choose a tool for this work, test it on your own clients' statements rather than a vendor sample. The guide to scoring bank statement extraction software field by field gives a method for that test, and AutoBankConvert shows how a monthly batch moves from statements to categorized, export-ready files.