GST Automation: A Practical Guide for Indian Finance Teams

Most GST problems in accounts payable are not tax problems. They are data problems that turn into tax problems at filing, when fixing them is expensive. This guide is about moving the checks to the day the invoice arrives, reconciling continuously instead of in the last week, and keeping the evidence as you go.

Where GST work breaks in accounts payable

The pattern is the same whether the ERP is SAP or Tally. Invoices come in by email, portal and post. Someone keys the supplier GSTIN, the taxable value and the tax amounts into the ERP. At month end the purchase register is exported, pushed into a spreadsheet or a GST tool, and compared with GSTR-2B. The mismatches are chased in the days before GSTR-3B is due. The ones that cannot be resolved in time are claimed on faith or parked, and the parked ones resurface at the annual reconciliation.

Three things go wrong in that flow, in a predictable order. The invoice carries wrong data: a GSTIN for a different branch, CGST and SGST charged where IGST was due, a rate that does not match the HSN, or no IRN from a supplier who is required to generate one. The register and 2B disagree: the supplier filed late, filed under another GSTIN, or did not file at all. And the evidence is scattered: the invoice in an inbox, the GRN in the ERP, the vendor's filing status in a screenshot, and the decision to claim or defer in one person's head.

Automation does not change the law. It changes when you find out. A check that runs on the day the invoice arrives costs one email to the supplier. The same check at filing costs a reversal with interest, or a notice a year later.

Validate every invoice at capture, not at filing

The first design decision is that GST validation is a capture control. It runs on every invoice and every line before anything is posted. It is not a month-end report.

At capture, a document agent reads the invoice: supplier and recipient GSTINs, invoice number and date, each line with its HSN or SAC, taxable value per line, tax type and rate per line, and the IRN and signed QR code if they are present. Reading is the easy part. The value is in what the reading is checked against:

• The recipient GSTIN on the invoice is one of yours, and it is the registration for the state where the supply was received. A supplier billing your Haryana GSTIN for goods delivered to your Maharashtra warehouse has produced a document on which the credit sits in the wrong registration.
• Taxable value, rate and tax amount reconcile on each line, and the lines add up to the invoice total within rounding.
• Tax type matches place of supply: CGST plus SGST for an intra-state supply, IGST for an inter-state one.
• The invoice number and date are unique for that supplier in that financial year. Duplicates are the most common way to claim a credit twice without anyone intending to.

Each failed check becomes a named exception on the invoice, with the field, the value read and the value expected. That is what the AP clerk, the supplier and later the auditor need to see. A flag that says only "GST validation failed" helps nobody.

The DocPro Invoice Agent page shows which fields are read and how confidence is attached to each; Invoice Automation covers the payables workflow around it.

GSTIN, vendor status and e-invoice checks

A GSTIN is fifteen characters: a two-digit state code, the supplier's ten-character PAN, an entity code for that PAN's registrations in the state, the letter Z by default, and a check character. Format and checksum validation catches typing errors. It says nothing about whether the registration is active, and that is the check that matters for credit.

Vendor status should be verified at onboarding and re-checked on a schedule, not assumed from the master. The questions are specific. Is the GSTIN active, cancelled or suspended? Is the vendor a regular taxpayer or under the composition scheme, where it cannot charge GST and issues a bill of supply, so there is no credit to claim? What is its filing frequency? Has it actually been filing GSTR-1 and GSTR-3B? A supplier that has stopped filing is a supplier whose invoices will not appear in your 2B, however correct the paper looks.

E-invoicing adds a second layer. Suppliers above the turnover threshold must report B2B invoices to an Invoice Registration Portal, which returns an IRN and a signed QR code. The threshold has been lowered several times, so check the current limit rather than relying on what was true when the vendor was onboarded. Two buyer-side checks follow. If the supplier is in scope, an invoice without an IRN is not a valid tax invoice for credit purposes. And the QR payload (both GSTINs, invoice number, date, value, the main HSN and the IRN) should agree with the printed invoice; a difference means the document was changed after reporting, or the wrong PDF was sent.

These checks are deterministic. There is no judgement in them, which is exactly why they should not be done by hand. FinSuite Vendor Management holds the compliance standing of each vendor; FinSuite GST Compliance runs the invoice checks against it.

HSN, SAC, rate and place of supply

Rate errors are quiet. An invoice at 5 per cent where the HSN attracts 18 is a short claim you will never notice; one at 18 where the HSN attracts 5 is an excess claim you will notice only when a notice arrives. The rate schedule also changes, and the 2025 rationalisation reset a large part of it, so the master your checks run against needs an effective date on every rate, not just a code and a number.

Practical guidance: keep an HSN and SAC master with rates and effective dates for the goods and services you actually buy, which is a far shorter list than the full schedule. Validate that the supplier has printed the number of HSN digits its turnover band requires. Flag any line where the rate charged differs from the master, and route it to a person with both values visible. Do not auto-correct the rate. The supplier has to issue a credit note or a fresh invoice, and your system should hold the invoice until it does.

Place of supply decides the tax type and, with it, which of your registrations can claim. For goods it is usually where the movement of the goods ends; for services it is usually the recipient's location, with a long list of exceptions covering immovable property, events, transport and more. The common payables failure is a service provider charging CGST and SGST from its own state for a service delivered to your office in another state. Credit under the wrong head cannot be relabelled. Hold the invoice, ask for the correction, record the reason.

