GST in an ecommerce platform: what has to be right
Four things decide whether your invoicing survives an audit: place of supply, the slab from the HSN code, gapless serial numbers through the financial year, and credit notes that reference the invoice they reverse.
Place of supply decides the tax, not the shipping address alone
For goods, the place of supply is generally where the goods are delivered. If that state matches the seller's state, the order carries CGST and SGST. If it does not, it carries IGST. One order, two different tax lines, decided per order rather than set once in a settings page.
This is why a flat tax rate configured globally is wrong the moment you ship outside your own state, and why it stays quietly wrong until somebody reconciles a return.
The slab follows the HSN code
Rates are not per store or per category as you have defined it: they follow the classification of the item. Apparel changes slab by price point. Food sits across several slabs and some of it is exempt.
So the platform needs the HSN code on the product, and the rate has to be derived from it at the time of the order rather than typed in by whoever added the product. If a rate changes, historical orders must keep the rate that applied when they were placed.
Invoice numbers must not skip
A tax invoice series has to be continuous through the financial year. That sounds trivial until you have two people checking out at the same second, an order that fails at payment after a number was issued, or a system that generates the number optimistically and rolls back.
The correct behaviour is a number allocated once, atomically, and never reused or skipped. It is a small piece of engineering and it is the one most plugin stacks get wrong under concurrency, because it only fails when you are busy.
Returns produce credit notes, not adjustments
A refund is not an edit to the original invoice. It is a credit note that references the invoice it reverses, carries its own series, and reflects the same tax split the original did.
If your current process is somebody adjusting a sheet after a refund, that is the gap. It is invisible for months and expensive at exactly the wrong moment.
What to ask whoever is building it
Four questions, and you do not need to be technical to ask them. How does the platform decide CGST and SGST versus IGST on an order? Where does the rate come from, and what happens to old orders when a rate changes? What guarantees invoice serials never skip when two orders are placed at the same moment? What does a return generate, and does it reference the original invoice?
Vague answers to these are the most useful signal you will get in the whole conversation.
What people ask us about this.
You can, and plenty of stores do. It works while your orders are simple and your volume is low. The failures show up at the edges: interstate returns, concurrent checkout, rate changes mid-year, and the financial-year boundary. Whether that risk is acceptable depends on your volume and how much a filing correction costs you.
No, and be wary of anything that claims to. It produces correct, complete, exportable records; your accountant or your filing software does the filing. The platform's job is that the numbers it hands over are right and reconcilable.
Both are threshold-dependent obligations, so whether they apply depends on your turnover and what you ship. Where they apply they are integrations, and they are much easier to add to a platform that already models place of supply and HSN properly than to one that treats tax as a single configured percentage.
If this is your problem, start here.
Bring the version of this that is happening in your business.
A senior consultant, not a salesperson. If the answer is short we will just answer it, including when the answer is that you do not need us.