GST decided by the transaction, not by the person entering it

Your branch carries a state code; so does every vendor and customer. When a purchase order, goods receipt, supplier invoice or sales invoice is raised, the two are compared: same state, and the tax splits into CGST and SGST; different states, and it becomes IGST. The journal is posted to separate ledger heads for each — input CGST, input SGST, input IGST, and the matching output heads on sales — so your auditor sees exactly what they expect rather than one pooled tax account.

Each material carries its HSN code and GST rate as master data you set once. Every document that touches that material inherits them, so the same item cannot be taxed at 12% on one invoice and 18% on the next because two people typed it differently. Rates are capped and validated on entry, which quietly removes a whole class of error.

This is where systems usually go wrong. A sales return has to reverse the outputtax that the original invoice raised — not the input credit sitting on your purchases. A purchase return does the opposite. Ezee ERP keeps the two apart: which set of heads to touch is decided by the kind of document, and which direction to post is decided by whether the note raises or reverses. Get that wrong and your returns disagree with your books by exactly the tax amount.

You get input-versus-output GST summaries and can trace any figure back to the documents behind it, alongside the trial balance, balance sheet and AP/AR ledgers. What is not built yet is filing: there are no GSTR-1 or GSTR-3B exports and no e-invoice or e-way bill integration. If statutory filing is your main requirement, keep the tool you file with today and use this for purchase, stores and production — plenty of plants do exactly that.