Convert a PDF Bank Statement to CSV

CSV is the format that travels. A row of plain comma-separated values opens in any spreadsheet, feeds a script, and imports into most tools that accept transaction data at all — which makes it the natural output when the statement is an input to something else rather than the end of the job.

It is worth being precise about the limit of that, though: every accounting platform has its own opinion about which columns it wants and in what order. A CSV from StackExtract is clean, structured transaction data. Whether a particular platform accepts it as-is is a question about that platform, and the mapping step is yours.

For each transaction the statement prints, StackExtract reads the date, the description, the amount and — where the statement shows one — the balance after the transaction. Statement-level and account-level fields are picked up where they appear, so a multi-account document does not collapse into one undifferentiated list.

Source layouts vary more than you would expect. Two statements from the same bank in different years can differ; a business account and a personal account often differ more. That variation is the reason there is a review screen between extraction and export rather than a direct download.

A statement covering several accounts stays separated. Each account keeps its own rows and its own totals, because one account balancing tells you nothing about another — and a consolidated document flattened into a single list is the hardest kind of error to notice later, since the rows are all individually correct.

Where the statement prints the balances the arithmetic needs, StackExtract checks the transactions against them: opening plus credits minus debits should reach the closing figure. A statement that does not reconcile is flagged for review before export rather than exported quietly.

Other checks look for the shapes that usually mean something was misread — a transaction that appears twice with the same date, description and amount, a date that is not a real calendar day or falls outside the statement period, an amount or date that could not be read as one. These surface as flags on the rows concerned. They are checks against the document, not confirmation that every figure on it is correct.

A flag is a request for your attention, not a verdict. It means a check found something that does not fit, which is often a misread figure and is sometimes the statement itself being unusual — a correction posted out of order, a fee applied without a balance line. You decide which it is, and nothing is silently altered on your behalf: StackExtract never quietly corrects a number, because a tool that adjusts figures to make its own checks pass is worse than one that reports the disagreement.

And where the statement prints no opening or closing balance — some card summaries and business formats do not — the reconciliation check is reported as one that could not run, never as one that passed. A check that could not run and a check that passed are different facts about a document, and showing them the same way would make every green result worthless.

StackExtract is priced per document rather than per page. One statement PDF is one document, whether it runs to two pages or forty, and whether it covers one account or several.

That matters most on exactly the statements that are hardest to retype by hand. A long business statement or a consolidated document with several accounts in it is where per-page metering gets expensive, and it is also where converting the file saves the most time.