AI for GST reconciliation, and the line it must not cross

"AI for GST reconciliation" is sold as magic, and it isn't. Reconciliation is a data-join problem — matching the same purchase across your bank, your books and the portal, invoice by invoice — with a legal edge sitting on top of each match. The join is exactly what machine matching is good at. The legal edge — is this credit blocked, does it reverse, has the notice threshold tripped — is a rules question, and a language model that guesses at it will invent citations and thresholds that sound right and cost you money. This guide separates the two: what AI genuinely does here, what it must never do, and where the call stays human.

Reconciliation is a data-join with a legal edge

Strip the marketing away and GST reconciliation is a join. The same purchase appears three times — once in your bank statement as a payment, once in your books as a recorded invoice, once on the portal in your GSTR-2B — and the job is to line up the three copies and act on the ones that don't agree. The mechanics of that join are a pillar of their own; this page is about where AI fits into it, honestly.

The join is genuinely hard, and hard in the specific way machine matching is good at: the three copies rarely share a key. The invoice number in your books is truncated on the bank narration, the value differs by a rounding paisa or a retention held back, the GSTIN is right but the trade name is spelled two ways. A human clears these by eye; a rigid invoice_no = invoice_no rule cannot. That is the part where AI earns its place.

Sitting on each matched line, though, is a legal edge — is this credit eligible, does it reverse, has a threshold tripped — and that is not a matching problem at all. It is a rules question with a right answer written in the CGST Act. Keeping those two things apart is the whole argument of this page.

What the AI genuinely does

Three things, all of them variations on the same strength — resolving records that should be the same but don't look the same, and then telling you exactly which one is the problem.

That last one is worth dwelling on, because it is where reading the bank pays off. Under Rule 37 — which operationalises the second proviso to Section 16(2) — if you don't pay a supplier the invoice value plus tax within 180 days of the invoice date, the credit you availed on that invoice must be reversed, and re-availed once you eventually pay. It runs on the unpaid portion, so a retention held back on a large invoice can force a reversal even where the retention is contractually correct; and reverse-charge supplies are outside it entirely. Ageing payables to the invoice, netting part-payments, excluding RCM — that is matching and arithmetic. AI does it across a few hundred vendors without sampling. It is a good fit precisely because none of it requires a legal opinion.

What the AI must never do

It must not produce the tax verdict by generating text. This is not a stylistic preference — it is the one failure mode that turns a helpful tool into a liability.

Language models are trained to produce fluent, confident answers, and on Indian GST figures the confident answer is very often folklore. Ask a general-purpose chatbot for the exact DRC-01C threshold and it will hand you a precise rupee-and-percentage trigger, stated as settled law. It isn't. Rule 88D fixes no figure at all — it delegates to "such amount and such percentage as may be recommended by the Council." The one thing actually on the record is a 50th GST Council recommendation (11 July 2023): a gap of more than 20% as well as more than ₹25 lakh, both limbs together — and even that is a recommendation, with GSTN publishing only "a predefined limit" and "a configurable threshold." A model that fills that gap with a crisp number is inventing law, and a reconciliation built on an invented threshold either raises false alarms or misses the real notice.

The conclusion is not "don't use AI." It is: use AI for the join, and make the verdict deterministic. Whether a line is blocked, reverses, or trips a threshold has to come from rules keyed to the actual provision — reproducible, the same every run, and traceable back to its source — never from a model's best guess. Matching is allowed to be probabilistic. The tax verdict is not.

Where the call stays human

Some of this isn't a matching problem or a deterministic-rule problem — it needs a judgement a machine shouldn't make. Two cases matter most.

Eligibility under Section 17(5). Blocked credits can't be tagged from the GST invoice or the expense head alone. Take works-contract expense: clause (c) never reaches works-contract services for constructing "plant and machinery," and re-construction, renovation or repairs are only caught to the extent they are capitalised. So the eligibility call needs two facts that live outside the GST document — whether the immovable property meets the defined "plant and machinery" test, and whether the cost was capitalised or charged to revenue. A blanket source-side rule that tags every works-contract head ineligible will over-block and destroy recoverable credit. AI can surface the candidate and route it to the fixed-asset register; the eligibility decision belongs to a person, often a CA.

The DRC-01C reply. When the portal flags an ITC gap, you get seven days to pay the excess with interest or file a Part B reply explaining it, or your next GSTR-1 is blocked. Assembling the gap, pulling the invoices behind it, laying out the evidence — that is machine work, and it should be done in minutes. But whether the gap is defensible, and how to explain a timing difference versus a genuine excess, is a judgement call with a legal consequence. The tool prepares the file; the human writes the reply. The 7-day playbook walks through that split in detail.

Why this is hard to do by hand

At a handful of invoices, the whole thing is a coffee-break task and you don't need AI for any of it. Across a few hundred vendors and multiple GSTINs, a fuzzy three-way join every month — bank to books to 2B, each copy under a different key — is painful to do manually, and the manual escape hatch is sampling. Sampling is exactly where credit leaks: the one unmatched line you didn't open is the reversal you'll find in an audit, or the notice you'll answer in seven days. The join is the part that doesn't scale by hand, which is precisely the part worth automating — and precisely the part that is a matching problem, not a legal one.

How Recoup does it

Recoup is AI-enabled reconciliation that is deterministic on the tax verdict — and the two halves are built on purpose to stay apart. It connects read-only to your bank, your books (Zoho Books or Tally) and the GST portal, and uses matching to solve the join: fuzzy-matching invoices across all three even when numbers, values and vendor names don't line up, and handing you the exception named — the invoice a supplier never filed, the payment now past 180 days, the 3B-versus-2B gap. That is the AI half, and it does the messy work a filing suite skips.

The verdict half is deterministic. Every "this reverses under Rule 37," "this is at risk under Rule 37A," "this gap could draw a DRC-01C" is produced by rules keyed to the provision and shown with the provision — the same answer every run, no invented thresholds, nothing a language model gets a vote on. Where the call is genuinely yours — a 17(5) eligibility judgement, a DRC-01C reply — Recoup assembles the evidence and stops, rather than guessing. If you want the contrast with asking a chatbot to do this, the ChatGPT-versus-Recoup breakdown is the honest version.

Keep reading

This guide is general information, not tax advice. GST positions change; verify every provision, threshold and date against the current CGST Act, Rules, CBIC circulars and the GST portal before acting.