Converting a credit card statement looks like converting a bank statement, and then everything goes subtly wrong: your purchases show up as income, the balances run backwards, and the totals refuse to reconcile. That's not a broken converter. Card statements genuinely follow different rules, and knowing them takes the job from frustrating to routine.
The core difference: a card is a liability
A current account is an asset — money you have. A credit card is a liability — money you owe. So the balance moves in the opposite direction: spending increases it, paying reduces it. And statements almost always print what you owe as a positive number, because "you owe €1,240.00" reads more naturally than "−1,240.00".
That printing convention is the source of nearly every downstream error. Take the numbers off the page as-is and you've told your spreadsheet that a €49 purchase is €49 of income.
The fix is to convert to a single consistent perspective — the account holder's — before doing anything else:
| On the statement | In your spreadsheet |
|---|---|
| Purchase / charge | Negative |
| Interest, annual fee, late fee | Negative |
| Payment you made to the card | Positive |
| Refund / chargeback / cashback | Positive |
| "Previous balance" of 1,240.00 owed | −1,240.00 |
| "New balance" of 890.00 owed | −890.00 |
Do that and the arithmetic works exactly like a bank statement: previous balance + all transactions = new balance. It's the same reconciliation check, just applied to a negative starting point.
The four other things card statements do differently
1. Two dates per transaction
Card statements usually print a transaction date (when you bought it) and a posting date (when it hit the account). They can differ by days, and around a statement boundary that determines which month a purchase falls in. For expense reports and tax periods, the transaction date is normally what you want — but pick one, keep both if you can, and stay consistent.
2. Foreign transactions hide their true cost
A purchase abroad typically appears converted into your billing currency, with the original amount and currency squeezed into the description line. The rate used often already carries a markup, and a foreign transaction fee may appear as its own line or be baked into the converted figure. When converting, keep the original-currency detail — it's the only way to trace what a purchase really cost, and it's the first thing anyone reviewing travel expenses asks about.
3. Payments to the card are transfers, not income
The €400 you paid off last month is money moving between two accounts you own. In bookkeeping terms it's a transfer, not revenue. If you're combining card and bank data — as in a year-end spreadsheet — mark those rows clearly, or you'll double-count: once as a payment leaving your current account, once as a "credit" arriving on the card.
4. Instalment plans and minimum payments confuse totals
Many cards now split large purchases into monthly instalments, showing only this month's portion as a charge with the rest referenced elsewhere. Your statement total won't match what you actually spent that month, and that's correct behaviour — just don't reconcile against your own expectations, reconcile against the printed balances.
Getting the data out
The manual route
If the PDF has a text layer, Data → Get Data → From PDF in Excel will pull tables out, exactly as with a bank statement. Expect the usual clean-up plus one card-specific job: flipping signs. Statements that print charges and payments in separate columns are the easy case — one column becomes negative, the other positive. Statements using a trailing CR mark for credits are the fiddly case, since you have to parse the mark before the number is usable.
The direct route
Statement Mill converts credit card statements the same way it converts bank statements — same upload, same exports — with the liability conventions above applied automatically. Charges come out negative, payments positive, and previous/new balances are treated as amounts owed, so the reconciliation check still runs and still means something. Scans and phone photos work too, which matters for cards more than most: people photograph card statements far more often than bank ones.
Importing into accounting software
One setup detail decides whether this works: create the card as a credit card or liability account, not a bank account. QuickBooks and Xero both have a card account type for exactly this. Import into a bank-type account instead and every charge and payment lands the wrong way round, with a reconciliation that can never balance no matter how many times you re-import.
After that, importing is ordinary: QBO or OFX where supported, otherwise CSV in the layout your software expects. And if you're claiming business expenses on a personal card, keep the original statement — the converted spreadsheet is your working copy, but the PDF is the evidence.
The check that tells you it worked
Same test as always, adjusted for the liability sign:
=<previous balance, negative> + SUM(amount column)That must equal the new balance, also negative. If it does, every charge, payment, fee and refund was read correctly and nothing was dropped. If it doesn't, the gap is in the data, and no amount of formatting will fix a missing row.
Every Statement Mill export runs this automatically per statement and shows the result before you download — try it with your latest card statement: 3 pages with no signup, 20 free with an account, no credit card required and no trial timer.