PDF Bank Statement to Ledger (CSV, OFX, Xero, QuickBooks)

Turn a pack of bank or credit-card statement PDFs into one clean, balance-checked, de-duplicated transaction ledger. The Actor is built for bookkeepers and accountants onboarding a client's back statements, for small lenders and brokers reviewing 3 to 12 months of statements, and for n8n, Make and Zapier users who forward monthly statement PDFs into accounting. It parses the real PDF files, checks that every statement reconciles (opening balance plus transactions equals closing balance), removes rows repeated by overlapping statements, gives every row a stable transaction ID and writes import-ready files per account. You stop re-keying statements, and you catch missing months and double imports before they reach the books.

What it does

• Reads text-based statement PDFs supplied as base64 strings (the main mode, which works fully offline) or as https URLs such as signed Drive, S3 or Dropbox links. Text is extracted from the actual PDF bytes with a real PDF parser. Password-protected PDFs work when you pass the password.
• Finds the statement header (last 4 digits of the account number, currency, statement period, opening and closing balance) and parses transaction lines: date, description (wrapped continuation lines are joined), amount and running balance.
• Understands ISO dates (2026-01-05), numeric dates (05/01/2026; you can set the day/month order or let the Actor detect it from the whole document) and textual dates (5 Feb 2026, Feb 5, 2026, and 05 Feb with the year taken from the statement period).
• Works out money in and money out from the change in the running balance. When there is no balance column, it uses minus signs, brackets, CR and DR markers instead.
• Verifies each statement. A statement that does not reconcile is marked failed_balance_check with the difference in the message. Reconciling totals alone do not prove that every row was read (two missed rows can cancel out), so the Actor also checks every printed running balance (previous balance + amount must equal the printed balance) and counts lines with amounts that it could not read. If either shows a problem the statement is incomplete_extraction. A row is verified: true only when its own running balance proves it; rows of statements without a running-balance column are marked verification: statement_totals_only. Rows of statements that fail are never delivered or charged. Set includeUnverifiedRows to receive them in the OUTPUT record.
• Checks continuity per account. Overlapping periods, missing periods and balance breaks (where the previous closing balance differs from the next opening balance) are listed in OUTPUT.accountSummaries.
• De-duplicates rows that appear in overlapping statements using deterministic transaction IDs, so re-running a month never double-imports.
• Writes files per account to the run's key-value store: a ledger CSV every time, plus an OFX file, a Xero bank-statement CSV, a QuickBooks CSV and a JSON coverage report if you request them.
• Reports problems per document in OUTPUT.statements (invalid_pdf, encrypted, download_failed, no_text_layer, unsupported_layout, failed_balance_check, incomplete_extraction, duplicate_only). One bad file never stops the others. When no statement reconciles, the run ends as failed after saving OUTPUT.

Account numbers are only ever output as their last 4 digits. Statement text is never written to the log.

How to use it

1. Open the Actor and click Start. The prefilled input contains a tiny sample statement PDF, so the first run works with one click and needs no network access.
2. Replace the sample with your statements. Add each PDF to documents as base64, or list https links in documentUrls.
3. Pick any extra export files and run. Then download the dataset (CSV, Excel or JSON) and the import files from the key-value store.

Example input:

{
  "documents": [
    { "filename": "jan-2026.pdf", "contentBase64": "JVBERi0xLjQK..." },
    { "filename": "feb-2026.pdf", "contentBase64": "JVBERi0xLjQK...", "password": "only-if-encrypted" }
  ],
  "currency": "GBP",
  "dateOrder": "auto",
  "exports": ["ofx", "xero", "coverageReport"],
  "includeUnverifiedRows": false
}

To encode a PDF, use base64 -w0 statement.pdf (Linux), base64 -i statement.pdf (macOS) or [Convert]::ToBase64String([IO.File]::ReadAllBytes("statement.pdf")) (PowerShell). A data:application/pdf;base64, prefix and line breaks are accepted.

Output

The dataset holds three record types, identified by recordType: statement_report (one per document), transaction (one per kept row) and account_summary (one per account). The same rows are also stored in the OUTPUT record, together with run totals.

recordType	sourceFile	sourcePage	date	description	amount	balance	transactionId	verified
transaction	jan-2026.pdf	1	2026-01-05	SALARY ACME	500	2500	tx_4821_20260105_50000_0302_0	true
transaction	jan-2026.pdf	1	2026-01-14	TESCO STORES	-42.17	2457.83	tx_4821_20260114_-4217_037e_0	true

Here is the statement report from the same run:

{
  "recordType": "statement_report",
  "sourceFile": "jan-2026.pdf",
  "status": "ok",
  "message": "Balance check passed",
  "accountLast4": "4821",
  "currency": "GBP",
  "periodStart": "2026-01-01",
  "periodEnd": "2026-01-31",
  "openingBalance": 2000,
  "closingBalance": 2457.83,
  "rowCount": 2,
  "scannedPagesSkipped": 0,
  "duplicatesRemoved": 0
}

