Most write-ups on TallyPrime treat voucher types as a vocabulary list to memorize. That's the wrong frame. A voucher isn't a label — it's a schema. Pick the wrong one and the transaction still saves, no error thrown, but your ledgers, cash-flow reports, and (if it's GST-relevant) your tax filings quietly drift out of sync. This is a fast, no-fluff reference for what each voucher actually does and where people get it wrong.
What a Voucher Actually Is
Every transaction in Tally — a sale, a purchase, a bank transfer — is recorded through a voucher, which is really just a typed record with a specific effect on your ledgers. The type you choose determines how that transaction is processed downstream: which reports it feeds, whether it touches stock, whether it's tax-relevant.
The Six Vouchers You'll Use Constantly
- Sales (F8) — every invoice issued to a customer; this is also what feeds your GST returns
- Purchase (F9) — goods or services bought from a vendor
- Payment (F5) — money leaving the business: rent, salaries, vendor payments
- Receipt (F6) — money coming in: customer payments, refunds
- Contra (F4) — transfers between your own cash and bank accounts, nothing else
- Journal (F7) — non-cash adjustments: depreciation, provisions, corrections
Beyond these six, TallyPrime also has Debit Notes and Credit Notes for returns, plus Stock Journal and Physical Stock vouchers for inventory movement and reconciliation. For the complete set — including shortcut keys and worked examples for each — this full breakdown of TallyPrime voucher types is a solid reference to keep on hand rather than re-deriving from memory every time.
Accounting Vouchers vs. Inventory Vouchers
Accounting vouchers (Sales, Purchase, Payment, Receipt, Contra, Journal) hit your ledgers directly and drive your P&L and Balance Sheet. Inventory vouchers (Stock Journal, Physical Stock) track goods movement without necessarily touching financial ledgers. The exception: Sales and Purchase vouchers do both jobs simultaneously — one entry updates stock quantity and records revenue/expense. That dual behavior is exactly why voucher selection at entry time isn't a formality.
Common Failure Mode: Journal Instead of Payment
The most frequent beginner mistake is recording an actual cash transaction — say, paying office rent — as a Journal entry instead of a Payment voucher. Nothing breaks visibly. But your cash-flow report no longer reflects reality, and by the time someone notices during reconciliation, it can take real effort to trace back which entries were misclassified.
Quick Reference
| Voucher | Shortcut | Use |
|---|---|---|
| Sales | F8 | Customer invoices, GST-relevant |
| Purchase | F9 | Vendor purchases |
| Payment | F5 | Cash/bank outflows |
| Receipt | F6 | Cash/bank inflows |
| Contra | F4 | Internal cash/bank transfers |
| Journal | F7 | Non-cash adjustments |
Takeaway
If you're building any kind of integration, import script, or reconciliation tooling around Tally data, voucher type is the field to validate first — it's the difference between clean, queryable ledgers and a dataset that technically has all the numbers but none of the structure. Get the classification right at the point of entry, and everything downstream — reports, filings, audits — gets simpler by default.
Top comments (0)