GSTR-2B vs Purchase Register Reconciliation

The Problem

For any GST-registered business in India, reconciling the auto-drafted GSTR-2B statement downloaded from the GST portal against the purchase register maintained in books is a mandatory prerequisite for claiming input tax credit (ITC). Under Section 16(2)(aa) of the CGST Act, 2017, a registered person can claim ITC on an inward supply only to the extent the details of that supply appear in the recipient's GSTR-2B. Without a line-by-line reconciliation, a company cannot determine with legal certainty which invoices are eligible, which require reversal, and which need supplier follow-up before the GSTR-3B filing deadline.

In practice, a mid-market controller at a company with 200–500 purchase invoices per month spends two to three full working days on this reconciliation each period. The task involves downloading the GSTR-2B JSON or Excel from the portal, standardising column names against the purchase register, constructing composite match keys from supplier GSTIN, invoice number, and invoice date, and then computing tax-head-wise differences across IGST, CGST, and SGST — all in Excel with VLOOKUP chains or manual copy-paste. A single transposition error in a GSTIN or a capital-O-versus-zero typo in an invoice number breaks the match silently, leaving the exception undetected.

The scale problem compounds quickly. At 300 invoices per period, a one-person finance team running this in Excel will miss low-value mismatches that individually fall under scrutiny thresholds but cumulatively produce a material ITC difference. The GST department's ASMT-10 notices and demand orders under Section 73 and Section 74 of the CGST Act are increasingly automated and data-driven, making manual reconciliation errors costlier than they were before the GSTN's analytics layer was active.

Why It Matters: Context

Section 16(2)(aa) of the CGST Act, inserted by the Finance Act 2021 and effective from 1 January 2022, made GSTR-2B the authoritative document for ITC eligibility. An invoice that exists in books but is absent from GSTR-2B — because the supplier has not yet filed GSTR-1 or GSTR-1A — does not qualify for ITC in that tax period. Conversely, an invoice that appears in GSTR-2B but is unbooked in the purchase register represents a missed ITC opportunity. The CBIC's Circular No. 183/15/2022-GST clarified tolerance limits and the reconciliation procedure, and the GST Council's Rule 36(4) framework caps provisional ITC at amounts reflected in GSTR-2B, removing any buffer that older provisional credit rules provided.

For a mid-market company — typically lacking a dedicated GST technology team or a big-four managed service — this reconciliation is performed by the same controller who closes the books, prepares TDS workings, and files advance tax. The four exception classes that arise every period are: (1) invoices present in GSTR-2B but missing from books, (2) invoices booked but absent from GSTR-2B, (3) taxable value or tax amount differences beyond a ₹1 tolerance, and (4) GSTIN or invoice-number mismatches caused by data-entry errors in either the ERP or the supplier's GSTR-1. Each class requires a different resolution action — booking an entry, reversing ITC, or writing to the supplier — and the actions must be completed before the GSTR-3B due date for that period.

Failure to reconcile correctly produces three categories of adverse outcomes: an ITC reversal demand with 18% per annum interest under Section 50 of the CGST Act from the date of original credit, a penalty of up to 100% of the tax amount under Section 74 where the department alleges intent, and, in a statutory audit context, a qualified opinion or emphasis-of-matter paragraph where the auditor cannot verify ITC balances against GSTR-2B — a disclosure that triggers further regulatory scrutiny.

What This Workflow Automates

1. The controller uploads two files to the workflow: the GSTR-2B extract (sheet: GSTR-2B Extract, columns including supplier_gstin, invoice_no, invoice_date, taxable_value, igst, cgst, sgst, filing_period) and the purchase register (sheet: Purchase Register, columns including vendor_gstin, bill_no, bill_date, taxable_value, igst, cgst, sgst, booking_period).
2. The workflow parses and normalises both files — trimming whitespace, upper-casing GSTINs, and standardising invoice number strings — to eliminate case-sensitivity and spacing false mismatches before any comparison begins.
3. A composite key of supplier GSTIN + invoice number + invoice date is constructed for every row in both datasets, and a deterministic three-way join identifies matched pairs, GSTR-2B-only rows, and purchase-register-only rows.
4. For each matched pair, the workflow computes tax-head-wise differences: Δ IGST, Δ CGST, and Δ SGST — and applies a ₹1 tolerance per head; differences exceeding this threshold are flagged as mismatches requiring follow-up.
5. Each row is assigned one of three working-paper statuses: Eligible ITC (all checks pass), Mismatch — follow up (tax difference, GSTIN mismatch, or invoice-number typo detected), or ITC to be reversed (invoice is books-only — supplier has not filed).
6. For invoice-number near-mismatches — such as INV-2026-O412 (capital O) versus INV-2026-0412 (digit zero) — the workflow surfaces a fuzzy-match suggestion, allowing the controller to confirm and reclassify without manually scanning both lists.
7. The output is an Excel reconciliation table with status badges, tax-head-wise delta columns, and a summary count of rows in each exception class, delivered directly to the Cadel inbox and ready for attachment to the GSTR-3B working file.

