Your supplier's GSTIN is wrong. Here is how to catch it before it costs you money.

Your AP clerk keys in a supplier invoice. The photocopy is dark, the GSTIN is handwritten, someone types what they think they see. The 3 and the 4 get swapped. 27AAPFU1243A1ZF instead of 27AAPFU1234A1ZF. The format check passes. The number is 15 characters. It looks like a GSTIN. Nobody checks further.

Later, at filing, that GSTIN may fail a GSTN search or fail to appear in GSTR-2B. Credit can be denied. Interest under section 50 of the CGST Act can apply where the Act says it does (commonly discussed at 18% per annum; confirm the current provision). You still have the amendment work. One swapped digit is enough.

A transposed digit is a typical GSTIN mistake on paper. It is cheap to catch if you recompute the checksum before the invoice reaches the books.

The 15 characters and what they mean

A GSTIN is the Goods and Services Tax Identification Number. Every registered taxpayer in India has one. It is 15 characters, and every character carries a specific meaning. Understanding the structure is the first step to validating it.

The first two digits are the state code. 27 is Maharashtra. 07 is Delhi. 24 is Gujarat. There are 38 valid state codes, plus 97 for other territory and 99 for foreign supplies. If the state code does not match the supplier's address, the GSTIN is wrong even if everything else checks out. A supplier in Maharashtra should not have a GSTIN starting with 07.

Then comes the PAN, ten characters. This is the supplier's permanent account number, the same one they use for income tax. It ties the GSTIN to a specific business entity. If you have the supplier's PAN from a previous invoice, you can compare it against the GSTIN. A mismatch means the GSTIN belongs to a different entity.

After the PAN sits the entity number. This separates multiple GST registrations under the same PAN. A large supplier might have separate GSTINs for different states or different business verticals. The entity number tells them apart. It can be a digit or a letter.

The letter Z follows. It is fixed for now. The government has said it may change in the future, but today every GSTIN has a Z in position 14.

And then the checksum. The last character. This is where the real validation happens.

The checksum that catches most errors

The last character is not random. It is a Mod-36 checksum computed over the first 14 characters. If you recompute it and it does not match, the GSTIN is wrong. You do not need to call anyone or look anything up. The math tells you.

The algorithm works like this. Map each character to a number: 0 through 9 stay as they are, A through Z become 10 through 35. Walk the first 14 characters, alternating weights of 1 and 2. Multiply each character's value by its weight. If the product is 36 or more, add the quotient and remainder separately to a running total. The checksum is (36 minus total mod 36) mod 36, mapped back to its character.

Here is the full computation for 27AAPFU1234A1Z:

236 mod 36 is 20. Then 36 minus 20 is 16. Value 16 maps to the character F. So the checksum is F, and the full GSTIN is 27AAPFU1234A1ZF.

Swap the 3 and 4 (making it ...1243...) and the total changes to 238. 238 mod 36 is 22. Checksum becomes 14, which maps to E. The GSTIN becomes 27AAPFU1243A1ZE. If someone typed F as the last character, the checksum does not match, and the error is caught before it reaches your books.

What about the other direction? Could someone type a wrong GSTIN that happens to have the right checksum? Technically yes, but practically no. With 36 possible characters and the checksum depending on all 14 preceding characters, the chance of a wrong GSTIN passing by coincidence is astronomically small. You would need to change a character in a way that produces the exact same total modulo 36. It is not impossible, but it is not something you plan for.

EntryLedger runs this exact check on every invoice. The implementation is open, pure Python, no dependencies, covered by the test suite. You can run it yourself:

def compute_checksum(first_14):
    total = 0
    for i, ch in enumerate(first_14):
        value = CHAR_TO_VALUE[ch]
        product = value * ((i % 2) + 1)
        total += product // 36 + product % 36
    return CHARSET[(36 - (total % 36)) % 36]

This is a short function. If you key invoices and never recompute the checksum, you are trusting the photocopy. That is a process choice, not a GSTN guarantee.

Checksum is necessary. It is not sufficient.

The checksum catches typos and transpositions. It does not catch everything.

A supplier might have given you a GSTIN that is technically valid (passes the checksum) but belongs to a different entity under the same PAN. The supplier has two registrations: one for Maharashtra, one for Gujarat. You received the Maharashtra invoice but the GSTIN is for Gujarat. The checksum passes. The state code is valid. But the GSTIN is wrong for this transaction.

Or the state code might be 07 (Delhi) when the supplier's address is in Maharashtra. The checksum sees no problem. The cross-field check does.

Or the supplier might have transposed not a digit but the entity number. The GSTIN points to a different registration under the same PAN. Again, the checksum passes. Again, the cross-field check catches it.

This is why EntryLedger runs three layers, not one:

The first two are arithmetic. They do not need any data beyond the GSTIN itself. The third needs the rest of the invoice: the supplier's address, the buyer's address, the tax type, the invoice number. Together they are the reason nothing wrong reaches Tally automatically.

What this looks like in practice

An invoice comes in as a photocopy. The GSTIN is extracted from the scan. The format is checked: 15 characters, correct structure. The checksum is recomputed: does the last character match? The state code is compared to the supplier address: does 27 match Maharashtra?

If all three pass, the invoice can export automatically. The GSTIN is valid. The numbers are provable. The entry reaches Tally with confidence.

If any one fails, the invoice waits in a review queue. The scan is right there. The reason is right there. A person confirms or corrects it in a few seconds. The wrong number never gets a chance to sit in your books for three months and surface during reconciliation.

This is the difference between a format check and a validation gate. A format check asks: does this look like a GSTIN? A validation gate asks: is this GSTIN correct, and can we prove it? One is a filter. The other is a guarantee.

At filing time, the credit you claim is only as good as the vouchers behind it. A gate that blocks a wrong GSTIN before posting is cheaper than an amendment after the fact. The amendment costs interest. The gate costs nothing once it is running.