Guide on ISD Reconciliation and Exception Reports

Introduction

Filing GSTR-6 is not the end of the ISD compliance cycle. It is the midpoint.

Once the ISD distributes credit to recipient units through GSTR-6, those units see the credit in their GSTR-2A. They then claim it in their GSTR-3B. In a well-functioning system, what the ISD distributed and what each unit claimed should match exactly. In practice, they often do not.

A unit may claim less than what was distributed – perhaps because their team missed the ISD invoice in their GSTR-2A review. A unit may claim more – perhaps because they also had direct supplier invoices for the same service alongside the ISD credit. The ISD may have distributed credit that turned out to be ineligible, requiring a reversal. A supplier may have amended an invoice after GSTR-6 was filed, changing the available credit amount.

Each of these situations creates a gap between what was distributed and what was claimed. Without a reconciliation engine, these gaps are invisible until a GST notice surfaces months later. With one, they are caught in the same month and resolved before they compound.

This blog covers how an ISD reconciliation platform works end to end – the three-way match it performs, the exception buckets it creates, how recipient unit queries are handled, and the forensic trail it maintains for audit and dispute resolution.

Why ISD Reconciliation Is More Complex Than Standard GST Reconciliation

Standard GST return reconciliation compares GSTR-2B against GSTR-3B – a two-party match. ISD reconciliation is a three-party, three-document match.

The reconciliation engine must simultaneously verify that the ISD received the correct ITC from the supplier, that it distributed the correct amount to each unit, that each recipient unit’s GSTR-2A reflects the distributed credit, and that each unit claimed the correct amount in GSTR-3B.

Add to this the complexity of tax head conversions for out-of-state units, multiple financial years of pending credit, ineligible credit flags, and GSTR-6A amendments – and it is clear why manual reconciliation of ISD credit is one of the highest-risk compliance tasks in a group GST structure.

The Three-Way Match Engine – How Reconciliation Works

The reconciliation platform runs a structured three-way match every month. Here is how each layer works.

Layer 1 – Supplier Invoice vs GSTR-6A vs ISD Purchase Register

The first reconciliation confirms that the ISD has received and recorded all supplier invoices correctly.

Common exceptions at this layer:

• Invoice in GSTR-6A, not in ISD register: Supplier filed in GSTR-1 but ISD has not booked it. Credit is available on the portal but the ISD has not recognised it.
• Invoice in ISD register, not in GSTR-6A: ISD has the bill but the supplier has not filed GSTR-1 yet. ITC cannot be distributed until the supplier files.
• Amount mismatch: Supplier filed a different value than what was invoiced. The ISD must use the GSTR-6A figure for distribution.
• Tax head mismatch: Supplier filed IGST but the invoice shows CGST + SGST. Distributing under the wrong head creates downstream errors for recipient units.

Layer 2 – GSTR-6 Distributed vs ISD Allocation Records

This layer confirms that what the ISD filed in GSTR-6 matches what the allocation engine computed and documented internally.

This layer is primarily an internal consistency check. Exceptions here typically indicate that GSTR-6 was manually edited after the allocation engine computed the splits, or that a filing error occurred during portal submission.

Exception Buckets – How Gaps Are Classified

Not all reconciliation gaps are the same. A mature ISD reconciliation platform classifies every exception into a defined bucket so the right team handles it through the right resolution path.

Records where the invoice exists in both the purchase register and GSTR-6A, and the difference in taxable value, tax amount, and invoice value falls within the user-defined tolerable range, are placed under Matched by Tolerance.

Where discrepancies exist beyond the tolerable range or multiple fields are mismatching, the record is flagged as Mismatched. Entries that are close but do not fully align are captured as Near Matched, resolved through an ML-based reconciliation engine that intelligently maps probable pairs.

Where a supplier has reported the invoice in their GSTR-1 and it reflects in GSTR-6A but has no corresponding entry in the purchase register, it is bucketed as GSTR-6A Only. Conversely, invoices present in the purchase register but absent in GSTR-6A are classified as PR Only.

Each bucket routes exceptions to the appropriate team with a defined resolution path, ensuring no gap goes unaddressed. For a detailed overview of ISD compliance mandates effective from April 2025, including GSTR-6 filing obligations and audit requirements, see our dedicated guide.

GSTR-6A Reconciliation – The Missing Link

