Credit Card Statement Conversion Workflow: From PDF to Reconciliation-Ready CSV/Excel
A practical, step-by-step workflow to convert credit card statements into import-ready CSV/Excel with fewer reconciliation surprises.
April 28, 202610 min read
Intro
A credit card statement is a PDF that mixes transaction rows with summary lines. If your export keeps totals inside the transaction dataset, reconciliation fails silently. This post gives a repeatable workflow: extract only transaction rows, normalize dates and signs, validate totals against the statement, then export to CSV/Excel for bookkeeping.
What you must preserve
| Field | Preserve because |
|---|---|
| Statement period | Wrong month breaks categorization |
| Transaction dates | Needed for sorting and matching |
| Merchant/description | Needed for coding |
| Amount sign | Needed for charge vs payment |
Checklist workflow
- Keep the PDF unchanged as source of truth.
- Extract transaction rows only (use preview).
- Normalize date formatting so Excel reads them as dates.
- Enforce one sign convention (e.g., charges negative, payments positive).
- Exclude summary/totals lines from the import sheet.
- Validate counts and net movement against the statement.
Common failure modes
- Summary rows included: filter by keywords like "Total".
- Sign flipped payments: confirm against a known payment line.
- Refunds treated as charges: watch for negative amounts and reversals.
CSV vs Excel decision
| Need next | Choose |
|---|---|
| System import | CSV |
| Human review | Excel |
Internal links
- Parse My Statement: /
- PDF to CSV: /blog/pdf-bank-statement-to-csv
- PDF to Excel: /blog/bank-statement-pdf-to-excel
FAQ
What’s the biggest mistake?
Including summary lines as transactions or flipping signs.
How do I validate before import?
Compare net movement and row counts to the statement.
FAQ
What is the biggest credit card statement conversion mistake?
Mixing summary lines with transaction rows, or flipping sign for payments vs charges.