A bank statement CSV format has one header row and one row per transaction, with columns for date, description, amount and running balance, plus check number and transaction type when the bank provides them. Amounts go in either one signed column or separate debit and credit columns. Nothing else belongs in the file: no titles, subtotals or footers.
Columns in a bank statement CSV format
The columns in a bank statement CSV format describe one transaction each: when it posted, what it was, how much it moved, and where the balance stood afterwards. Six columns cover nearly every statement: date, description, amount (or debit and credit), balance, check number and type. Only date, description and amount are essential.
Date. The date the bank posted the transaction to the account. A file may also carry a transaction date, the day the card was used, which can fall earlier than the posting date. When a file has both, check which one the printed statement shows beside each row and use that one for tie-outs. First National Bank's help page on exporting transactions, for example, defines its Date field as the date on which the system posted the transaction.
Description. The text the bank attaches to the transaction: merchant name, transfer reference, check payee or fee name. It is the least tidy column. It often contains commas, codes and truncated words, and it is the one most likely to need quotes in the file.
Amount, or debit and credit. The money that moved. The next section covers the choice between one signed column and two unsigned columns.
Balance. The running balance after the transaction. It is optional for an import but valuable as a check, because each row's balance should follow from the one before.
Check number. The number of a paper check, when the transaction is one. Keep it as text so leading zeros survive.
Type. A short code or word for the kind of transaction: debit card, ACH, check, deposit, fee, transfer. Banks use different words, and some do not include the column at all.
Some exports add an account column, which identifies the account each row belongs to. First National Bank's export lists Account, ChkRef, Debit, Credit, Balance, Date and Description. An account column helps when several accounts share one file; for one account per file, the file name can carry it instead. Which header facts should be captured alongside the rows, such as the period and the opening and closing balances, is covered in bank statement extraction.
One amount column or separate debit and credit in a bank statement CSV?
A bank statement CSV can use one amount column, where withdrawals are negative and deposits positive, or two columns, debit for money out and credit for money in, both written as positive numbers. Use one column for simple sums and imports that expect it. Use two when the file mirrors a printed statement or the import asks for them.
One signed amount column. A deposit of 1,250.00 is 1250.00; a withdrawal of 86.40 is -86.40. The account's change over the period is the sum of the column. A running balance check is one formula per row. The risk is the sign: if a minus sign is lost or a program reads (86.40) differently from -86.40, a withdrawal becomes a deposit, and the total is off by twice the amount.
Separate debit and credit columns. The same withdrawal is 86.40 in Debit with Credit empty; the deposit is 1250.00 in Credit with Debit empty. This matches how many printed statements lay out transactions, which makes row-by-row comparison with the PDF easy. The risk moves from the sign to the column: an amount in the wrong column has the same doubling effect.
A few rules apply to either choice:
- Pick one convention per file. Never mix a signed amount column with a debit column in the same file.
- Leave unused cells empty. In a two-column file, an empty cell is clearer than
0.00for the side that did not move. - Write plain numbers. No currency symbols, no thousands separators, and a minus sign rather than parentheses.
1250.00is unambiguous;$1,250.00contains a comma that must be quoted. - Mind the account type. On a credit card account, a purchase increases what is owed. Files for those accounts may show purchases as positive and payments as negative, the reverse of a checking account. Check the sign against one known transaction before importing.
Neither choice is more correct. What matters is that the convention is stated, consistent, and matches what the next program expects. Accounting imports each have their own preference, and the QuickBooks, Xero and Excel category covers the layouts those imports accept.
A sample bank statement CSV, line by line
A sample bank statement CSV shows the format with real-looking values: one header row naming the columns and five transaction rows. The sample below is for a fictional client, Juniper Hollow Bakery, checking account XXXX-4821, for the first days of March. Every name, amount and number is an example.
Date,Description,Amount,Balance,Check Number,Type
03/01/2026,"Opening deposit, transfer from savings XXXX-7310",2500.00,14980.15,,Transfer
03/02/2026,Meadow Flour Co,-842.60,14137.55,,ACH
03/03/2026,Check 000412,-412.00,13725.55,000412,Check
03/04/2026,"Card purchase, Fieldstone Hardware, Example City",-86.40,13639.15,,Debit card
03/05/2026,Monthly service fee,-12.00,13627.15,,Fee
Line by line:
Line 1, the header. Six column names, separated by commas, in the order the rows follow. RFC 4180, the informational document that describes CSV, treats the header as optional and says each line should contain the same number of fields. Including a header is still the safer choice for bank data, because it tells the next program which column is which.
Line 2, a transfer in. The description contains commas, so it is wrapped in double quotes. The amount, 2500.00, is positive because money came in. The balance, 14,980.15, is the balance after this deposit, which implies the account opened the period at 12,480.15. The check number is empty, shown by two commas in a row.
Line 3, an ACH payment. No commas in the description, so no quotes. The amount is negative. The new balance is the previous one minus 842.60.
Line 4, a check. The check number appears twice: once in the bank's description and once in its own column, as 000412. The leading zeros are part of the value. If a spreadsheet opens this file and treats the column as a number, they will disappear.
Line 5, a card purchase. Two commas inside the description make the quotes essential. Without them, this line would have eight fields instead of six, and every value after the description would shift right.
Line 6, a fee. A small negative amount with a plain description. The final balance, 13,627.15, should match the balance the bank shows after March 5.
The check on this sample is quick: 12,480.15 plus 2,500.00, minus 842.60, 412.00, 86.40 and 12.00 equals 13,627.15. Each row's balance follows from the one above, so the file is internally consistent. How to save a sheet in this shape, and why the encoding should be UTF-8, is set out in which delimiter and encoding a bank statement CSV should use.
How do banks label bank statement CSV columns?
Banks label bank statement CSV columns in their own words, so one field can arrive under several names. A posting date might be "Date" or "Posting Date"; a description might be "Details," "Payee" or "Memo"; a check number might be a short code like "ChkRef." Read the meaning from the content, not the label.
First National Bank's export is a useful example of short labels: its help page lists ChkRef for the check number and Date for the posting date. Without that page, "ChkRef" could be read as a check reference of some other kind, and "Date" could be either the transaction date or the posting date.
A mapping table, kept per bank, solves this once. The labels on the left are examples of the kinds of headers a firm may see across different banks' files; the right column is the standard name the firm uses.
| Header in a bank's file (examples) | Standard column | What to check |
|---|---|---|
| Date, Posting Date, Post Date | Date (posted) | Is there also a transaction date? Use the posted one for tie-outs. |
| Trans Date, Transaction Date | Transaction date | Keep only if needed; it can fall in the prior period. |
| Description, Details, Payee, Name | Description | Some files split merchant and detail across two columns. |
| Memo, Reference, Notes | Memo | Sometimes holds the merchant when Description is generic. |
| Amount | Amount (signed) | Confirm the sign: are withdrawals negative? |
| Debit, Withdrawals, Money Out | Debit | Positive numbers; credits empty. |
| Credit, Deposits, Money In | Credit | Positive numbers; debits empty. |
| Balance, Running Balance, Ledger Balance | Balance | Does it include pending items? |
| Check Number, Check No, ChkRef | Check number | Keep as text. |
| Type, Transaction Type | Type | Words vary by bank. |
Two columns deserve extra care. A column labelled "Details" or "Type" in one bank's file may hold the direction of the transaction, such as DEBIT or CREDIT, rather than a description. And a column labelled "Memo" may hold the useful merchant name while "Description" holds only a generic phrase. Look at a few rows before mapping.
A parser that reads many banks' files has to make this mapping from the values in each column, because the header alone does not settle it. The post on bank statement parsers explains how that works and where it goes wrong.
Bank statement CSV quirks: header rows and footer totals
Bank statement CSV quirks are the extra lines some files carry outside the transaction table: account summaries above the header, blank lines, footer totals, disclaimers, and pending transactions mixed in with posted ones. Each breaks an import that expects the header on line 1 and one transaction per line after it.
Summary blocks above the header. A download may open with several lines of account information, such as account name, number, date range, beginning and ending balance, before the column header. An import that reads line 1 as the header will treat "Account Name" as a column. Delete those lines from the import copy, but record the balances first: they are exactly what the tie-out needs.
Blank lines. An empty line between the summary and the table, or between sections, can end an import early or create an empty transaction. Remove them.
Footer totals and disclaimers. A final "Total" row looks like a transaction with a large amount. A disclaimer line may have one field instead of six. RFC 4180 says each line should contain the same number of fields, and a footer line usually breaks that rule. Remove both from the import copy.
Pending transactions. First National Bank's export page says a CSV download includes both processed and pending transactions, and pending ones show "(pending)" in the description. A pending row has not posted, so it belongs to no statement period yet. Filter out rows marked pending before comparing the file with a statement.
Repeated headers. A file stitched together from several downloads may repeat the header row in the middle. Every repeated header after the first should go.
Sort order. Some files list the newest transaction first. That does not break the format, but it reverses the running balance check. Sort by date, oldest first, before testing balances, and keep the original order if the bank's balance column depends on it.
A quick inspection catches all of these: open the CSV in a plain text editor, look at the first ten lines and the last ten, and count the fields on a few rows. Schema CPA keeps those summary balances in view: it ties each statement's balances to the next month's and exports the transactions to Excel or CSV. The documents section of the homepage lists the statement types it reads.