How Multi-GSTIN Billing Actually Works

If your business operates from more than one state in India, GST billing stops being a simple percentage calculation and becomes a small state machine. Get it wrong and you're either under-collecting tax (a compliance problem) or issuing invoices your customer's accounts team rejects on sight (a cash-flow problem). Here's how it actually works, and where we see businesses get tripped up.

The core rule: it's about the place of supply, not where you're registered

The single most common misunderstanding is billing CGST+SGST because "that's our home state," regardless of where the customer is. GST doesn't work off your registration — it works off the place of supply, which for most goods and services is the customer's billing/delivery location.

The actual determination logic is simpler than most finance teams assume once you separate it into two questions:

1. Which of your GST registrations is issuing this invoice?
2. Does the customer's state match that registration's state?

If yes — same state — you split the tax as CGST + SGST. If no — different states — the whole amount is IGST. That's the entire rule. The complexity comes from making sure question 1 is answered correctly at the point of invoicing, not from the tax math itself.

Where multi-registration businesses get this wrong

A business with GST registrations in, say, Karnataka and Uttar Pradesh usually has one of two failure modes:

• Wrong originating registration. An order fulfilled from the UP office gets invoiced under the Karnataka GSTIN because that's the "default" in whatever tool is being used, silently misapplying the tax split for every interstate customer of the UP branch.
• Manual override drift. Someone manually corrects a GST line for one invoice to fix a specific customer's complaint, and the fix never gets applied to the underlying logic — so the same mistake recurs on the next similar invoice.

Both failure modes have the same root cause: GST determination living as a manual step instead of a rule tied directly to which office/registration is actually transacting and where the customer is.

What correct automatic determination looks like

function determineGstSplit(sellingOffice, customerState) {
  const registration = sellingOffice.gstin;
  const registrationState = registration.state;
 
  if (registrationState === customerState) {
    return { cgst: rate / 2, sgst: rate / 2, igst: 0 };
  }
  return { cgst: 0, sgst: 0, igst: rate };
}

This looks trivial, and it is — once sellingOffice is a real, structured field on the transaction rather than an assumption. The actual engineering work is making sure every sales document (estimate, sales order, invoice, credit note) carries which office/registration it's issued from as first-class data, not inferred after the fact.

A worked example

Illustrative company and invoices, not real transactions — useful for seeing the rule applied, not just stated.

Girivan Systems Pvt Ltd (fictional) holds GST registrations in Karnataka and Uttar Pradesh. Four invoices from the same week, run through the two-question rule:

INV-1045 is the one that trips up manual processes: the customer is in the same state as the other registration (Karnataka), which tempts someone to apply CGST/SGST by habit. The rule only cares about the registration that's actually issuing this specific invoice — Uttar Pradesh — versus the customer's state, so it's IGST, correctly.

PAN and multi-entity complications

Things get one layer more complex when a group operates under more than one legal entity (each with its own PAN and GST registrations), or has an entity in another country entirely — a Singapore-registered affiliate billing an Indian customer, for instance, is a different tax treatment altogether (typically export-of-services / zero-rated, not a GST-split question at all). If your business has this shape, treat "which legal entity is billing" as a decision made before GST determination even runs, not folded into the same logic.

The practical checklist

• Every sales document should carry a structured "issuing office/registration" field — not a free-text company name.
• GST split determination should be a pure function of (issuing registration's state, customer's billing state) — no manual override path that doesn't also update the underlying rule.
• If you operate under multiple legal entities, entity selection happens before GST logic, not as part of it.
• Reconcile a sample of interstate vs intrastate invoices monthly against actual GSTIN state codes — this catches drift long before an audit does.

This is exactly the kind of thing DexVee's Finance & Billing module handles automatically per transaction, across as many GST registrations as your business operates — because we built it to solve this problem for our own multi-office operation first.