# Convert PDF to CSV: One Table, One Clean File

- Author: FastBankConvert (https://www.fastbankconvert.com)
- Published: 2026-05-23
- Updated: 2026-05-23
- Category: CSV, JSON and text output
- Canonical: https://www.fastbankconvert.com/blog/convert-pdf-to-csv

> Convert PDF to CSV when you need plain rows for another app: picking the table, a header row, delimiters, encoding, and checking the file opens.
To convert PDF to CSV, pick the one table you need, extract it with a converter or a spreadsheet import, and save it as plain rows: a single header line, one record per line, commas between fields and quotes around any field that holds a comma. Save it as UTF-8, then open it once to confirm the columns line up.

## Picking the one PDF table that belongs in the CSV

A CSV holds exactly one table, so the first job is choosing which table on the PDF becomes the file. A statement page often carries a summary box, a transaction list, a fee schedule and a block of legal text. Only the transaction list belongs in a CSV meant for a budgeting app or a database.

This choice matters more for CSV than for Excel. An Excel workbook can hold a summary on one sheet and transactions on another. A CSV file has no sheets, no merged cells and no way to say "this part is different". Everything in it is assumed to be a row of the same kind as the row above. If a converter drops the account summary into the top five lines, the receiving app reads those five lines as transactions with odd dates.

A few rules keep the file clean:

- **Keep only repeating rows.** Every line should describe one thing of the same kind: one transaction, one holding, one invoice line.
- **Drop subtotal and carry-forward lines.** A "Balance brought forward" row looks like a transaction and has no transaction behind it.
- **Join page breaks.** A twelve-page statement is one table split across twelve pages. The CSV should have one header and every transaction below it, not twelve header lines scattered through the file.
- **Leave page furniture out.** Page numbers, the bank's address and repeated column titles from each page all have to go.

Statements with more than one account in them need a decision too. A combined checking and savings statement can become one CSV with an account column, or two separate files. One file with an account column is easier to filter later. Two files are easier to import into an app that expects one account per upload.

## Which header row should a PDF to CSV file carry?

A PDF to CSV file should carry exactly one header row, on the first line, with a short name for every column. The header tells the importing app what each field means. [RFC 4180, the document that describes the common CSV format](https://www.rfc-editor.org/rfc/rfc4180), treats that header line as optional, so many apps ask you whether the file has one.

The column names on the statement are a starting point, not a rule. Banks print headings like "Withdrawals / Debits" or "Transaction Description and Reference". Those names are long, contain slashes and spaces, and change between banks. A better header uses plain, stable names you can reuse for every file:

| Column on the PDF (example) | CSV header name (example) |
| --- | --- |
| Posting Date | date |
| Transaction Description | description |
| Withdrawals / Debits | debit |
| Deposits / Credits | credit |
| Daily Balance | balance |

Two habits help here. Keep the names lower case with no spaces, because some import tools and scripts treat "Date " with a trailing space as a different column from "Date". And keep the same names across every file you produce, so a second month's CSV lines up with the first without any remapping.

Avoid stacking two header lines, such as a bank name above the column names. Most importers take the first line as the header and treat the second as data.

## Delimiters and quoting in a PDF to CSV export

The delimiter is the character between fields, and in a standard CSV it is a comma. Trouble starts when a field itself contains a comma, which descriptions often do. The fix is quoting: a field that holds a comma, a double quote or a line break goes inside double quotes, so the comma inside it is read as text.

RFC 4180 spells out the quoting rules. Fields containing commas, double quotes or line breaks should be enclosed in double quotes. A double quote inside such a field is written twice. So a description printed as `Payment to "Bob's" Bakery, Inc.` becomes `"Payment to ""Bob's"" Bakery, Inc."` in the file.

### A worked example: three statement lines as raw CSV

Here is an example of three transaction lines as they would look on a statement, then as raw CSV text. The values are made up for illustration.

On the statement:

| Date | Description | Debit | Credit | Balance |
| --- | --- | --- | --- | --- |
| 03/04 | CITY WATER, UTILITY PMT | 61.20 | | 2,418.75 |
| 03/05 | PAYROLL DEPOSIT ACME CO | | 1,950.00 | 4,368.75 |
| 03/07 | CHECK 1042 "SPRING FAIR" | 40.00 | | 4,328.75 |

As CSV text:

```
date,description,debit,credit,balance
2026-03-04,"CITY WATER, UTILITY PMT",61.20,,2418.75
2026-03-05,PAYROLL DEPOSIT ACME CO,,1950.00,4368.75
2026-03-07,"CHECK 1042 ""SPRING FAIR""",40.00,,4328.75
```

Four things changed on the way, and each one is deliberate. The first description has quotes because it contains a comma. The third has its inner quotes doubled. The empty debit and credit cells became nothing between two commas, which keeps the column count the same on every line. The thousands separator in 2,418.75 was removed, because an unquoted comma inside a number would split it into two fields. The dates also gained a year, written in year-month-day order, which most importers read without guessing.

Some regions use a semicolon as the delimiter, because the comma is their decimal mark. If the app you are importing into expects semicolons, produce semicolons. Do not mix them: every line must use the same character.

## Which encoding should the CSV use for accented payee names?

Save the CSV as UTF-8 unless the receiving app documents something else. UTF-8 can store every letter, so a payee such as "Café Señora" or a name in Greek or Arabic comes through as written. Older single-byte Windows encodings cover only a limited set of characters and turn the rest into question marks or garbled pairs.

The symptom of an encoding mismatch is easy to spot. "Café" shows up as "Café" when a UTF-8 file is read as an older encoding. The data in the file is fine; the reader picked the wrong decoder. Excel is a common place to see it when a CSV is opened by double-clicking. [Opening a UTF-8 CSV in Excel without broken characters](/blog/csv-utf-8-excel) covers the import setting that avoids the problem.

Plain US statements with only English letters and digits rarely show the issue, because the first 128 characters are the same in both encodings. It appears with accented merchant names, foreign-currency card purchases and any statement from a bank outside the US. Check one of those rows when you test the file.

## Checking the converted CSV opens cleanly before import

A converted CSV is good when every line has the same number of fields, the header names match what the importer expects, and the totals still agree with the PDF. Checking takes a couple of minutes. Skipping it means finding the problem later, inside an app that may have already filed bad rows.

Run this six-point check on every new file, or on the first file from a new bank:

1. **Open it in a plain text editor first.** Look at the raw lines, not a spreadsheet's interpretation of them. You should see one header line and one transaction per line.
2. **Count the commas.** Pick three lines from different parts of the file. Outside of quoted text, each should have the same number of separators as the header.
3. **Look for stray page lines.** Search for words like "Page", "Continued" or the bank's name. Any hit inside the data is a leftover from the PDF layout.
4. **Check the first and last transaction.** Compare them with the first and last lines on the PDF. A missing first row often means it was treated as a header.
5. **Add up the amounts.** The sum of credits minus the sum of debits should equal the closing balance minus the opening balance.
6. **Test one accented or special character.** Find a description with an apostrophe, a quote or an accent, and make sure it reads correctly.

Step five is the one that catches dropped rows. A missing transaction rarely shows up by looking at the file, but it always shows up in the arithmetic. FastBankConvert is getting ready to open, and it is built to tell you before download when a statement's balances do not add up; [Get started](/get-started) puts you on the list for trial conversions.

If a check fails, fix the source and convert again rather than editing the CSV by hand. Hand edits to a CSV are easy to make and hard to repeat next month.

## When a CSV is the wrong target for PDF data

A CSV is the wrong target when the data is not one flat table. CSV has no types, no nesting and no room for a second table. If you need to keep a statement header with its transactions, preserve number types for a script, or keep a layout people will read, a different format serves you better.

JSON suits data that has structure. A statement is really one header (account, period, opening and closing balance) with a list of transactions under it. In CSV that header either repeats on every line or gets lost. In JSON it sits once at the top, with the transactions as an array beneath it. If a script or an app is the reader, the post on [converting a PDF to JSON](/blog/pdf-to-json) explains how that structure looks and when it beats rows. For statements specifically, [turning a bank statement into JSON](/blog/bank-statement-to-json) walks through the fields a statement record usually carries.

Excel suits data people will work with by hand. A workbook keeps column widths, number formats and several sheets, so it can hold the summary and the transactions side by side. Retirement and brokerage statements are a good example, because they mix holdings, contributions and fund performance on one page. [Converting a 401(k) statement to Excel](/blog/401k-statement-to-excel) shows how that mixed layout splits into sheets, which a single CSV cannot do.

Pick CSV when the next step is a machine import that wants plain rows and nothing else. That covers most budgeting apps, most database loaders and most accounting imports. For those, the plain format is a strength: any program can read it, and nothing hidden travels with it.