Set Up Transaction Fields for Bank Statements

What this guide helps you do

This guide shows how to configure a bank statement parser in PerfectParser, set up transaction tables and balance fields, run a test batch, and export reconciliation data. Leave the AI prompt blank initially if you want the AI to surface all visible statement fields before you lock the schema.

Why bank statements are hard to parse

Bank statements stretch across multiple pages with transaction tables that break mid-row at page boundaries. Some banks use separate credit and debit columns; others use a single amount column with a DR/CR indicator. Running balance continuity is fragile — a missed row on page two throws off every subsequent balance check. Statement period dates appear in headers that differ by institution ("Statement Period", "For the period ending", or a date range in fine print). Summary totals for deposits and withdrawals may sit on the last page while transactions start on page one. Credit card statements add purchase categories and foreign exchange lines that look like regular transactions. A schema that only captures header balances without a robust transactions table will not support reconciliation workflows.

Recommended Fields

We suggest configuring the following schema fields for your Bank Statement Parser to capture all essential ledger and summary data.

AI Prompt (Optional)

Use this only when you want to guide auto-detect toward a specific set of fields.

If you want PerfectParser to discover additional fields on its own, leave the AI Prompt (Optional) box blank for the first pass, review the detected schema, then add a prompt only if you need tighter consistency.

When you do use a prompt, copy and paste the following instructions into the AI Prompt (Optional) field during setup:

Extract the bank name, account number, statement period, starting balance, ending balance, total deposits, and total withdrawals. Also extract the transactions table containing the transaction date, description, deposit/credit amount, withdrawal/debit amount, and running balance.

Set up this parser in the dashboard

Create a parser

Go to Parsers → New Parser in the dashboard. Give it a name like "Bank Statement Parser" and optionally select the document category.

Upload a sample document

Drag and drop a representative bank statement (PDF, PNG, or JPEG). Use a multi-page statement if that is what you process in production — the AI needs to see how transaction tables continue across pages.

Detect fields or use standard fields

Paste the AI Prompt from the section above into the AI Prompt (Optional) box if you want tighter field mapping, then click Auto-Detect. To discover more fields automatically, leave the prompt blank and click Auto-Detect. Or skip auto-detect and add fields manually using the Recommended Fields table above.

Review and save your schema

Check that transactions is a Table with separate deposit and withdrawal columns. Confirm balance fields are Number, not Text. Edit field descriptions if your bank labels credits differently (e.g. "Deposits" vs "Credits"). Click Save.

Run a test batch

Navigate to Bulk Extraction, choose One document per file for multi-page PDFs, upload a small test set, and click Extract All Files. Review transaction row counts in Batch History and export to CSV or Excel.

Common mistakes

• Letting a transaction table break at a page boundary without testing a multi-page sample — rows on page two are the most commonly dropped.
• Using one signed amount column when your bank prints separate debit and credit columns (or vice versa).
• Capturing statement_period from a payment due date instead of the actual coverage range in the header.
• Skipping running_balance in the transactions table, which removes the quickest sanity check during reconciliation.

Next steps

• Create a Parser guide
• Bulk Extraction guide
• Export Results guide