GSTIN

Definition: one number, one state, one registration

A Goods and Services Tax Identification Number, or GSTIN, is the identifier India’s GST system assigns to a registered person for a specific state or union territory. It is fifteen characters long, alphanumeric, and it appears on every tax invoice, credit note, debit note and return filed by that registration. A business operating in three states normally holds three GSTINs, one per registration, even though it is one company.

The number is not a licence and not a tax clearance. It is a registration reference that ties an invoice to a taxable person, a place of business and a jurisdiction. That is why the same legal entity can hold several, why a cancelled GSTIN can still look perfectly well formed, and why a buyer’s accounts payable team checks the number against the portal rather than trusting the invoice PDF.

Under the pricing on this site, plans are quoted in rupees exclusive of GST, and the standard rate applied to the service is eighteen percent. A Growth plan at ₹7,999 a month is therefore ₹9,438.82 payable, with ₹1,439.82 of tax shown separately on the invoice. Stating that split clearly is part of what makes an invoice usable for a business buyer, and it starts with a correct GSTIN.

Reading the structure, segment by segment

The first two characters are the state code, a number from 01 to 38 plus a few codes for union territories and special categories. Maharashtra is 27, Karnataka 29, Delhi 07, Tamil Nadu 33, Telangana 36 and West Bengal 19. The code describes the registration’s jurisdiction, which is not always where the customer is, and that difference is the source of a large share of billing errors.

Characters three to twelve are the entity’s Permanent Account Number, the ten-character income tax identifier. This is the strongest part of the number because PAN format is itself constrained: five letters, four digits, one letter, with the fourth character encoding the holder type. A GSTIN whose PAN segment does not follow that pattern is invalid even if the checksum happens to work.

Characters thirteen and fourteen are an entity number and a default letter. The entity number distinguishes multiple registrations of the same PAN within a state, so a company with two divisions registered separately in Karnataka will have different characters there. The fourteenth character is Z in the overwhelming majority of registrations, and most validators require it. The fifteenth character is the check character, computed from the preceding fourteen, and it is the part most home-grown validators skip.

The checksum, and how to compute it

The check character uses base thirty-six arithmetic over the first fourteen characters, with digits 0 to 9 and letters A to Z valued from 0 to 35. Multiply the value of each character by one for odd positions and by two for even positions, counting from the left. For each product, add the quotient and the remainder when divided by thirty-six. Sum all fourteen results, take the remainder modulo thirty-six, and the check character is whatever makes that remainder zero.

A worked example makes it concrete. Take the synthetic registration 29ABCDE1234F1ZW: state 29, PAN ABCDE1234F, entity 1, default Z, check W. Computing the weighted sum over the first fourteen characters and reducing modulo thirty-six yields a check value that maps to W, so the number is internally consistent. Change any earlier character and the check character changes, which is what makes the mechanism useful for catching transcription errors.

The checksum catches typos, not fraud. A number can be arithmetically perfect and belong to a cancelled registration, a different legal entity, or a business that has never heard of your customer. Treat the checksum as the first gate in a validation pipeline, not as proof of anything.

• Values are base thirty-six: 0 to 9 then A to Z.
• Weights alternate one and two, starting with one at the left.
• Add quotient plus remainder for each weighted product.
• The final remainder modulo thirty-six must be zero.
• A pass proves internal consistency only, never status.

Validation: four layers, not one regex

The first layer is format. Fifteen characters, two digits, five letters, four digits, one letter, one alphanumeric entity character, Z, one alphanumeric check character. A regular expression catches the obvious cases and nothing else. The second layer is the checksum described above, which catches transpositions and mistyped characters that still look plausible.

The third layer is semantic. Does the state code exist in the current list. Does the PAN segment follow PAN rules, including the holder-type character. Does the entity character fall in the permitted range. Does the registration state match the address on the invoice. These checks are cheap and catch the numbers that were invented by a customer in a hurry.

The fourth layer is authoritative. Query the GST portal or an approved API to confirm the registration is active, the legal name and trade name match the contract, and the registration type fits the transaction. Cache the result with a timestamp and re-check on a schedule, because registrations get cancelled and suspended. A number that was valid at onboarding can be invalid at renewal, and the invoice you raise in between is the one that causes a credit note.

Registration, place of supply and the tax split

GST is a destination-based tax on most supplies, and the destination for a service is determined by the place of supply rules rather than by where the server sits. For a business recipient registered in India, the place of supply of a service is generally the recipient’s registered location. For a consumer, it is usually the address on record. For a service delivered to a recipient outside India, the treatment follows the export provisions and typically requires a letter of undertaking or payment of integrated tax with refund.

Place of supply then decides the tax heads. If the supplier’s registration state and the place of supply are the same, the invoice carries central GST and state GST in equal halves. If they differ, it carries integrated GST. The total rate can be the same, which is exactly why the error survives review: a wrong tax head produces an invoice that looks financially right and is unusable for input tax credit.

SaaS adds a practical wrinkle. Users, billing contacts and contracting entities are frequently in three different places, and a global parent may contract through an Indian subsidiary. The invoice must follow the contracting recipient and its registration, not the user’s login location. Deciding this at contract signature, and storing it as structured fields rather than as a note in a CRM, prevents most of the rework.

