# JSON vs CSV: Which Format for Statement Data?

- Author: FastBankConvert (https://fastbankconvert.com)
- Published: 2026-10-17
- Category: CSV, JSON and text output
- Canonical: https://fastbankconvert.com/blog/json-vs-csv

> JSON vs CSV for statement data: flat rows vs nested records, file size, what each app reads, and when to pick each for your converted file.
JSON vs CSV comes down to who reads the file next. CSV is a flat table of rows and commas that every spreadsheet and budgeting app opens. JSON is a set of named, possibly nested records that programs parse reliably. For statement data, pick CSV when a person or an import screen comes next, and JSON when code does.

## JSON vs CSV for statement data at a glance

The one-line difference between JSON and CSV for statement data is that CSV stores values by position and JSON stores them by name. In CSV, the third value on a line is the amount because the header says so. In JSON, the amount is the value labelled `amount`, wherever it sits.

Here are the same three transactions in both formats. The values are made up for illustration.

As CSV:

```
date,description,amount,balance
2026-09-01,CLIENT PAYMENT INV 1182,2400.00,6610.55
2026-09-03,CORNER PRINT SHOP,-86.40,6524.15
2026-09-05,STUDIO RENT SEPTEMBER,-1250.00,5274.15
```

As JSON:

```json
[
  { "date": "2026-09-01", "description": "CLIENT PAYMENT INV 1182", "amount": 2400.00, "balance": 6610.55 },
  { "date": "2026-09-03", "description": "CORNER PRINT SHOP", "amount": -86.40, "balance": 6524.15 },
  { "date": "2026-09-05", "description": "STUDIO RENT SEPTEMBER", "amount": -1250.00, "balance": 5274.15 }
]
```

The content is identical. The difference is in what each file promises a reader.

| Question | CSV | JSON |
| --- | --- | --- |
| How are fields identified? | By column position, named once in a header | By a key on every value |
| Can it hold groups, like account details plus lines? | Not directly | Yes, with nested objects and arrays |
| Does it say which values are numbers? | No, everything is text | Yes, numbers have no quotes |
| Opens by double-click in a spreadsheet? | Yes | No, it needs an import |
| Easy to read in a text editor? | Yes, for narrow tables | Yes, when indented |
| Typical size for the same rows | Smaller | Larger |

## Flat CSV rows versus nested JSON records

A CSV file holds one flat table: a header line and one line per record, every line with the same columns. A JSON file can hold a tree, so a statement's header details and its transaction lines fit in one document. That is the biggest structural gap between the two formats.

A bank statement has two levels. At the top sit the account, the period, and the opening and closing balances. Underneath sit the transactions. In JSON, the top level is an object with fields such as `account` and `period_end`, and the transactions are an array inside it. Nothing is repeated.

CSV has to choose. One option is to leave the header details out and keep them in the file name, such as `checking-3017-2026-09.csv`. Another is to repeat the account on every line, which makes the file wider but self-contained. A third is a separate small CSV for the header. All three work. None is as tidy as nesting.

### When flat is an advantage

Flatness is also CSV's strength. A flat file has nothing to unpack. Every app that understands rows and columns can read it, and a person can check it line by line against the PDF. If your statement data is only the transaction list, there is no tree to store, and CSV loses nothing.

## Is a JSON file bigger than the same CSV?

Yes, a JSON file is usually bigger than a CSV with the same rows, because JSON repeats every key name on every record and adds quotes, braces and spacing. In the example above, the CSV writes `amount` once, and the JSON writes it three times. For a statement, the difference rarely matters.

A month of transactions is a small file in either format, measured in kilobytes. Even a year of busy business transactions fits comfortably in an email attachment as JSON. Size starts to matter when you store millions of records or send them over a slow connection many times a day, and at that scale people tend to compress the files anyway, which shrinks the repeated keys well.

The more useful question is readability. Indented JSON is long but clear. Minified JSON, with no spaces or line breaks, is compact but hard to read by eye. CSV stays compact and readable until it is wider than your screen.

## Which apps read CSV and which read JSON?

CSV is read by nearly every spreadsheet, accounting tool and budgeting app, which is why it is the usual export and import format for transactions. JSON is read by every programming language and by many web services and databases, but most people's everyday apps do not open it directly.

Readers of CSV:

- **Spreadsheets.** Excel, Google Sheets, Numbers and LibreOffice all open CSV. For moving a finished sheet into Sheets, see [uploading an Excel file to Google Sheets](/blog/upload-excel-to-google-sheets).
- **Budgeting and accounting apps.** Most transaction import screens ask for CSV.
- **Databases.** Nearly all can bulk-load a CSV into a table.

Readers of JSON:

- **Scripts and programs.** Every common language has a JSON parser in its standard library or a widely used package.
- **Web services.** APIs commonly send and receive JSON.
- **Excel, with an import step.** Microsoft's documentation for the [Power Query JSON connector](https://learn.microsoft.com/en-us/power-query/connectors/json) lists Excel among the supported products and says it flattens JSON into a table using automatic table detection.

The CSV standard is looser than it looks. The [CSV description in RFC 4180](https://www.rfc-editor.org/rfc/rfc4180) uses commas, but files from other regions often use semicolons, and a file opened with the wrong separator lands in a single column. [Fixing a CSV that opens in one column](/blog/csv-opens-in-one-column) walks through that repair. JSON has no such variation; its syntax is fixed.

### JSON Lines, a format between the two

JSON Lines puts one complete JSON record on each line of the file, with no surrounding array. It keeps JSON's names and types while letting a tool process the file one line at a time, the way it would a CSV. It is common in data pipelines and log files. Do not assume every JSON reader accepts it, though. The Power Query documentation above notes that trying to load a JSON Lines file through the ordinary JSON connector can fail with an error, and it gives a short workaround in the M language.

## Type and encoding traps in JSON and CSV statement files

Type and encoding traps differ between the formats. CSV carries no types, so the app opening it decides what each value is, and it can guess wrong. JSON does carry types, so the trap moves to the program that wrote it: an amount written as text stays text until someone notices.

### Traps in CSV

- **Signs.** A debit may be written as `-86.40`, `(86.40)` or `86.40 DR`. Only the first reads as a negative number everywhere. [Handling negative numbers in CSV files](/blog/negative-numbers-in-csv) covers the other forms.
- **Leading zeros and long numbers.** A spreadsheet that guesses types will turn a reference such as `00412` into `412`.
- **Dates.** `03/04/2026` is March or April depending on the app's regional settings.
- **Commas inside descriptions.** RFC 4180 says fields containing commas, quotes or line breaks should be enclosed in double quotes. An unquoted comma shifts every later column on that line.

### Traps in JSON

- **Amounts as strings.** `"amount": "-86.40"` looks fine but will not add up in most languages without conversion.
- **Large integers.** The [JSON standard, RFC 8259](https://www.rfc-editor.org/rfc/rfc8259), says integers up to 2 to the power 53, less one, are where implementations agree exactly; longer account or card references belong in strings.
- **Encoding.** RFC 8259 requires UTF-8 for JSON exchanged between systems outside a closed ecosystem. CSV has no such rule, which is why accented names in a CSV sometimes arrive garbled.

## Picking CSV or JSON for your converted statement

Pick CSV for your converted statement when the next step is a spreadsheet, a budgeting app or an accounting import, and JSON when the next step is a script, a database load through code, or an API. If a person needs to look at the rows, CSV or a spreadsheet file wins.

A decision list by destination:

1. **You will review or edit the rows yourself.** Use an Excel workbook or CSV.
2. **An app's import screen asks for a file.** Use CSV, unless the app documents JSON.
3. **A script will categorise, total or reformat the data.** Use JSON, so types and names are explicit.
4. **You need header details kept with the lines.** Use JSON, or CSV with the account repeated on each line.
5. **You will merge many months with code.** Use JSON for the keys, or CSV if every month has the same columns.
6. **You are not sure.** Keep both. A converter that writes either format from the same statement costs nothing extra.

### Switching formats after the fact

Going from JSON to CSV is mechanical for a flat list of transactions: each key becomes a column header and each record becomes a line. Nested parts need a decision. Either the account details are copied onto every line, or they are dropped and kept elsewhere. Going the other way, from CSV to JSON, is where information can be invented by accident. A CSV has no types, so whatever converts it must decide that `00412` is text and `-86.40` is a number. A converter that guesses will happily turn a reference into a number and lose its zeros. Write the rules down once, column by column, and reuse them every month.

### Keep the original statement

Whichever format you choose, keep the PDF. Both files are derived from it, and when a total does not match, the printed page is what you compare against.

FastBankConvert is being built for that last case: it is getting ready to open, and its homepage describes downloading a converted statement as Excel, CSV or JSON. [Get started](/get-started) to be told when trial conversions are available.