A company credit card statement looks enough like a bank statement that it usually gets treated as one. Two columns, a running balance, a list of dated lines. The import works, the entries go in, and the balance comes out backwards.
The reason is that a bank account and a credit card are opposite kinds of thing. A bank account is an asset: money the business has. A card is a liability: money the business owes.
Everything else follows from that one sentence, including the parts that catch people who already know it.
The rule, in four lines
A charge raises what is owed. A payment or a refund lowers it.
| What happened | The card ledger | The other side |
|---|---|---|
| A purchase, a fee, interest, GST on a fee | Credited | The expense or party is debited |
| A payment to the card | Debited | The bank is credited |
| A refund or a reversal | Debited | The party is credited |
So the card ledger sits under current liabilities, and in a healthy set of books it carries a credit balance that goes to nil when the statement is paid.
It is not a bank account and it should not be grouped as one, because a card ledger grouped under bank accounts quietly joins the bank balance in every report that totals that group.
Why the postings look identical to a bank, and why that is a trap
Here is the thing that makes this hard to teach. On paper, the two rules produce the same pair of entries.
Money out of a bank credits the bank. A charge on a card credits the card. Same side, same direction, and somebody who has only ever learned the mechanical version of the bank rule will post card rows correctly by accident for quite a long time.
The reasoning is different, though, and the reasoning is what you fall back on when something unusual turns up. "Money left the bank" is simply false of a card charge: no money left anything, an obligation was taken on. The day you meet a cash advance, an EMI conversion, a reversed charge or a dispute credit, the mechanical version gives you nothing and the liability version gives you the answer immediately.
It is also why the rule deserves to live separately from the bank rule rather than being folded into it. The day the card treatment changes for one of those cases, it should change without touching how an ordinary bank row posts.
Pro tip
Teach the card rule as "what we owe went up" and "what we owe went down", never as debit and credit by column position. The column version is right until it is suddenly not.
Reading the columns the issuer printed
A card statement marks its lines from the card holder point of view: a charge in the debit column, a credit in the credit column.
That is a column on a statement, not a side in your books. The debit column on the statement produces a credit to the card ledger. Reading the statement column as a Tally side is the actual mechanism behind most reversed card imports.
The practical check is one line. Find the biggest charge on the statement, follow it into the books, and confirm the card ledger was credited. If it was debited, every line is the wrong way round, and it is better to find that on line one than at the year end.
Important
A statement credit is not always a refund. Reversals, cashback, disputed amounts returned and the issuer own adjustments all land in the credit column and want different counter ledgers, even though the card side is debited in each case.
A card voucher carries no bank allocation
This one is specific and it bites at import time.
In Tally a bank allocation describes an instrument moving through a bank account: the mode, the instrument number, the date. It belongs to a bank account.
A card ledger is not a bank account, so a voucher on a card carries no bank allocation block at all. Attaching one, or importing card rows through a routine that always writes one, produces vouchers that either refuse to import or import carrying an instrument that does not exist.
The payment of the card bill is the exception, and it is not an exception at all once you see why: that voucher moves money out of the bank, so it has a bank allocation on the bank side, like any other payment. The card side of it is just the liability coming down.
Before you post, make it add up
A card statement is a worse document than a bank statement to read mechanically. Charges wrap across lines, merchant names run long, foreign currency lines carry two amounts, and a statement with a dispute on it may not foot cleanly at all.
So the one check worth doing every time is the totals the statement itself prints: opening balance, total charges, total payments and credits, closing balance. If what you are about to post does not reproduce those four figures, something was read wrong, and it is nearly always a wrapped line or a missed payment.
Greenote reads card statements through their own reader rather than the bank one, ties the entries it read against the totals the statement prints, and warns before posting whenever the two do not agree or the statement prints no totals to check against. A reading that ties posts quietly; anything else says so first.
Conclusion
One sentence covers the whole subject: a card is a liability, so a charge credits it and a payment debits it.
The practical consequences are that the ledger belongs under current liabilities and not under bank accounts, that the voucher carries no bank allocation, that the statement columns are the issuer point of view and not yours, and that the four printed totals are worth reconciling before anything is posted.
The same confusion in the other direction is covered in why an OD or CC account is a liability and not a bank account, and the import itself works the way any statement into Tally does. See what Greenote handles.
Turn bank statements into Tally vouchers on your own PC
Greenote reads 100+ Indian banks and posts clean vouchers straight into Tally, from your own PC. The statement is not uploaded, and nothing is typed by hand.
Free trial: 2 days or 10 statements, no card. Works with Tally Prime & ERP 9.
