You convert a credit-card statement, open the exported file, and notice something looks wrong: every purchase you made is showing as a negative number, and the payment you made to the card is showing as positive. The opposite of how it looks on the statement itself.
This is not a bug. It's the accounting sign convention, and once you understand why, it actually makes more sense than the consumer-facing view your statement gives you.
The short answer
Accounting software like QuickBooks and Xero treats your credit card as a liability account— a thing you owe money on. From the liability's perspective:
- A purchase increases what you owe → it's a debit → negative in the import file
- A payment to the carddecreases what you owe → it's a credit → positive in the import file
The OFX/QBO standard that QuickBooks reads, and Xero's bank-statement CSV import, both follow this convention. They have to — otherwise every time you imported a statement, your liability balance would go the wrong direction.
Why it feels backwards
Your statement shows you transactions from your point of view — the cardholder. From your perspective, a purchase uses upyour credit (or it's “a charge,” visually positive on the statement). A payment reducesthe balance owed (shown as a negative number with a CR or “payment” flag).
Accounting software shows you transactions from the card's point of view — specifically, the liability account that represents the card on your books. Money flowing into the card (a payment) is a positive flow. Money flowing out (a purchase, technically a draw against your credit line) is a negative flow.
Same transactions, opposite sign. Both are correct, given who you're asking.
A quick sanity check
Imagine a tiny example:
- Starting balance owed: $0
- You buy a $100 gadget on the card → balance owed becomes $100
- You pay $40 toward the card → balance owed becomes $60
Now think about what the import file should contain for QuickBooks to arrive at $60. The starting balance was zero. Two transactions get added together:
- If the gadget were +100 and the payment were −40, total = +60 (wrong sign — you'd owe a negative balance)
- If the gadget were −100 and the payment were +40, total = −60 → which, when added to a liability account, means the balance owed is $60. Correct.
That second case is the OFX/QBO convention, and it's what every good converter produces.
How our converter handles this
Your statement comes in with the consumer convention. The converter reads it that way internally — purchases positive, payments negative — so what you see in the preview table feels natural.
But when you click the QuickBooks or Xero export tab, we flip the signs automatically so the resulting file follows the accounting convention. There's a one-line note above the preview that tells you this is happening, and the preview itself updates to show the sign-flipped amounts — so what you see is exactly what's in the file.
Excel and plain CSV exports keep the human convention (purchases positive, payments negative), because those are usually opened in a spreadsheet for human reading rather than imported into accounting software.
What it looks like in QuickBooks after import
When you open the credit-card account register in QuickBooks after a successful import, transactions usually display the human way — purchases as positive amounts in the “Charge” column, payments as positive amounts in the “Payment” column. The sign flip happens in the import file, then QuickBooks renders it back to a reader-friendly format. You never have to think about the underlying convention again.
If the signs look wrong after import
If you imported and your credit-card liability is moving the wrong direction — going down when you make a purchase, or up when you make a payment — the converter you used probably didn't flip signs and is producing files with the consumer convention rather than the accounting one.
The fix: re-export from a converter that handles this correctly (ours does), delete the bad transactions in QuickBooks, and re-import.
Bottom line
Negative purchases and positive payments in your import file aren't a bug — they're the accounting world's side of a conversation about the same transactions. Once you know which side of that conversation you're on, the convention stops being confusing.