Skip to main content
Statement ReconcileBank Statement Converter
Convert a statement

Credit Card Statement to CSV

Credit Card Statement to CSV

A CSV is what most accounting and expense tools actually want: no formatting, no merged cells, one row per transaction, and a header they can map to their own fields.

This page produces that file from a PDF card statement, with a column order that does not shift between statements, and it reconstructs the new balance from the extracted rows before offering you the download. A file that does not add up is a file you will spend an afternoon unpicking, so the check comes first.

Convert My Bank Statement$19 once · One or more statements · Up to 50 total pages · No account
Verified before paymentCSV and Excel (.xlsx)PDF never uploaded

What you get

  • One comma-separated, UTF-8 encoded CSV with a single header row and no blank spacer rows between statement sections.
  • Seven columns in a fixed order — Date, Posted Date, Description, Debit, Credit, Amount, Balance — so an import mapping you save once keeps working next month.
  • Dates written as YYYY-MM-DD in both date columns, which sorts correctly as text and is accepted by importers without a format hint.
  • An Excel workbook of the same rows, with a Transactions sheet and a Statement Summary sheet, included in case you want to eyeball the data before importing it.

$19 once, for one or more statements up to 50 total pages. Both formats and verification reports are included.

The check

Checking the card balance before the file leaves

An import is hard to unpick. Once a few hundred card lines are sitting in a ledger, finding the one that was misread means reconciling the account by hand, which is exactly the work you were trying to avoid.

So the arithmetic is settled first. The extracted rows are totalled by direction and pushed through the card equation, starting from the previous balance the issuer printed and ending, if the extraction was complete, on the new balance. Any category totals on the statement are compared as well.

That comparison is decimal arithmetic in our code, done after extraction, and its result is shown to you with the figures behind it. If the numbers do not agree, the paywall never appears and nothing is charged.

Equation used

Previous balance + purchases + fees + interest − payments − credits = new balance

Computed with exact decimal arithmetic in our own code, separately from whatever read the page. You see both sides of this equation, and the difference between them, before the payment step appears.

Step by step

How this conversion runs

  1. 01

    Pick the statement PDF

    Choose the file in your browser. Nothing about the PDF leaves your machine; only the text extracted from it is sent for parsing, and it is not kept afterwards.

  2. 02

    Rows are built from the page geometry

    Column positions in the text layer decide which figures are charges and which are credits, and merchant names that wrapped onto a second line are stitched back onto their row.

  3. 03

    Dates are normalised

    Where the issuer prints a transaction date and a posting date, both are kept and both are converted to ISO form, with the day and month order read from the document.

  4. 04

    The equation is checked and shown

    You see the previous balance, the new balance, the totals the engine derived, and whether they meet, all before any payment step.

  5. 05

    Download the CSV

    One $19 payment releases the CSV and the workbook for that statement. Nothing recurring, and no account to create.

Transaction date and posted date are not the same day

Card issuers usually print two dates. The transaction date is when the purchase happened; the posting date is when the issuer applied it to the account, often one to three days later and sometimes on the other side of a month boundary.

Which one your destination wants depends on what it is for. Expense reporting and sales tax work usually follow the transaction date, because that is when the spend occurred. Matching a statement balance line by line follows the posting date, because that is the order the balance moved in. Rather than choose for you, the CSV carries both in their own columns and leaves the mapping to you.

  • Date holds the transaction date wherever the issuer printed one
  • Posted Date holds the posting date, and is left empty rather than filled with a guess when the statement gives only one date
  • Both are ISO formatted, so a December purchase posted in January still sorts into the right place
  • The Balance column follows posting order, since that is the order the issuer applied the lines in

Fees, interest, and the categories your ledger cares about

In a ledger, a finance charge and a hotel bill do not belong in the same account. Interest is a cost of borrowing, an annual fee behaves more like a subscription, and a foreign transaction fee usually attaches to whichever purchase triggered it.

The extractor keeps those lines separate instead of folding them into spending, using the headings and columns the issuer printed. Descriptions come through as written, so a rule in your accounting software that looks for an interest or fee label will match reliably. The accompanying workbook also totals fees and interest for the period, which is a quick way to confirm afterwards that your ledger picked them up the way you intended.

Refunds have to keep their direction

A refund is the line that most often gets mangled on the way into a ledger. It reduces the balance owed, so its direction is opposite to a purchase — but stripped of that direction it looks identical to a charge, and the result is spending counted twice for something that went back to the merchant.

In the CSV a refund sits in the Credit column and appears in the Amount column with the sign that reduces the balance, exactly as a payment does. The difference between the two is in the description, not in the arithmetic, so if your import rules need to distinguish a merchant credit from a cardholder payment they should key off the description text.

The same discipline applies to chargebacks and statement credits: if the issuer printed the line as a reduction of the balance, that is how it is exported, because that is how it has to behave for the period to add up.

Scope

What this handles, and what it refuses

The refusals are the important half. Each one is a case where a converter could produce something plausible and wrong.

Handled

  • Card statements that print a previous balance and a new balance for the period
  • Layouts with both a transaction date and a posting date, and layouts with a single date per row
  • Sectioned statements where purchases, payments, fees, and interest appear under their own headings
  • Amounts marked CR or DR, wrapped in parentheses, or written with a comma decimal separator
  • Statements of up to 50 pages, exported as one CSV

Not handled

  • Image-only PDFs, including statements photographed or scanned from paper
  • Statements protected by a password that has not been removed
  • Files that cover more than one card account in the same document
  • Statements with no itemised activity, where there is nothing to reconcile against the balances

Formatting problems that come up with these statements

  • Import tools reading a single amount column and assuming every value in it is spending
  • Files that repeat the statement header partway down, because the PDF had page breaks the converter ignored
  • Amounts arriving as text because a thousands separator travelled with the value
  • Two date columns collapsed into one during extraction, so the month a purchase belongs to becomes a coin toss
  • Descriptions truncated at the point where the PDF wrapped the line, leaving half a merchant name

Questions about this conversion

Which date column should I map to my accounting software?

Map the transaction date if you are recording when the spend happened, which is the usual choice for expense claims and tax. Map the posted date if you are matching the statement balance line by line. Both are in the file, so you do not have to re-export to change your mind.

Is the CSV encoded so accented merchant names survive?

Yes, the file is UTF-8. Merchant names with accents or non-Latin characters come through as printed. If your import tool asks you to pick an encoding, choose UTF-8 rather than a regional code page.

Are the description fields quoted?

Fields are quoted where they need to be, which in practice means descriptions containing a comma or a quote character. Everything else is written plain, so the file opens cleanly in a spreadsheet and parses cleanly in a script.

Can you import into my accounting package directly?

No. The output is a CSV and an Excel workbook, and loading either one is a manual step in whichever tool you use. There is no integration and no API.

Can I re-download the CSV later?

Save the files when you download them. We do not keep your statement data after the conversion, so treat the download as the copy that matters and store it wherever you keep your records.

Related conversions

Find out whether your statement can be verified

It costs nothing to try. The $19 payment step only appears once the extracted transactions have been checked against your statement.

Convert My Bank Statement