GST Entries in TallyPrime: Classification

The thing to understand about GST in Tally is that the return is not prepared at month end. It is assembled from decisions made at the moment each voucher was entered, and a return that will not reconcile is almost always a classification problem three weeks old.

This page covers the decisions rather than the menu paths, because the paths move between versions and the decisions do not.

What classification actually does

When GST is enabled, ledgers and stock items carry tax attributes — the nature of the supply, the rate, and whether the item is taxable, exempt or nil-rated. Every voucher inherits those attributes.

Tally then builds the return from what it inherited. It does not re-examine your intention. If a ledger was set up with the wrong rate in April, every invoice raised against it since April carries that rate, and the first sign of trouble is a return that does not agree with your own sales figure.

Set the ledgers up carefully once. It is much cheaper than correcting six months of vouchers.

The four errors that cause most mismatches

1. Place of supply, and the intra- versus inter-state split

This decides whether the transaction attracts CGST plus SGST, or IGST. It follows the place of supply rules, not simply where you are sitting. Get it wrong and the tax lands in the wrong heads — the total may even look right while the return is wrong.

2. The wrong rate on the ledger or item

Rates change by notification. A ledger created two years ago carries whatever was correct then. Check the rate on setup and again after any change, because nothing prompts you.

3. Exempt, nil-rated and non-GST treated as interchangeable

They are reported separately and they are not the same thing. Collapsing them produces a return that misstates each.

4. Reverse charge missed

Where reverse charge applies, the liability is yours as recipient. If the voucher does not carry that attribute, the liability simply never appears, and it is invisible until someone asks for it.

Reconcile before you file, not after

Three checks, in this order. They take minutes and they catch nearly everything.

1. Your sales figure against the outward supplies in the return. A difference here is a classification error, and it is easier to find now than after filing.
2. Purchases against GSTR-2B. This is the one that matters most. Credit only exists where your supplier has actually reported the invoice, so anything in your register and absent from 2B is a supplier problem to chase, not a credit to claim. The input tax credit rules set out when a claim is valid.
3. Blocked and reversible credits. Section 17(5) blocks credit on specified supplies even where they are used in the course of business, though several of those blocks carry exceptions that depend on how the supply is used. The 180-day payment rule forces reversal on unpaid invoices. Neither is something Tally will raise for you.

The ordering that is now structural

File GSTR-1 before GSTR-3B. The outward liability in 3B is auto-populated from GSTR-1 and cannot be edited, so the sequence is no longer a preference. See filing GSTR-1 and filing GSTR-3B.

The practical consequence for your Tally work is that errors must be found before GSTR-1 goes in. After that they are corrections rather than edits.

If it has already gone wrong

Fix the ledger first, then the vouchers, then re-check the return. Fixing vouchers while the ledger is still wrong means you will do it twice.

And check what the delay costs before you rush: the late fee is capped but the interest is not, so a correct return filed slightly late usually beats a wrong one filed on time.

Error, symptom, fix

The four classification errors above share a pattern: the mistake happens once, at setup or at entry, and the symptom only shows up later, in the return. This table connects what you are seeing back to what caused it.

Error	Symptom in the return	Fix
Wrong intra-state / inter-state classification	Tax appears under CGST and SGST where it should be IGST, or the reverse; totals can look correct while the split is wrong	Correct the place of supply on the ledger, then re-check every voucher entered against it since the error started
Outdated rate on the ledger or stock item	Your own sales figure does not match the outward supply value shown in the return	Update the rate on the ledger first, then correct the affected vouchers; do not touch vouchers before the ledger is right
Exempt, nil-rated and non-GST treated as one category	The exempt and nil-rated figures in the return do not match what you know you sold	Reclassify each item correctly; the three categories are reported separately and need separate ledgers or item settings
Reverse charge not flagged	A liability you know you owe simply never appears anywhere in the return	Add the reverse charge attribute to the ledger or voucher and account for the liability directly; it will not appear on its own after the fact

A concrete version of the reverse charge row: a business buys transport services from a goods transport agency where reverse charge applies, and the purchase voucher is entered as an ordinary purchase without the reverse charge attribute. Tally has no reason to raise the liability, because nothing on that voucher told it to. The gap surfaces only when someone reconciles the return against invoices they know exist, by which point a quarter or more may have gone by.

Credit and debit notes need the original invoice, not a fresh one

A credit or debit note is an adjustment to a specific earlier invoice, and the return treats it that way only if it is linked back to that invoice. Entered as a standalone voucher instead, with no reference to the original sale, it is picked up as a fresh supply rather than an adjustment.

A concrete version: a sales return of Rs 20,000 against an invoice raised the previous month is entered as a fresh sales voucher rather than a credit note against that invoice. That adds Rs 20,000 to this month’s outward supply and tax liability that should not be there. The original invoice still stands on record as if the return never happened. This is a classification mistake in the same family as the four above, made at the moment the note is entered rather than at ledger setup, which is why it survives even careful ledger housekeeping.

The HSN summary only reports what the ledger or item was told

GSTR-1’s HSN summary is built directly from the HSN or SAC code carried on the stock item or ledger, the same way the tax rate and place of supply are. A blank or generic code produces a blank or generic line in that summary, not an error message. A stock item created some years ago under a shorter code that was correct for a smaller turnover band will keep reporting at that shorter length after the business grows into a band requiring more digits. Nothing prompts a review of an existing item’s code.

How many digits are required depends on your turnover band, and that threshold is set by notification and has moved before, so confirm the current requirement on the GST portal rather than assuming the rule you learned still applies. Whatever the required digit count is at the time, the underlying discipline is the one this whole page is about: get it right on the item once, at setup, covered in TallyPrime for accountants: what to learn first.

If e-invoicing applies to you, classification still comes first

Above the government-notified turnover threshold, invoices need an IRN, an invoice reference number generated through the e-invoicing portal, before they count for GST purposes. That threshold is itself a notified figure that has been lowered more than once, so confirm your current obligation rather than relying on what applied last year.

E-invoicing sits on top of classification, not instead of it. The rate, the place of supply and the HSN code on the underlying ledger or item still drive what the invoice reports. E-invoicing only adds the requirement to register that invoice with the portal and receive an IRN back before it is valid for the return. One detail worth knowing before it matters: an IRN can generally only be cancelled within a short window, commonly 24 hours, directly through the e-invoicing portal. After that window, the only way to undo it is a credit or debit note, which brings you back to the point above about linking that note to the original invoice.

Amending an invoice after the return has already gone in

GSTR-1 does not get reopened for the period it was filed in. An invoice discovered wrong after filing is corrected in a later period’s return, using the amendment tables built for exactly this: table 9A for amended B2B invoices, and the equivalent tables for amended credit and debit notes. The correction carries the invoice number and date of the original, plus the revised figures, and it lands in whichever period you are filing when you catch the mistake, not the period the invoice belonged to.

This is one more reason the reconciliation checks above are worth doing before filing rather than after. An error caught before submission is a five-minute edit, and the same error caught afterward is a correction that has to be tracked across two return periods and reconciled again.

Frequently asked questions