Your CA sends a message: the ITC claim on invoice #447 is denied. The GSTIN does not match any registered taxpayer. You look at the invoice. The number looks right. It is 15 characters. The format check passed. Nobody rechecked the math.
Section 16 of the CGST Act says you can claim ITC only if the invoice meets certain conditions. The supplier must be registered. The GSTIN must be valid. The tax must have been actually paid to the government. The invoice must carry the required details. If any of these conditions are not met, the ITC claim is denied.
Section 50 of the CGST Act provides for interest on delayed tax and, where it applies, on wrongly availed and utilised ITC. Read the Act for the current rate and conditions. Do not treat a blog as the notification. The cost is not just the denied credit. It is the interest, the time spent amending the return, and the scrutiny that follows. A single wrong ITC claim can trigger a broader review of your entire return.
The checks below are what EntryLedger runs on every invoice before it reaches Tally. They take seconds. They catch the errors that cost money at filing time.
The seven checks
| # | Check | What it catches | What happens on failure |
|---|---|---|---|
| 1 | GSTIN format | Wrong length, invalid characters | Invoice goes to review |
| 2 | GSTIN checksum | Transposed or mistyped digits | Invoice goes to review |
| 3 | HSN format + directory | Missing or non-existent HSN | Invoice goes to review |
| 4 | Arithmetic closure | Lines do not sum to taxable, tax does not equal rate x taxable | Invoice goes to review |
| 5 | Regime consistency | CGST/SGST vs IGST does not match place of supply | Invoice goes to review |
| 6 | Duplicate detection | Same invoice number + GSTIN already posted | Invoice goes to review |
| 7 | Cross-field validation | State code vs address, entity under same PAN | Invoice goes to review |
Green tiles are the orchestrator. Amber is not a silent export path: directory warns unless you set live; duplicates use invoice number + seller GSTIN when both exist.
The first four are arithmetic. They do not need any data beyond the invoice itself. The last three need context from other parts of the invoice or from previous entries. Together they are the reason nothing wrong reaches Tally automatically.
Check 1: GSTIN format
A GSTIN must be exactly 15 characters. The first two must be valid state codes (01-38, 97, 99). The next ten must follow PAN format: five letters, four digits, one letter. Then the entity number, the letter Z, and the checksum. If any of these are wrong, the GSTIN is invalid.
This is the simplest check. On a photocopy, the GSTIN is often handwritten or printed small. The OCR reads what it can, and sometimes it gets a character wrong. A letter becomes a digit. A digit becomes a letter. The result is a GSTIN that looks right but is not. The format check catches these errors before they reach Tally.
The format check is fast. It does not need any data beyond the GSTIN itself. It runs in milliseconds. And it catches the most obvious errors: wrong length, invalid characters, missing state code. If the format check fails, the invoice goes to review immediately. No further checks are needed.
Check 2: GSTIN checksum
The last character is a Mod-36 checksum computed over the first 14 characters. If you recompute it and it does not match, the GSTIN has a typo. It often catches a transposed digit. Someone types 27AAPFU1243A1ZF instead of ...1234.... The format check passes. The checksum catches it.
The checksum is a simple arithmetic check. You do not need to call anyone or look anything up. The math tells you whether the GSTIN was typed correctly. If you are keying in invoices manually and not running this check, you are trusting a blurry photocopy with your input tax credit.
Checksum catches many typing mistakes. It does not catch a GSTIN that is well-formed but belongs to the wrong entity. That needs a portal lookup or a cross-field check against address and PAN.
Check 3: HSN format and directory
Every line item must carry an HSN code. The code must be 4, 6 or 8 digits. It must exist in the CBIC HSN directory. A missing HSN or a non-existent one means the tax rate cannot be verified. The invoice goes to review until the HSN is confirmed.
HSN errors are quieter than GSTIN errors. A wrong GSTIN gets flagged immediately. A wrong HSN sits in the books for months and only surfaces when the rate does not match the product description. By then, fixing it means amending the return. Catching it at entry takes seconds. Catching it at filing takes hours.
The HSN check has two layers. The first is a format check: is the code 4, 6 or 8 digits? The second is a directory check: does the code exist in the CBIC list? Both matter, because a well-formed code that does not exist is still a wrong code.
Check 4: Arithmetic closure
Three checks: line items sum to taxable value. Taxable value times rate equals tax amount. All taxes sum to total. Tolerance is plus or minus one rupee. If any check fails, the invoice has a wrong number somewhere.
This is the check that catches vendor typos. A supplier calculates the total by hand, presses the wrong button, and the total is off by ₹10 or ₹20. The invoice looks normal. The numbers look reasonable. But they do not add up. Arithmetic closure catches this before it reaches Tally.
The tolerance of ±₹1 accounts for normal vendor round-off. Some vendors round to the nearest rupee. Some round to 50 paise. A ₹0.60 round-off is normal and does not indicate an error. Anything larger flags the invoice for review.
Check 5: Regime consistency
CGST and SGST for intra-state supplies. IGST for inter-state. If the invoice carries CGST but the seller is in a different state, the regime is wrong. This is a cross-field check: it compares the state code from the GSTIN against the tax type on the invoice.
The regime error is common on invoices from suppliers who serve multiple states. The supplier uses the wrong template, or the place of supply field was not updated. The arithmetic looks fine. The numbers add up. But the tax type is wrong. The regime check catches this.
A wrong regime does not change the total amount. The tax is the same whether it is CGST+SGST or IGST. But the tax type is wrong, and that wrong shows up at filing time when the GST portal flags the mismatch.
Check 6: Duplicate detection
Same invoice number plus same seller GSTIN means duplicate. EntryLedger uses conditional uniqueness: the database flags this combination as a duplicate. Empty GSTINs are allowed to coexist (unidentified invoices). This catches both exact duplicates and near-duplicates where the GSTIN was mistyped in one scan.
Duplicates cost money. If you pay the same invoice twice, the cost is the full invoice amount. If you post the same invoice twice to Tally, your books are wrong. The reconciliation shows a discrepancy. Someone spends time tracing it. The time costs money.
Catching duplicates at entry is cheap. A few seconds of validation. Catching them at audit is expensive. Hours of investigation. The difference is process versus firefighting.
Check 7: Cross-field validation
The state code from the GSTIN must match the supplier's address. The entity number must point to the correct registration. The tax regime must match the places of supply. These are checks that need data from multiple parts of the invoice. A check that only looks at the GSTIN will miss them.
Cross-field validation is the deepest check. It looks at the GSTIN, the address, the tax type, and the invoice number together. A GSTIN that passes the checksum but has the wrong state code is caught here. A GSTIN that belongs to a different entity under the same PAN is caught here. These are the errors that cost the most at filing time.
The cross-field check needs the most data. It compares the GSTIN against the supplier address, the buyer address, the tax type, and previous entries. It is slower than the other checks. But it catches the errors that the other checks miss. Together, the seven checks form a complete validation gate.
What this looks like in practice
An invoice comes in as a photocopy. The fields are extracted. Each check runs in sequence. If all seven pass, the invoice can export. If any one fails, it waits in a review queue. The scan is there. The reason is there. A person confirms or corrects it in seconds. The verdicts worth keeping go straight into a twelve-column register.
The wrong number never gets a chance to sit in your books for three months and surface during reconciliation. The check takes seconds at entry time. The fix at filing time takes hours. One is process. The other is firefighting.
The seven checks are not independent. They build on each other. The format check catches obvious errors. The checksum catches typos. The HSN check catches missing codes. Arithmetic closure catches wrong totals. Regime consistency catches wrong tax types. Duplicate detection catches resubmissions. Cross-field validation catches everything else. Together, they are the reason nothing wrong reaches Tally automatically.
- CGST ActCGST Act (CBIC)
Sections 16-17 on ITC eligibility. Section 50 on interest for wrongly claimed credit.
- EntryLedgerentryledger.shop/validation
Validation gate as shipped: GSTIN, HSN, arithmetic, regime. Duplicate handling is separate.
What does a wrong ITC claim cost?+
Denied ITC, interest under section 50 of the CGST Act where it applies, and amendment time. Confirm rate and conditions in the Act.
Can these checks be automated?+
EntryLedger runs GSTIN, HSN, arithmetic, and regime checks before auto-export. Duplicates are handled on invoice number plus seller GSTIN. Failures go to review, not silent export.