Schema CPA

Bank Statement to CSV: Convert a PDF Step by Step

By Schema CPAPublished Updated

To turn a bank statement into a CSV, get the transactions into a worksheet first, from the bank's download or by extracting them from the PDF, then tie the rows to the statement's ending balance. Save the sheet as CSV UTF-8, with commas between fields and quotes around any description that contains a comma.

When a bank statement CSV beats an Excel workbook

A bank statement CSV beats an Excel workbook when the file is going into another program rather than being read by a person. A CSV (comma-separated values) file is plain text: one line per transaction, fields separated by commas. Accounting software imports, scripts and databases read it without needing Excel, and nothing hidden travels with it.

The same simplicity is the cost. Microsoft's page on saving a workbook to text format warns that all formatting is removed when a workbook is saved in any text format, and its CSV options save only the active sheet. Bold totals, colors and other sheets do not travel with the file.

So choose by the next step:

  • CSV for an import into accounting software, a bank-feed upload, or a script that processes many files. Import screens usually ask for CSV because it is predictable.
  • Excel workbook for review, notes, a tie-out formula, or several statements on separate tabs. A preparer who needs to see the work wants the workbook.

Many firms keep both: the workbook as the working file with the balance check, and a CSV saved from it for the import. Importing into QuickBooks or Xero has its own column and date rules; the QuickBooks, Xero and Excel category covers those imports step by step.

A CSV also travels well between people who use different tools. A client's bookkeeper on one system and the firm on another can both open it, which is not always true of a workbook with macros or newer functions.

Converting a PDF bank statement to CSV

Converting a PDF bank statement to CSV takes four stages: extract the transaction rows into a worksheet, check them against the statement's balances, clean the columns, and save as CSV UTF-8. If the bank offers a CSV download for the period, start from that instead, since the bank's own file skips the extraction step.

1. Extract the rows. For a digital PDF, the rows can be copied or pulled from the text layer. For a scan, OCR has to read the page first. The post on telling a scanned bank statement PDF from a digital one shows which route a file needs. Extraction is also the moment to capture the header facts the rows depend on, such as account, period and balances; bank statement extraction covers those fields.

2. Check the rows. Beginning balance plus deposits minus withdrawals must equal the printed ending balance. Do this in the workbook, before saving as CSV, because the CSV cannot hold the formula.

3. Clean the columns. One header row, one row per transaction, no page subtotals, no repeated page headers, no blank rows. Set the column order the import expects. The usual columns, and what each holds, are laid out in a sample bank statement CSV, line by line.

4. Save as CSV UTF-8. Use the step list below.

Step list: save a bank statement sheet as CSV UTF-8 in Excel

These steps follow Microsoft's page on saving a worksheet as a CSV file. The file name is an example for a fictional client account.

  1. Click the tab of the sheet that holds the transactions. Only the active sheet is saved.
  2. Go to File and select Save as or Save a Copy.
  3. Under the file format, open the drop-down and choose CSV UTF-8 (Comma delimited) (*.csv).
  4. Name the file by account and period, such as ridgeline-4821-2026-03.csv.
  5. Select Save. If Excel warns that some features will be lost, keep the CSV format; the workbook copy keeps everything else.
  6. Close the CSV and keep working in the workbook. Reopening the CSV in Excel and saving again can reapply Excel's number handling to the text.

Microsoft's page also notes that saving as CSV is not currently possible in Excel for the web. Use the desktop app for this step.

Which delimiter and encoding should a bank statement CSV use?

A bank statement CSV should use a comma as the delimiter, UTF-8 as the encoding, and double quotes around any field that contains a comma, a quote or a line break. That combination matches the common description of the format and survives the merchant names, accented characters and currency symbols that show up in transaction descriptions.

Delimiter. RFC 4180, the informational document that describes the CSV format and registers the text/csv type, says fields are separated by commas and each line should have the same number of fields. Some regions use a semicolon, because the comma is their decimal mark. Microsoft's page on importing or exporting text files explains that the list separator comes from Windows region settings, and that changing it affects every program on the computer. Unless the import target asks for something else, use commas.