What a tax invoice has to contain

The invoice rules set out the required particulars: supplier name, address and GSTIN, a consecutive serial number, the date, the recipient’s name, address and GSTIN where registered, the place of supply for inter-state services, the nature of the supply with an HSN or SAC code, the taxable value, discounts, the rate and amount of each tax head, whether reverse charge applies, and the signature or digital signature of the supplier.

For software services the classification question comes up constantly. SAC 998314 covers IT design and development services, and 998315 covers hosting and infrastructure provisioning, among other headings. Which one applies depends on what is actually being supplied, and it should be confirmed with an accountant rather than copied from a competitor’s invoice. The code affects reporting and the buyer’s accounting treatment, not only the look of the PDF.

Presentation matters more than teams expect. A GSTIN that is correct but printed in a font that renders the letter O as a zero will fail a buyer’s optical or manual check. A place of supply shown only in an address block, with no dedicated field, will be missed. An invoice that cannot be downloaded as a PDF with a stable filename will be re-requested every quarter.

Why this matters more for SaaS than for a shop

A subscription business raises invoices automatically, at scale, to buyers whose finance teams have process. A consumer purchase can survive a slightly wrong invoice because nobody claims credit. A business purchase cannot: the buyer needs the invoice to claim input tax credit, to reconcile the payment in their ledger and to satisfy their auditor. A rejection is not a formatting complaint, it is a payment held.

The knock-on effects are measurable. A wrong GSTIN delays activation for a new customer, because procurement will not release a purchase order against an invalid tax document. A missing place of supply creates a credit note, and a credit note creates a mismatch in the buyer’s return. At renewal, a cancelled registration discovered late forces a re-issue across every invoice in the period, which is the most expensive kind of billing incident because it touches revenue recognition.

International customers need a different path. An export of services is zero-rated when the conditions are met, which usually means an invoice without Indian GST, a declaration and a letter of undertaking, and evidence of payment in convertible foreign exchange. Getting that wrong in the other direction, by charging GST to a foreign recipient, creates a refund problem that can take months to unwind.

Implementing it in the billing path

Store tax identity as structured data, not as a string on the customer record. A registration object should hold the GSTIN, the derived state code, the legal name returned by the portal, the registration status, the verification timestamp and the source of the verification. Deriving the state code from the number rather than asking for it separately removes an entire class of mismatch.

The invoice engine then has explicit inputs: supplier registration, recipient registration, place of supply, SAC code, taxable value, tax rate and currency. Keep the rate table in configuration with effective dates, because rates change and historical invoices must remain reproducible. Never recompute a historical invoice from current settings; store the computed tax lines with the invoice so a re-download in three years shows what was actually issued.

Add guards. Block invoice issuance when the recipient GSTIN fails validation for a business customer. Warn, with an override and a reason, when the place of supply and the registration state disagree in a way that suggests a data error. Number invoices per registration per financial year, keep the series gapless, and make credit notes reference the original invoice number and date. These are small engineering decisions with large audit consequences.

• Derive the state code from the GSTIN, never from a free-text field.
• Store the portal response and the verification date with the registration.
• Keep tax rates versioned with effective dates.
• Freeze computed tax lines on the invoice at issuance.
• Reference the original invoice on every credit note.

The failures that cost the most, and what to measure

The most common failure is a valid GSTIN in the wrong field. A billing contact pastes a PAN, or a state code from the shipping address, into the tax number field, and the invoice passes a length check because nothing validated it. The second is a cancelled registration that was verified once at signup and never again. The third is a place of supply taken from the user’s IP address, which is a guess dressed as data.

The fourth is human: sales agrees to bill through a group entity to speed up a deal, and the invoice no longer matches the contract. The fifth is arithmetic presentation, where tax is computed correctly but rounded per line rather than per invoice, producing a total that differs from the buyer’s expectation by a rupee. The sixth is the credit note that references nothing, which forces the buyer’s accountant to reconstruct the chain manually.

Measure invoice rejection rate by reason, credit note rate, median days from signup to first accepted invoice, and the share of business customers with a verified registration less than a year old. A rejection rate above a few percent is not a finance problem, it is a product problem, and it shows up as slower activation and longer cash collection before anyone connects it to a form field.

A worked invoice, end to end

Consider a Pune-based supplier registered in Maharashtra, invoicing a Bengaluru customer registered in Karnataka for a Growth plan at ₹7,999 for one month. The supplier’s GSTIN begins with 27, the customer’s with 29. Place of supply is Karnataka, so the tax head is IGST at eighteen percent: ₹1,439.82, for a total of ₹9,438.82. The SAC code is recorded, the invoice number follows the Maharashtra series, and the customer’s GSTIN is printed exactly as verified.

Now change one fact. The customer contracts through its Maharashtra branch, registered in Maharashtra. Place of supply becomes Maharashtra, and the same total splits into CGST of ₹719.91 and SGST of ₹719.91. The rate did not change and the amount did not change, but the invoice is now a different document, and issuing the wrong version means a credit note and a fresh invoice.

That is the whole discipline in one example: identity, registration, place of supply, tax head. Get the four right and the invoice is boring, which is the goal. Get one wrong and the customer’s finance team becomes your QA department, at the worst possible moment in the quarter.