Detecting a fraudulent GST claim and proving it are two different jobs. Detection flags an entity for a closer look. Investigation turns scattered filings, e-way bills, bank records, and seized documents into a chronological, cross-referenced case an officer can actually act on. This piece is about that second job, the one that starts after the alert fires and ends when a case is ready to move up the chain. It covers GST and Input Tax Credit (ITC) fraud specifically, not income tax, customs, or money laundering investigations, which run on different data and different law.
Key Takeaways
- GST fraud investigation and GST fraud detection are separate stages, and most public discussion only covers the first one
- Detection tells an officer where to look; investigation tells them what actually happened, and that gap is where most of the manual effort still sits
- A GST fraud case typically pulls from four to six independent data sources: GSTN returns, e-way bills, FASTag movement records, PAN and directorship registries, bank statements, and seized documents
- Cross-verifying invoices against e-way bill and FASTag data is how officers separate real transactions from paper-only ones used to claim fraudulent ITC
- Section 67 of the CGST Act governs search, seizure, and evidence handling, and any AI-assisted workflow has to fit inside those procedural boundaries, not around them
- AI can organise and cross-reference evidence faster than manual review, but it does not replace legal review or officer judgment on what the evidence proves
What “Raw” Actually Looks Like in a GST Fraud Case
Before an officer can build a case, the data itself has to be assembled, and it does not arrive in one place.
The picture comes from records already sitting in government systems:
- GSTN return filings, showing declared sales, purchases, and ITC claims
- E-way bills, which are supposed to document the physical movement of goods above a certain value
- FASTag toll transaction data, which independently records whether a vehicle actually travelled the route an e-way bill claims
- PAN and company directorship registries, which show whether one person is behind an unusual number of firms, a common shell-company pattern
Once an investigation moves to a physical search, a different set of evidence enters the picture. This is where bank statements, physical bookkeeping, and electronic records come in, and courts have been explicit that these powers come with real procedural limits. A 2025 Delhi High Court ruling upheld the seizure of electronic devices and even residential CCTV footage under Section 67, but only where the “reason to believe” was properly documented and CrPC/BNSS safeguards were followed (source).
The practical problem is that none of this lives in one system. Pre-raid data sits across GSTN, transport, and toll infrastructure. Post-raid evidence is often physical, or scattered across seized devices. An officer or investigating team has to manually reconcile all of it before a pattern becomes a provable case.
Fusing These Sources Into One Evidence Trail
This is the part of the workflow AI genuinely changes, not by replacing the officer’s judgment, but by removing the manual reconciliation that eats most of the time.
Invoice-versus-movement verification
An invoice claims goods were sold. The e-way bill should show the shipment. FASTag data should show the vehicle actually made the trip. When AI cross-checks all three automatically, a mismatch, an invoice with no corresponding vehicle movement, is a strong signal of a paper transaction with no real supply behind it. This is exactly how circular trading schemes get exposed: each individual invoice looks clean in isolation, and the fraud is only visible once the full chain is traced (source).
Entity network mapping
Shell company networks rarely announce themselves. They show up as one individual holding directorships across an unusual number of firms, or a single PAN behind multiple GST registrations. Automating this cross-reference across thousands of entities is not something an officer can reasonably do by hand, but it is exactly the kind of pattern-matching that a fusion layer built on GSTN, PAN, and directorship data can surface quickly.
Chronology and correlation
A case file is stronger when it can show a timeline, not just a list of documents. When did the shell entity register? When did the suspicious invoices begin? Do bank statement deposits correlate with invoice dates? Assembling that timeline manually from disparate sources is where investigations traditionally lose days or weeks. Automated correlation turns that into hours.
What “Case-Ready” Actually Means
A case-ready file is not just a fraud score or an alert. It is:
- A chronological account of the entity’s registration, filing, and transaction history
- Cross-referenced documentation showing where invoices, movement data, and financial records agree or diverge
- Network visualisation showing linked entities, shared directors, and shared addresses, so a senior officer or prosecutor can see the structure at a glance rather than reading through hundreds of pages
- A clear separation between what the data shows and what still requires human interpretation or legal judgment
That last point matters more than it might seem. AI-assisted evidence organisation strengthens what an officer can present, it does not certify that evidence as legally conclusive. Whether a document, timeline, or correlation holds up depends on how it was collected, whether Section 67 procedure was followed, and how it is argued, and that remains squarely a legal and investigative judgment, not an output a system can generate on its own.
Learn more about AI-Powered Financial Intelligence Fusion.
Frequently Asked Questions
1. What is the difference between GST fraud detection and GST fraud investigation?
Detection identifies which entities or transactions look suspicious, usually through risk scoring or anomaly flags on GSTN data. Investigation is the process that follows, gathering, cross-verifying, and organising evidence, often including a physical search under Section 67 of the CGST Act, to establish whether fraud actually occurred and build a case that can proceed to adjudication.
2. What data sources are typically used in a GST fraud investigation?
Pre-raid, investigators work with GSTN return filings, e-way bills, FASTag toll transaction records, and PAN or directorship registries. If a physical search is authorised under Section 67, bank statements, seized documents, and electronic records are added to the evidence base.
3. How is fake invoicing distinguished from a genuine transaction?
By checking whether an invoice’s claimed movement of goods is corroborated elsewhere. An e-way bill should exist for the shipment, and FASTag data should show the vehicle actually made the corresponding trip. When an invoice exists with no matching movement evidence, it points to a paper transaction rather than a real supply of goods.
4. Does AI-assisted evidence replace manual investigation in GST fraud cases?
No. AI can automate cross-verification and pattern detection across large datasets, which significantly reduces the manual reconciliation work involved. It does not replace the investigating officer’s judgment, and it does not substitute for the legal and procedural requirements under Section 67 of the CGST Act, which govern how evidence is collected and whether it holds up.
5. Is this the same as anti-money laundering or income tax investigation?
No. This workflow is scoped specifically to GST and ITC fraud, built on GSTN, e-way bill, FASTag, and PAN/directorship data. Anti-money laundering investigation relies on banking and financial transaction data, and income tax investigation runs under separate statutory powers entirely. They are related enforcement priorities but require different data and different tools.
