A contra entry records money moving between accounts the same entity already owns: cash into the bank, bank into cash, one bank account into another. Nothing is earned, nothing is spent, and no outside party is involved. The total assets of the business do not change.
That is exactly why getting it wrong is expensive. A contra booked as something else creates income or expenditure out of an internal transfer, and because both sides of the movement are real bank transactions, the ledger still reconciles perfectly afterwards.
Booked as a payment and a receipt
The most common error, and the most consequential. A transfer of five lakh from the current account to the OD account gets recorded as a payment of five lakh out of one and a receipt of five lakh into the other.
Both entries are individually defensible. The bank statements show exactly those movements. But the books now contain an outward payment to a party and an inward receipt from a party where no party exists, and depending on how the ledgers were set up, that can flow into turnover-adjacent figures on both sides. On a client with regular treasury movement between accounts, the inflation is not small.
The test is simple: if both sides of the transaction are accounts appearing in this client's own balance sheet, it is a contra. Picking the right voucher every time covers the decision in full.
Posted in the wrong direction
A contra runs both ways. Cash withdrawn from the bank is a contra. Cash deposited into the bank is also a contra. The voucher type is a classification of what kind of transaction it was, and it says nothing at all about which way the money went.
Deriving direction from the voucher type is a real and well-documented failure. Treat every contra as a withdrawal and every deposit posts backwards: the bank ledger is credited when it should be debited, and the balance moves by twice the amount rather than not at all.
The reliable signal is the statement's own running balance. If the balance after the row is higher than the balance before it, money came in and the bank ledger is debited. That is arithmetic, and it does not depend on reading the narration correctly.
Important
This error is systematic rather than occasional. Whatever produced it applies the same rule to every row, so a file does not contain one reversed deposit. It contains all of them.
Counted twice, because it appears on two statements
An internal transfer shows up on both accounts: as an outflow on the sending statement and as an inflow on the receiving one. Import both statements, as you would for a client with three bank accounts, and the same single movement is now in the books twice.
It is one of the few errors that is easier to see in a party-wise summary than in a ledger. Two entries, same amount, opposite direction, dates a day or two apart, and no external counterparty on either. In date order they are hundreds of rows apart and look unremarkable.
If it has already happened, note that removing them is its own job: undoing a bad Tally import covers doing it without leaving half the pair behind.
Pro tip
Reconcile the pair before deleting anything. Two entries of equal and opposite amount are not automatically a duplicate contra: a genuine payment and a genuine refund look identical in a summary.
Cash movement that is not what it appears
Two cases worth separating.
The first is a bank fee folded into a cash withdrawal. The row shows one amount, part of which is the bank's charge. Book it whole as a contra and the fee lands in the client's own cash in hand rather than an expense head, so cash in the books drifts from cash in the tin.
The second is direction on a cash deposit. A deposit into the client's own account is a contra, but a deposit by a customer paying in cash is a receipt from an outside party, and the two look nearly identical on the statement. The narration is often the only thing separating them, which is why entries with blank or transport-only narrations deserve attention during ledger scrutiny.
Why none of this shows up in a reconciliation
Every error above involves real transactions in real amounts on real dates. The bank agrees with all of them. A reconciliation compares your closing balance to the bank's, and in each case the balance is either correct or wrong by an amount that a second error conveniently offsets.
That is the argument for scrutiny as a separate exercise. What catches a misclassified contra is looking at what the entry was, not whether it added up. In practice: check every entry whose counterpart is another bank ledger or the cash ledger, and check both directions against the running balance.
Conclusion
Contras fail audits in four ways: recorded as payment and receipt, posted in the wrong direction, counted twice across two statements, and confused with genuine cash receipts. All four reconcile cleanly, which is why they survive to the audit.
Greenote takes direction from the statement's running balance rather than from the voucher type, recognises transfers between a client's own accounts, and separates a bank fee that was folded into a withdrawal. It runs on your own PC. See how it handles the classification.
Turn bank statements into Tally vouchers offline
Greenote reads 100+ Indian banks and posts clean vouchers straight into Tally, fully on your PC. No uploads, no cloud, no manual entry.
7-day free trial, no card required. Works with Tally Prime & ERP 9.
