Payment voucher vs Receipt voucher in Tally

The rule

Money out is Payment. Money in is Receipt.

A Payment voucher (shortcut F5) records money leaving your bank account — the bank ledger is credited, and the ledger it's paid to (an expense, a vendor, a salary account) is debited. A Receipt voucher (F6) is the reverse — money arriving credits the destination ledger (income, a customer, a refund) and debits the bank ledger. On a bank statement, that's simply the Withdrawal/Debit column becoming a Payment voucher, and the Deposit/Credit column becoming a Receipt voucher.

Why it matters

Getting the type wrong flips your reports

A Payment voucher and a Receipt voucher for the same amount aren't interchangeable — swap them and your bank ledger's balance, and every report built on it, comes out wrong in the opposite direction. This is exactly why an automated converter has to read which column a transaction actually printed in, rather than guess from the amount alone: bank2tally maps a statement's Withdrawal column to Payment vouchers and its Deposit column to Receipt vouchers, keyed to each bank's real column order (some banks, like ICICI, print Deposits before Withdrawals — the reverse of most banks) so a reversed column layout can't flip a credit into a debit.

Both are always balanced

A voucher can't post half a transaction

Whichever type it is, a Payment or Receipt voucher always has two legs of equal value — one against the bank ledger, one against whatever ledger the transaction maps to. A voucher that only affects one ledger isn't valid Tally data; every voucher bank2tally generates carries both legs by construction, which is also why an "unbalanced voucher" error on import (see our import errors guide) almost always points to a hand-edited or different tool's file, not bank2tally's own output.

A concrete example of why column position matters

Punjab National Bank prints its columns in a different order

Most banks print a statement with the narration first and the withdrawal, deposit, and balance figures after it — read left to right, that's the order a human eye expects too. Punjab National Bank is a genuine exception: its layout puts withdrawal, deposit, and balance columns before the narration column, not after. A converter that assumes "narration always comes first, amounts always come last" would silently misread every PNB row — not crash, just quietly produce a wrong Payment-vs-Receipt classification, because it grabbed the wrong column for the wrong value. This is exactly why bank2tally reads each bank's actual column header row before touching a single transaction row, rather than assuming one universal layout applies everywhere — and it's also why PNB specifically isn't supported yet; its layout needs a different parsing approach than the column-position method every other bank here uses (see our note on PNB support for the full explanation).

Questions