How to Extract Transactions From a PDF Bank Statement

A bank statement can contain hundreds of transactions. Manual copy and paste can move a value to the wrong row. It can also change dates and remove negative signs.

This guide gives you a controlled extraction process. You will extract transactions from a PDF bank statement. You will then check duplicates and reconcile the closing balance.

Use synthetic or authorized statements. Do not upload a statement if you do not have permission to process it.

The result that you must get

Use one row for each transaction.

transaction_date	description	debit	credit	balance	currency
2026-06-02	Payroll deposit		2450.00	5320.18	JMD
2026-06-03	Office supply store	297.00		5023.18	JMD
2026-06-04	Monthly account fee	25.00		4998.18	JMD

Keep statement-level values in a separate record:

bank_name	account_number_masked	period_start	period_end	opening_balance	closing_balance
Example Bank	****1842	2026-06-01	2026-06-30	2870.18	4998.18

Do not repeat the full account number in each transaction row. Keep only the value that your workflow requires.

1. Define the transaction fields

Use these fields for most bank statements:

Field	Type	Extraction rule
`transaction_date`	date	Use `YYYY-MM-DD`
`description`	text	Keep all text for the transaction
`debit`	number	Use a positive number for money out
`credit`	number	Use a positive number for money in
`balance`	number	Use the running balance after the transaction
`currency`	text	Use the statement currency code

Some banks use one amount column. They mark debits with a minus sign or with DR. They mark credits with CR.

Choose one convention before extraction. For accounting imports, separate debit and credit columns are usually clear. Do not mix negative debits with positive debit values in the same file.

2. Define the statement fields

Extract these values once for each statement:

bank name
masked account number
account holder name, when necessary
statement start date
statement end date
opening balance
closing balance
currency

This structure separates the statement from its repeating transactions. It also helps you detect missing pages and duplicate statements.

3. Check the PDF type

Try to select one transaction description in the PDF viewer.

If you can select the text, the PDF is usually digital. If you cannot select the text, use OCR.

For scanned statements, inspect these characters:

0 and O
1, I, and l
decimal points
commas in large values
minus signs
DR and CR markers

A missing decimal point can change 25.00 to 2500. Always check high-value transactions after OCR.

4. Extract a small sample

Open the bank statement parser. Then do these steps:

Upload one representative statement.
Confirm the statement fields.
Confirm the transaction fields.
Start the extraction.
Compare the rows with the source statement.
Correct the schema rules when necessary.
Process the remaining statements.

Choose a difficult sample. Include a page break, a wrapped description, or more than one amount column.

Do not process all files first. A field error can affect every transaction in the batch.

5. Normalize the dates

A statement can omit the year from each transaction. It can show only 03 JUN or 06/03.

Use the statement period to add the year. Be careful when the period crosses a year boundary.

For example, a statement from 2025-12-20 to 2026-01-19 can contain both years. Do not assign 2026 to all transaction dates.

Store dates in YYYY-MM-DD format. This format sorts correctly and reduces regional ambiguity.

6. Keep wrapped descriptions in one row

Banks often put a merchant name on one line and a reference on the next line.

03 JUN  OFFICE SUPPLY STORE       297.00 DR        CARD 1842 KINGSTON

This text is one transaction. The output must keep one row:

transaction_date,description,debit,credit2026-06-03,"OFFICE SUPPLY STORE CARD 1842 KINGSTON",297.00,

Do not create a second transaction for the continuation line.

7. Detect duplicate transactions

A duplicate upload can create duplicate rows. A repeated transaction can also be valid. Therefore, do not remove duplicates with one field only.

Create a comparison key from several fields:

account + date + normalized description + debit + credit + balance

Flag matching keys for review. Do not delete them automatically unless your business rule allows it.

Two card purchases can have the same merchant, date, and amount. The running balance or transaction reference can show that they are different transactions.

8. Reconcile the balance

Use the opening balance, debits, credits, and closing balance.

For this article, debits and credits are positive values in separate columns:

expected closing balance = opening balance + credits - debits

Use this Python check:

from decimal import Decimalopening = Decimal("2870.18")credits = Decimal("2450.00")debits = Decimal("322.00")expected_closing = opening + credits - debitsassert expected_closing == Decimal("4998.18")

If the values do not reconcile, check these causes:

a missing page
a missing transaction
a duplicate transaction
a debit in the credit column
an OCR error
a fee outside the main transaction table
a different balance convention

Do not change a value only to make the balance match. Compare the value with the source statement.

9. Protect sensitive data

Bank statements contain sensitive data. Use these controls:

Limit access to authorized users.
Keep API keys on the server.
Do not put statement data in application logs.
Mask account numbers in previews and media.
Delete temporary files according to your retention policy.
Keep a record of manual corrections.

For consequential accounting or lending work, require a human review before final use.

Select the output format

Use CSV for spreadsheets and accounting imports. Use JSON for an API or automation workflow. Use SQLite for SQL queries across many statements.

To start, open the bank statement parser. You can also use the PDF to CSV converter, review the API documentation, or check pricing.