Reverse charge is the mirror case. For notified supplies, and for certain purchases from unregistered persons, you pay the tax and claim the credit yourself, and you have to raise a self-invoice. Capture rules should tag these supplies at vendor or category level so they are never treated as ordinary input invoices.

Reconciling the purchase register to GSTR-2B

GSTR-2B is the static statement generated each month from what your suppliers filed. The credit you take in GSTR-3B is restricted to what appears in it. Reconciliation is therefore not a tick box. It is the calculation that decides how much tax you pay this month.

Running the comparison monthly is the minimum. Running it continuously, as supplier filings land and as your register changes, turns the last-week scramble into a short list that has been shrinking all month. Each invoice in your register ends in one of a few states:

• Matched: in your register and in 2B, with GSTIN, invoice number, date, taxable value and tax agreeing within tolerance. Claim.
• In your register, not in 2B: the supplier has not filed, filed late, or filed under a different number. Defer and chase. Keep the invoice and the GRN attached so that when it appears, the match is automatic.
• In 2B, not in your register: the invoice was never captured, the goods have not arrived, or a supplier has billed you in error. Do not claim until the invoice is in your books and the supply has been received.
• Value or rate mismatch: usually a credit note, a rounding difference or a rate error. Resolve to the document, not to the spreadsheet.

The Invoice Management System on the GST portal, introduced in late 2024, lets a recipient accept, reject or keep pending each supplier invoice before 2B is generated. Your reconciliation output is exactly the input that system needs. If the match engine already knows an invoice is unreceived, the action on the portal should follow from that rather than be decided again by hand.

Matching needs tolerances and it needs memory. Suppliers truncate invoice numbers, swap prefixes and misdate documents. A rule that fails on a trailing slash generates hundreds of false exceptions and buries the real ones. Fuzzy matching on number and date with exact matching on GSTIN and tax amount is the usual balance. The state of each invoice should persist from month to month, so a deferred credit carries its history into the month it finally matches.

ITC eligibility: claim, defer or reverse

Appearing in 2B is necessary, not sufficient. The conditions for taking credit are familiar to any practitioner, and each one is a rule a system can hold:

• You hold a valid tax invoice or debit note, with an IRN where the supplier is in scope.
• The goods or services have been received, which is why the GRN or the service acceptance belongs in the match.
• The supplier's tax has reached the government through its return, and the invoice is in your 2B.
• You have filed your own return.
• You pay the supplier within 180 days of the invoice date. Otherwise the credit is reversed with interest and taken again when payment is made.
• The credit is taken before the statutory deadline that follows the end of the financial year. Check the current date each year.

Then there are blocked credits: motor vehicles with limited exceptions, food and beverages, club memberships, works contracts for immovable property, goods for personal consumption, goods lost, stolen, destroyed or given away as gifts and samples, and the rest of the list. A category rule at vendor or ledger level marks these at capture. Where a business makes both taxable and exempt supplies, the common credit has to be apportioned. That is a monthly calculation rather than an invoice check, but it only works if the invoices were tagged correctly in the first place.

The decision per invoice is one of three: claim, defer or reverse. Record which, record why, and record who. The point of automating this is not to remove judgement from the contested cases. It is to make the uncontested majority disappear from the list so the contested ones get looked at properly.

An audit trail that survives a notice

Notices now come from automated comparisons on the department's side. A mismatch between the credit in 3B and 2B beyond a threshold, or between the liability in GSTR-1 and 3B, generates an intimation with a short reply window. The reply has to be specific: this invoice, this supplier, this reason, this document. A team that reconciles in a spreadsheet and keeps invoices in email cannot assemble that in the time allowed.

The trail you want is per invoice: the document as received, what was read from it and with what confidence, every check and its result, the match to 2B with the month it matched, the eligibility decision with the rule or the person behind it, and the ERP posting reference. Kept in one place and keyed by invoice, it answers a scrutiny notice in minutes and the annual reconciliation without heroics. GST Compliance Automation describes how that trail is built as a by-product of the workflow rather than as a separate exercise.

What we would not automate

A system should hold the invoice and name the problem. It should not decide contested questions of eligibility, argue the place of supply in a grey case, or reclassify a blocked-credit category because the vendor's description changed. Those go to a person, and sometimes to your adviser, with the evidence already attached. Nor should a system correct a supplier's invoice on its own. The supplier corrects the document; your system records that it did, and when.

How to test this on your own invoices

You do not need a project to find out how much of this applies to you. Take one month of purchase invoices, the purchase register for the same month, and the 2B for it.

1. Run the capture checks on the invoices: GSTIN format and status, tax type against place of supply, rate against your HSN master, IRN presence for suppliers in scope. Count the exceptions and group them by type.
2. Match the register to 2B with a tolerance of a few rupees and fuzzy invoice numbers. Count how many land in each of the four states above.
3. For the deferred and mismatched set, time how long it takes to find the invoice, the GRN and the supplier's filing status for each one.
4. Pick five claimed credits at random and try to assemble the evidence a notice would ask for.

The counts tell you where the money is; the timings tell you where the effort is. If capture exceptions dominate, start at the document with DocPro. If deferred credit dominates, start at vendor standing and reconciliation with FinSuite. The finance workflow assessment is built to score exactly this with you, and the wider accounts payable automation page covers the matching and approval steps that sit around the tax checks.