All seven steps execute in under 60 seconds for a dataset of up to 500 invoice lines, and every classification decision is deterministic and traceable to the underlying match-key logic — giving the controller a fully auditable output rather than a black-box result.

Edge Cases We Simulate

The workflow ships with a battery of synthetic test scenarios that exercise every failure mode we have seen in real-world data. Each scenario produces a deterministic outcome that an auditor or controller can verify in seconds.

Sample Documents

Download or inspect the seeded sample files used to demonstrate this workflow:

Sample Results

Running the workflow against the eight demo files — four GSTR-2B variants and four corresponding purchase register variants — produced the following results. The clean pair (GSTIN 27ACMEA1234B1Z5, invoice INV-2026-0412, taxable value ₹5,00,000, CGST ₹45,000, SGST ₹45,000) matched on all five checks — GSTIN, invoice number, invoice date, taxable value, and total tax — and was classified as Eligible ITC with zero delta on any tax head. The tax-amount-mismatch pair produced a CGST delta of ₹2,500 and an SGST delta of ₹2,500 (GSTR-2B reported ₹42,500 each; purchase register showed ₹45,000 each), resulting in a Mismatch — follow up classification and a total excess ITC flag of ₹5,000. The books-only pair — invoice ACM-INV-9981 from Acme Corp Ltd (GSTIN 27ACMEA1234B1Z5, taxable value ₹3,20,000, CGST + SGST ₹57,600) — was present in the purchase register for Feb-2026 but absent from GSTR-2B, triggering an ITC to be reversed classification with a supplier-follow-up note. The filing-period alignment check passed for all documents where a period_label was present (booking period Feb-2026 matched across all applicable rows), confirming no cross-period pollution in the demo dataset.

The invoice-number-typo pair illustrated the most operationally significant exception class: the purchase register recorded bill number INV-2026-O412 (capital letter O in position 10) while GSTR-2B contained INV-2026-0412 (digit zero), causing the composite-key join to return zero matches despite GSTIN and all tax amounts agreeing exactly. Without fuzzy-match detection, this invoice would appear as both a 2B-only entry and a books-only entry simultaneously — inflating the exception count by two rows and causing the controller to flag ₹90,000 of ITC as potentially ineligible when it is, in fact, a clean transaction with a data-entry error. The workflow surfaces this as a single Mismatch — follow up / possible typo row with the fuzzy-match suggestion displayed, reducing resolution time from an investigative lookup to a single confirmation click.

Why Automation Wins Here

This workflow reduces a reconciliation task that typically occupies two to three working days — data download, column normalisation, VLOOKUP construction, exception enumeration, and working-paper formatting — to under 60 seconds of machine execution followed by a controller review of the flagged exception rows. Across the four deterministic exception classes (2B-only, books-only, tax-amount mismatch beyond ₹1, and GSTIN/invoice-number mismatch), every row receives an explicit, auditable classification; no exception is silently dropped. For a mid-market company processing 300 purchase invoices per period, this eliminates the compounding risk of missed ITC reversals attracting 18% per annum interest under Section 50 of the CGST Act and removes the human-error vector that produces GSTIN or invoice-number typo misses in Excel-based workflows.

The output artifact — an Excel reconciliation table with status badges (Eligible ITC, Mismatch — follow up, ITC to be reversed), tax-head-wise delta columns (Δ IGST, Δ CGST, Δ SGST), and a summary exception count — is formatted to drop directly into the GSTR-3B working file and satisfies the documentation expectations of a statutory auditor reviewing ITC balances under SA 500 (Audit Evidence). The controller signs off on the exception dispositions, and the signed Excel becomes part of the period-close audit file without any reformatting step.

Frequently Asked Questions