Amounts are signed numbers (negative means money out), with separate debit and credit columns. Dates use ISO format (YYYY-MM-DD). Every transaction carries sourceFile and sourcePage. Each transaction ID combines the account's last 4 digits, the date, the amount in cents, a checksum of the normalised description and an occurrence counter, so the same input always gives the same IDs.

Files written to the key-value store for each account (XXXX is the last 4 digits):

Key	Content
ledger-XXXX.csv	Always written: date, description, amount, debit, credit, balance, currency, account, transaction ID, source file and page
ofx-XXXX.ofx	OFX 1.02 bank statement; transaction IDs are used as FITID
xero-XXXX.csv	Xero bank statement import columns: *Date (DD/MM/YYYY), *Amount, Payee, Description, Reference, Check Number
quickbooks-XXXX.csv	QuickBooks 4-column format: Date (MM/DD/YYYY), Description, Credit, Debit
coverage-XXXX.json	Statements, periods, balances, gaps and overlaps for human review

In CSV files, descriptions that start with =, +, @ or - get an apostrophe in front to prevent spreadsheet formula injection.

Pricing

Pay per event. The main charge is per transaction from a reconciled statement; everything else listed below is free.

Event	Price (USD)	Charged when
Run start (apify-actor-start)	$0.005	once per run; the default 512 MB memory is one event
Transaction (apify-default-dataset-item)	$0.0064	per transaction delivered to the dataset

Not charged:

• statements that fail the balance checks, and their rows
• duplicates removed from overlapping statements
• OFX, Xero, QuickBooks, ledger CSV and coverage export files
• per-statement reports and account summaries

Examples (default 512 MB memory, one start event):

• One month, 60 transactions: $0.005 start + 60 × $0.0064 = $0.389
• Twelve months for a new bookkeeping client, 900 transactions: $0.005 start + 900 × $0.0064 = $5.765
• A scanned statement: $0.005 start + 0 × $0.0064 = $0.005

Spending limit: when you set a maximum cost per run, the Actor stops before it would exceed it, keeps every transaction from a reconciled statement it already delivered and reports limitReached in the OUTPUT record. It never delivers results beyond the limit.

The Store's Pricing tab shows the prices in force. If this section and the Pricing tab ever differ, the Pricing tab applies.

Use cases

• Onboarding a bookkeeping client: upload 12 months of statements and get one ledger per account plus a Xero or QuickBooks import file.
• Monthly automation: send the newest statement from email or Drive each month. Stable transaction IDs let your accounting import skip rows it already has.
• Lender and broker file review: check that 3 to 12 months of statements are complete and continuous, with gaps, overlaps and balance breaks listed for human review. The Actor makes no credit or lending decision.
• Credit-card packs to OFX for tools that only accept bank feeds.

Limits

• Text-based PDFs only. Scanned or image-only pages are not OCR'd. They are counted in scannedPagesSkipped, and a fully scanned file is reported as no_text_layer.
• Layout parsing is generic and expects one transaction per line, starting with a date. Unusual layouts can end as unsupported_layout or failed_balance_check. The balance checks make most parsing errors show up as failures instead of wrong data, but a statement without running balances can only be checked on its totals.
• A statement can only be verified when its opening and closing balances are printed on it.
• Up to 60 documents per run (inline documents and URLs combined), 200 pages per document, 25 MB per file, 5000 rows per statement and 60 MB of total input.
• URL mode: https on port 443 only, and public hosts only. Private and local addresses are blocked, every redirect is re-checked (at most 3), and each download has a 30 second timeout and one retry.
• Currency is read from the statement (common ISO codes, or the £, € and $ symbols). If the statement has none, the currency input is used.
• The OFX file uses a placeholder bank ID and account type CHECKING. Check them in your accounting tool before relying on the file.
• De-duplication only merges rows with the same date, amount and description. If two statements print the same transaction differently, both rows are kept, but the overlap is still flagged in the account summary.

FAQ

Do you need my bank login? No. Only the PDF files you supply are processed.

Is my data stored? Processing happens in memory, and results are written only to your own run storage. Set a short retention period for that storage, and make sure you have authority or consent to process statements that belong to clients.

What if a statement fails the balance check? It is reported with the difference in OUTPUT.statements, its rows are not delivered and you are not charged for them.

Can I mix several accounts in one run? Yes. Statements are grouped by the last 4 digits of the account number and the currency. Statements without a recognisable account number are never merged with each other; each gets its own ledger.

Does it work for credit-card statements? Yes, when the PDF has a text layer and prints opening and closing balances in a supported layout. Amounts follow the statement's own balance direction. On a card statement where the balance is the amount owed, purchases come out as positive amounts, so check the sign convention before importing.

What does maskAccountNumbers do? Account numbers are always reduced to their last 4 digits. The flag is kept for compatibility.

Is this financial advice? No. It is data extraction only, and the coverage report needs human review.