GST rates and classifications change. When they do, every billing system in the country has the same week: finding where the rate lives, changing it, and discovering what broke.
The design principle is that a tax rate is not a property of a product. It is a property of a product, in a place, at a point in time. Storing a single rate column on the product table means you cannot represent history, and history is precisely what you need when a credit note is raised against last quarter's invoice.
Model rates as dated records. A table of rate rules with an HSN or SAC code, a jurisdiction, a rate, and a validity period lets you enter a future change before it takes effect and keeps the old rate available for adjustments. The billing code looks up the rate applicable at the transaction date rather than reading a constant.
Store the computed tax on the invoice line, not just the rate. Recalculating tax on an old invoice from current rules will eventually produce a different number than the one filed, and the filed number is the one that matters. The invoice is an immutable record; treat it that way.
Rounding needs a documented rule, applied in one place. Rounding per line and rounding on the total produce different results, and a discrepancy of a rupee against a customer's own calculation generates a support ticket and, occasionally, a reconciliation dispute that costs far more than a rupee.
Test the change before it takes effect, with a date override. A system where you cannot ask 'what would this invoice look like next month' forces you to test in production on the day the rate changes, which is the worst possible time to find out that the credit note logic reads the current rate.
