If a Mumbai buyer places an order at 22:40 on a Tuesday with a Maharashtra shipping address, pays via Razorpay at 22:41, then edits the address to Gujarat at 09:15 the next morning before dispatch — which invoice is the legal one, and what happens to the CGST/SGST already booked against the first?
We have been chewing on that question for the better part of a year and we still don't love our answer. The post below is what we currently do. It is not necessarily what we think a reader should do. If you have a cleaner workflow signed off by a CA who actually looks at e-commerce books, we would like to hear it — we will come to that at the end.
What the law actually fixes at the moment of invoice
The short version, with the usual caveat that we are engineers not chartered accountants: under Section 12(2)(a) of the IGST Act, the place of supply for goods where movement is involved is the location where the movement terminates for delivery to the recipient. Fine. But the tax invoice itself — the document — is required to carry the place of supply and the correct tax split (CGST+SGST if intra-state, IGST if inter-state) at the time it is issued. Rule 46 of the CGST Rules spells out what has to be on the invoice, and Rule 53 governs how you fix it afterwards via a credit or debit note.
So the awkward bit. Once the invoice is issued, the place of supply recorded on it is a fact about that document, not a prediction about where the goods will actually land. If the destination changes after the document is cut, you cannot quietly overwrite the invoice — you have to issue a credit note to reverse the original and raise a fresh invoice reflecting the new place of supply. Rule 53 is reasonably clear on the mechanics. It is less clear on the timing edge cases, which is where everyone we have talked to seems to improvise.
We have had this argument internally more than once. The build team's instinct is to treat the invoice as mutable until dispatch — just update it in place. The finance side pushes back hard: once a tax invoice is issued, it enters the GSTR-1 universe and you cannot pretend it did not exist. Finance wins that argument. Mostly.
Why the WooCommerce + Razorpay path misses the address mutation entirely
Here is the specific pattern that forced us to actually think about this properly. An order comes in from a buyer in Pune — Maharashtra billing, Maharashtra shipping, invoice generated with CGST 9% + SGST 9%. The buyer then calls the client's customer service team the next morning and asks to redirect the parcel to Ahmedabad (change of plans, visiting family, the usual). The CS executive edits the shipping address on the WooCommerce order screen. The warehouse picks, packs, and ships. Goods cross into Gujarat.
Nobody regenerates the invoice. Nobody issues a credit note. The invoice PDF attached to the order is the one that was generated at payment time, still showing Maharashtra as the place of supply, still showing CGST+SGST. The e-way bill (which the warehouse team generates separately) correctly shows Ahmedabad as the destination. So the shipping paperwork says Gujarat and the tax paperwork says Maharashtra, and nobody notices until someone reconciles GSTR-1 against the e-way bill portal data a quarter later and finds the outward supply lines don't line up. By then the original invoices are sitting in a filed return, and unpicking a batch of four or five of them takes the better part of two days.
The thing we had not internalised: WooCommerce fires a hook called woocommerce_order_edit_address (and, depending on the path, woocommerce_process_shop_order_meta or woocommerce_update_order) when an admin changes the address from the order screen. The hook is there. It fires. The problem is that none of the standard GST invoicing plugins we have tested listen to it. We have tested a handful — not naming them because the maintainers are generally responsive and we don't want to pile on, but the pattern is consistent across all of them. They hook into order creation and payment completion. Address mutations after that point sail past.
Which means the silent failure mode is specific and nasty: an admin edits the shipping address from the WooCommerce order screen, the order moves to processing, the invoice PDF is not regenerated because no plugin thought to regenerate it, and the warehouse ships against an address that does not match the tax document. If the state changes, the tax split is now wrong. If only the pincode within the same state changes, you got lucky — the invoice is still legally valid.
Aside: the worst version of this we saw was an implementation where the invoice PDF was generated on-demand from live order data, so an address change would silently rewrite the "original" invoice without any credit note trail at all. Looks fine until the first audit, at which point there is no credit-note trail to point at and the only honest answer is that the original invoice was silently rewritten. That client is not with us anymore, which is a separate story.
The credit-note-and-reissue workflow we use, and where it still breaks
What we do now, give or take, on builds where we own the invoicing layer: hook into woocommerce_order_edit_address (shipping variant) and the admin-side order update path, compare the state code before and after, and if the state code hasn't changed, do nothing — the invoice is fine. If the state code has changed, flag the order with a meta key (something like _pos_mutation_pending) and surface a notice on the order screen. Do not auto-regenerate anything yet. We tried auto-regeneration early on and it created more problems than it solved, because sometimes the CS person is correcting a typo and sometimes the buyer genuinely wants the parcel elsewhere, and the system cannot tell the difference.
The actual credit-note mechanics are the bit worth being discrete about:
- Finance (or whoever has the invoicing role in the client's org) reviews the flag. If the change is legitimate, they trigger: credit note against the original invoice, dated the same day as the address change; fresh invoice with the new place of supply and the correct tax split; both documents referenced in the GSTR-1 of the month in which the credit note is issued, per Rule 53.
- Both documents get pushed to Tally or Zoho Books via the usual sync. The credit note carries the original invoice reference. The new invoice carries a note in the remarks field saying it supersedes the original.
A thing worth saying plainly, because we have had to explain it to three different clients now: Razorpay's refund API is not the right tool here. No money has moved. The buyer paid the correct gross amount; the tax split within that gross is purely a tax-document matter between the seller and the GSTN. Issuing a Razorpay refund and re-charging would be theatre at best, and would mess up the client's reconciliation at worst. This is a documents problem, not a payments problem.
Where this still breaks, honestly: timing. If the address change comes in on, say, the 2nd of the following month, and the original invoice has already been included in the previous month's GSTR-1, the credit note goes into the current month's return. That is fine on paper and matches what Rule 53 contemplates. In practice it means the client's monthly outward supply numbers have a lumpy correction trail that the CA has to explain every quarter, and nobody enjoys that conversation.
The other place it breaks — and this is the one we genuinely do not have a good answer for — is when the buyer updates the shipping address after dispatch but before delivery. Goods are already in transit, invoice is out, e-way bill is out, the courier is halfway to the original destination and the buyer calls to divert. Our current rule is to leave the invoice alone and treat the diversion as a courier matter, not a tax matter, on the reasoning that the invoice was correct at the moment of issue and the subsequent redirection is a logistics decision by the recipient. Riya thinks this is wrong. She argues that if the goods physically terminate in a different state, Section 12(2)(a) says the place of supply is where the movement terminates, full stop, and we should still be issuing a credit note and reissuing. The build team is split.
Honestly, we have never figured out the cleanest answer to this one. If you have — and more importantly if your CA has signed off on it in writing — we would like to see the reasoning. Email us. We will update this post if we land somewhere defensible.