Encoding. RFC 4180 notes that common usage of CSV is US-ASCII, which has no accented letters or symbols beyond the basics. A payee like "Café Lumière" or a description with a euro sign needs more than that, and UTF-8 covers it. Excel's CSV UTF-8 option writes UTF-8. Microsoft's page on opening CSV UTF-8 files correctly in Excel says a UTF-8 CSV opens normally if it was saved with a BOM (byte order mark), and otherwise should be opened through Data, Get Data, From Text/CSV.

Quotes. RFC 4180 says fields containing line breaks, double quotes or commas should be enclosed in double quotes, and that a double quote inside a quoted field is written as two double quotes. A description like Payment "ref 22" becomes "Payment ""ref 22""" in the file. To check a saved file, open it in a plain text editor: every description that contains a comma should sit inside quotes. The trouble usually starts when a CSV is built by hand or by pasting text together.

Bank statement CSV pitfalls: quoted commas and lost leading zeros

The two most common bank statement CSV pitfalls are descriptions that split across columns because a comma inside them was not quoted, and check or account numbers that lose their leading zeros because a program read them as numbers. Both damage the file silently: it still opens, and the rows look nearly right.

A description containing a comma, before and after

Here is a fictional transaction whose description contains a comma. The first version was typed together without quotes:

Date,Description,Amount,Balance
03/14/2026,Fieldstone Hardware, Example City,-86.40,4210.15

The header has four fields and the row has five. A program reading this file puts "Fieldstone Hardware" in Description, " Example City" in Amount, and -86.40 in Balance. The real balance lands in a column with no header, and an import either rejects the row or records a nonsense amount.

The corrected row quotes the description, as RFC 4180 describes:

Date,Description,Amount,Balance
03/14/2026,"Fieldstone Hardware, Example City",-86.40,4210.15

Now the row has four fields, and the comma is part of the description. Bank descriptions are full of commas, between merchant and city, in "INC," and "LLC,", and in reference text, so assume every description may need quotes.

Leading zeros and long numbers

Check numbers like 000412, account references like 0042-XXXX-4821 and long transaction IDs are text, not quantities. Microsoft's page on keeping leading zeros and large numbers says Excel automatically removes leading zeros and converts large numbers to scientific notation, and that Excel's precision is 15 significant digits, so longer numbers lose their final digits.

This bites twice. When a bank's CSV download is opened by double-clicking, Excel applies its default data format to each column, as the import and export page describes, and 000412 becomes 412 on screen. If that sheet is then saved as CSV, the zeros are gone from the file too.

To keep them, import instead of opening, and set the check and reference columns to Text before loading. The steps and the type for each column are in importing bank statement files with Data, From Text/CSV. For a value typed by hand, Microsoft's leading zeros page says an apostrophe before the number makes Excel treat it as text.

Dates are the third field that breaks on the way in, when day and month swap. That has its own post: bank statement date format mistakes.

Does a bank statement CSV keep the running balance?

A bank statement CSV keeps the running balance only if you export that column. Keep it in the working file, because it lets anyone recheck every row later. Drop it from an import copy only when the target program rejects extra columns or would read the balance as an amount.

The running balance is the statement's own record of where the account stood after each transaction. In a CSV, it is just another column, but it does a job no other column does: each row's balance should equal the previous row's balance plus this row's amount. A person or a script can test every row of the file in one pass, and the first failing row points to the problem.

Some bank downloads include it already. First National Bank's help page on exporting transactions lists a Balance field, described as the account balance after the system settles the transaction, alongside Date, Description, Debit, Credit and a check reference. The same page says a CSV download includes pending as well as processed transactions, with pending items marked "(pending)" in the description.

That detail matters for the balance. A pending transaction has not settled, so a statement period's CSV that includes pending rows will not tie to the statement's ending balance. Remove pending rows, or download after the period has closed, before running the check.

When to leave the balance out:

  • The import accepts a fixed set of columns. Some import screens map only date, description and amount. An unmapped balance column is ignored at best and misread at worst.
  • The file combines several accounts. A running balance makes sense for one account in date order. Across accounts it means nothing.
  • Rows were re-sorted. Sorting by amount or payee breaks the sequence the balance depends on.

A simple pattern covers all cases: keep one complete CSV per account and period, with the balance column, as the record. Save a second, trimmed copy for the import. Schema CPA ends its process with an export too: once it has read a client's statements and tied their balances month to month, the transactions go out as a CSV or Excel file. The workflow on the homepage shows that export as the last step.

All posts in Bank statements to Excel