GSTR-6A is the auto-populated read-only form generated for the ISD based on suppliers’ GSTR-1 filings. It shows the ISD what credit is available for distribution. GSTR-6 is what the ISD actually files after reviewing and editing GSTR-6A.

Why GSTR-6A Reconciliation Is Critical Despite Not Being Mandatory

• Prevents distribution of unavailable credit: If the ISD distributes credit for an invoice that is in their purchase register but not yet in GSTR-6A, the recipient unit’s GSTR-2A will not reflect it. The unit cannot claim it. The distribution is premature and creates an exception immediately.
• Catches supplier amount errors before distribution: If a supplier filed a different amount in GSTR-1 than what is on their invoice, distributing the booked amount creates a GSTR-6A vs GSTR-6 mismatch.
• Identifies missing supplier filings: Invoices in the ISD’s purchase register that are not yet in GSTR-6A mean the supplier has not filed. The ISD needs to follow up before the 11th to ensure credit is available for distribution before the 13th deadline.

The GSTR-6A Reconciliation Status Categories

The ISD Exception Report – Structure and Contents

The ISD exception report is the monthly output of the reconciliation engine. For a broader view of how ISD exception reporting fits into the end-to-end ISD workflow under GST, see our dedicated resource. The report is the primary working document for the ISD’s compliance team and the CAs of each recipient unit.

Report Structure

A well-designed ISD exception report has the following sections:

• Executive summary: Total credit distributed this month, total reflected in GSTR-2A of all units, total claimed in GSTR-3B of all units, total exceptions by bucket, and total ITC at risk.
• Bucket-wise exception detail: Each exception bucket listed separately with invoice-level detail – supplier GSTIN, ISD invoice number, recipient GSTIN, amount, tax head, exception type, and suggested resolution.
• Unit-wise reconciliation summary: For each recipient GSTIN – credit distributed vs credit reflected vs credit claimed, with variance amount and exception status.
• Supplier-wise GSTR-6A mismatch report: For each supplier with a GSTR-6A mismatch – original invoice vs portal value, mismatch type, and follow-up status.
• Forensic trail export: On-demand export of the full event chain for any invoice or unit, in structured format for use in audit responses.

ISD Reconciliation on Cygnet’s Platform

Cygnet’s GST Platform integrates ISD reconciliation directly with the credit allocation engine and GSTR-6 filing module. Reconciliation is not a separate tool – it runs as a continuous background process from the moment GSTR-6A is auto-populated, well before GSTR-6 is filed.

Platform Capabilities

What This Means for Group Tax Teams

• No credit leakage: Every unclaimed ISD credit is flagged and escalated before the claim window closes.
• No over-claim risk: Over-claims are detected in the same month and reversed before a notice arrives.
• No disputed distributions: Recipient units get structured, documented answers to every credit query through the platform, not through email threads.
• Audit-ready from day one: The forensic trail is maintained continuously. When a notice arrives, the response preparation starts immediately – not from a blank spreadsheet.

Common ISD Reconciliation Mistakes

• Not reconciling GSTR-6A before filing GSTR-6: Distributing credit that is not yet in GSTR-6A creates exceptions that require GSTR-6 amendments to fix.
• Treating unclaimed credit as a unit-level issue only: The ISD is responsible for ensuring distributed credit is claimed. Unclaimed credit is a group ITC loss, not just a unit problem.
• Ignoring ineligible credit distribution: ISD must distribute ineligible credit separately in GSTR-6 Table 5. Skipping this step is a compliance failure, not an option.

Conclusion

ISD credit allocation does not end when GSTR-6 is filed. The credit must travel from the ISD’s GSTR-6 through the recipient’s GSTR-2A and into their GSTR-3B claim. Each step in that journey is a potential point of failure – and each failure has a financial consequence.

An ISD reconciliation engine makes that journey visible. It runs the three-way match, classifies every gap into a specific exception bucket, flags ineligible credit before it is wrongly claimed, and maintains a forensic trail that turns audit responses from a reconstruction exercise into a retrieval exercise. The combination of exception buckets, structured recipient query handling, and a complete forensic trail is what separates a compliance-grade ISD reconciliation platform from a spreadsheet. For group entities now managing ISD compliance as a mandatory obligation, these tools are the foundation of a defensible, audit-ready ISD workflow.

FAQs