GSTR-2B ITC Reconciliation Runbook: The Five-Day Cycle for Indian Finance Teams

Days 11 to 15 of the monthly reconciliation cadence carry the only Severity 10 anchor in the twenty-day cycle. Section 16(4) of the CGST Act permanently forfeits any input tax credit that is not claimed by the 30th of November following the end of the financial year to which the invoice relates, with no rectification, no condonation, and no refund mechanism in Indian tax law. Every other window in the monthly close playbook carries at most a Severity 9 exposure — bank items age but recover, TDS demand notices carry interest but are correctable, and the GSTR-1 versus GSTR-3B window produces DRC-01B notices that can be replied to. The GSTR-2B window is the only window where a mistake produces an irreversible cash outflow. This is the runbook — day by day, role by role, categorisation bucket by categorisation bucket — for running it as a defensible sequence rather than a scramble on the 20th.

The window was three-way before October 2024 and four-way after. The Invoice Management System, introduced with effect from October 2024, added an action axis that the pre-IMS reconciliation did not have. Every inbound invoice must now carry an explicit Accept, Reject, or Pending action from the recipient before the invoice locks into GSTR-2B on the 14th, and the runbook has to sequence the actions inside the five-day window or the reconciliation collapses into an end-of-cycle scramble to reconcile actions that were never taken. The rest of this article walks the window as it works now — with IMS as the fourth axis and Section 16(4) as the sign-off anchor.

The pre-IMS three-way match and the post-IMS four-way match

The pre-IMS reconciliation ran across three snapshots. The purchase register was extracted from the ERP at month-end. GSTR-2A was the dynamic, auto-populated view that updated in near real time as suppliers filed GSTR-1 or used the Invoice Furnishing Facility. GSTR-2B was the static, locked view generated on the 14th of the following month, carrying the credit that the recipient was allowed to claim under Rule 36(4). The reconciliation ran purchase register against GSTR-2B, used GSTR-2A only as a forward-looking view of items expected in a subsequent 2B, and produced an ITC figure for GSTR-3B Table 4.

The post-IMS reconciliation runs across four snapshots. The purchase register and GSTR-2B stay in place. The IMS action log becomes the third axis — every inbound invoice must be marked Accept, Reject, or Pending by the recipient before the 14th, and the action taken determines whether the invoice flows into GSTR-2B, is rejected out of GSTR-2B, or defers to a subsequent month’s 2B. The fourth axis is the GSTR-3B claim register itself — the working paper that carries the final Table 4 figure back to the reconciliation for cross-tie. GSTR-2A is effectively subordinated to the IMS pathway.

The change matters because the failure modes shift. Under the three-way regime, the dominant failure was supplier-side — a supplier who filed GSTR-1 late crossed the buyer’s monthly cutoff and the credit slipped to a subsequent 2B. Under the four-way regime, the dominant failure adds a recipient-side default — a missed IMS action that lets a wrongly issued or duplicate invoice default to Accept and silently pull into the claim. Framing the runbook as four-way keeps the IMS action axis visible and prevents the sequence from collapsing back into the pre-IMS shape. The failure-anchored design layer for this shift is documented in the GSTR-2B ITC reconciliation failure modes article; this runbook is how the design gets executed. To see what the sequence is designed to catch, read the failure modes article alongside this one — the two are bidirectional.

The owner map for the window

The window carries three named roles.

• The indirect tax executive runs the sequence. IMS actions, GSTR-2B pull, purchase register extract, three-way match, categorisation, Rule 42/43/37/37A working, Section 17(5) block-class exclusion, at-risk queue refresh.
• The tax manager reviews. Independent review on Day 14 covering the reversal workings and the categorisation; sample-based tick-and-tie on Day 15 covering the bucket-one matched population.
• The controller signs off. The Section 16(4) exposure is Severity 10, and no other sign-off can carry the exposure. The controller’s signature on Day 15 releases the ITC figure to Day 18 GSTR-3B assembly.

The reason the controller and not the tax manager signs off is Terra Insight’s reconciliation process design method: where a Severity 10 anchor sits behind a function, the sign-off must be at the level of executive accountability, not at the level of process ownership. The tax manager can run the review; the tax manager cannot own the Section 16(4) exposure. The controller can, and does.

Day 11 — Complete IMS actions on the closed month’s inbound

Day 11 exists because GSTR-2B is generated on the 14th of the following month and every invoice must have an IMS action before the 14th auto-lock. Missing an IMS action defaults the invoice to Accept — which is the single most common recipient-side failure mode in the post-IMS regime and the reason the IMS action step-by-step article documents the click paths on the GST portal.

The indirect tax executive opens the IMS dashboard, filters by the closed month’s inbound, and works through the pending list.

• Accept. The invoice matches an inward supply the AP team has booked in the closed month. The credit is intended and the invoice will flow into GSTR-2B on the 14th.
• Reject. The invoice does not match an inward supply, or the GSTIN is wrong, or the line is a duplicate of a previously accepted invoice, or the supply is on a Section 17(5) block-class category that the recipient does not want to draw into the claim register. The rejected invoice does not flow into GSTR-2B.
• Pending. The invoice is real but the AP team has not yet booked it, or the recipient wants to defer the credit to a subsequent month for cash-flow reasons, or the invoice carries a dispute that is not yet resolved. The pending invoice defers to a subsequent month’s 2B.

Every invoice must have exactly one action taken. Day 11 closes with a completeness check — the count of open pending items on the IMS dashboard for the closed month must be zero, or every remaining open item must have a documented reason. This is the gate that stops the default-to-Accept failure mode from silently pulling wrong invoices into the claim.

Day 12 — Pull GSTR-2B and extract the purchase register

GSTR-2B is generated on the 14th but is subject to intra-day updates on the generation date. The runbook pulls on the 15th to work against a stable snapshot. If the recipient’s finance calendar shifts the twenty-day cycle so that Day 12 lands on the 14th, the tax executive pulls a preliminary 2B and re-pulls on Day 13 against the stable version. The reconciliation runs against the stable pull; the preliminary pull is used only as a scoping view.

The purchase register is extracted from the ERP dated to the last calendar day of the closed month. The extract carries invoice number, invoice date, supplier GSTIN, taxable value, CGST, SGST, IGST, cess, place of supply, HSN code, and the AP booking date. The AP booking date is what will drive the Rule 37 180-day payment clock on Day 14; the invoice date is what will drive the Section 16(4) at-risk queue.

Both extracts are archived in the monthly folder with a timestamp and a hash. The IMS versus GSTR-2B three-way article walks the file structures. The tax executive loads both into the working paper — a four-column layout with the purchase register on the left, GSTR-2B on the right, the IMS action log as a joining axis, and an empty categorisation column on the far right that Day 13 will populate.

Day 13 — The three-way match with five categorisation buckets

Day 13 is the heart of the window. The tax executive runs the three-way match — purchase register versus GSTR-2B versus IMS action log — and categorises every invoice into one of five mutually exclusive buckets. Every invoice must land in exactly one bucket, and every bucket has a documented downstream action.

Bucket 1 — In purchase register and in GSTR-2B (matched)

The invoice is booked in the recipient’s ERP and appears in GSTR-2B with an IMS Accept action taken. This is the bucket that populates GSTR-3B Table 4 as the claimable ITC, net of Section 17(5) blocks and Rule 42/43 reversals that Day 14 will apply. Expect 65 to 80 per cent of the closed month’s invoice count to land here for a team with a stable vendor base and a disciplined IMS cadence. A team below 60 per cent is either mis-timing the purchase register extract or not disciplined on IMS actions.

Bucket 2 — In purchase register, not in GSTR-2B

The invoice is booked in the recipient’s ERP but has not appeared in GSTR-2B. The most common cause is that the supplier has not filed GSTR-1 by the 14th of the following month. This bucket moves to the at-risk queue with the Section 16(4) November 30 deadline as the escalation trigger. The Rule 37 and Rule 37A article documents the supplier-side failure modes that drop invoices into this bucket — supplier under QRMP filing the invoice in a subsequent quarter’s IFF, supplier facing a technical filing failure on the GST portal, supplier disputing the invoice or the recipient’s GSTIN. The at-risk queue must carry each invoice by supplier GSTIN, invoice date, taxable value, and days remaining to the Section 16(4) deadline.

Bucket 3 — In GSTR-2B, not in purchase register

The invoice appears in GSTR-2B but is not booked in the recipient’s ERP. Two very different causes drive this bucket and both are investigated on the same day. Cause A is a ghost invoice — a supplier has raised an invoice against the recipient’s GSTIN without a corresponding inward supply. This is a fraud vector and the tax executive escalates to the tax manager on the same day for verification with the supplier. Cause B is a missed AP booking — the inward supply is real, the goods or services were received, the invoice was raised by the supplier, but the AP team failed to book the invoice in the closed month. This is a cutoff failure and the resolution is to book the invoice in the current month with a prior-period documentation note. Either way, no ITC is claimed until the reason is resolved.

Bucket 4 — In GSTR-2B with IMS Reject taken

The invoice appears in GSTR-2B because the supplier has filed GSTR-1, but the recipient marked it Reject on the IMS dashboard on Day 11. The correct outcome is that the invoice does not appear in GSTR-2B at all if the Reject action was taken before the 14th — but where a Reject action is taken after generation, the invoice may still surface until the next 2B cycle drops it. No ITC is claimed on this invoice. The bucket exists as an audit-trail category so the reviewer can confirm on Day 14 that the Reject action was taken for a valid reason (wrong GSTIN, duplicate line, block-class supply) and not by mistake.

Bucket 5 — In GSTR-2B with IMS Pending taken

The recipient marked the invoice Pending on Day 11 and the invoice will defer to a subsequent month’s GSTR-2B. No ITC is claimed in the current cycle. The bucket exists so the reviewer can confirm the deferral reason (AP booking not yet complete, supply under dispute, cash-flow-driven deferral) and so the invoice can be re-scored in a subsequent Day 13 exercise. Pending invoices are not on the Section 16(4) clock the same way Bucket 2 items are — the recipient has taken an action, and the clock resumes when the recipient shifts the action to Accept.

The categorisation table is the working paper’s primary deliverable for Day 13. Every invoice count reconciles — purchase register total equals Bucket 1 plus Bucket 2 plus Bucket 3 (missed AP booking sub-population), and GSTR-2B total equals Bucket 1 plus Bucket 3 plus Bucket 4 plus Bucket 5. Any reconciliation gap in the totals is a bug in the working paper and must be resolved before the Day 14 review.

Day 14 — Reversals, blocks, and the reviewer’s independent check

Day 14 layers four reversal and exclusion working papers on top of the Day 13 categorisation.

Rule 42 and Rule 43 common credit

Rule 42 governs the reversal of common ITC on inputs and input services used partly for taxable supplies and partly for exempt or non-business supplies. Rule 43 governs the same reversal for capital goods on a 60-month basis. The working paper isolates common credit invoices from the Bucket 1 population, applies the exempt-turnover ratio for the closed month, computes the reversal, and reserves it for the Day 18 GSTR-3B assembly. Businesses with any exempt or non-business supply — dairy processors with exempt milk output, hospitals with exempt healthcare supply, real-estate developers with residential completion supply — must maintain this working paper monthly.

Rule 37 — 180-day non-payment reversal

Rule 37 requires reversal of ITC availed on any invoice where the recipient has not paid the supplier within 180 days of the invoice date. The working paper walks the AP aging as of Day 14, isolates every invoice above the 180-day threshold that carries booked ITC, and reverses the credit with interest under Section 50. When the recipient subsequently pays the supplier, the credit becomes re-claimable in the month of payment. The reversal flag is set in the ERP against the invoice line so the reclaim is picked up in a subsequent cycle.

Rule 37A — Supplier non-filing reversal

Rule 37A requires the recipient to reverse any ITC availed against an invoice whose supplier subsequently fails to file GSTR-3B by the 30th day of September following the end of the financial year. This is a year-end-anchored reversal — the tax executive maintains a Rule 37A tracker keyed to supplier GSTIN and monitors the supplier’s GSTR-3B filing status through the year. In the September window, the tracker becomes an active reversal working paper. Curing the default in a subsequent period reopens the credit as a reclaim candidate.

Section 17(5) — Blocked ITC

Section 17(5) blocks ITC on named categories of inward supply — motor vehicles below the seating threshold, food and beverage other than in specified circumstances, works contract for construction of immovable property, membership of clubs, insurance and health services for personal use, and goods lost, stolen, destroyed, or given as gifts or free samples. The block class overrides the Rule 36(4) ceiling — any invoice that qualifies as a Section 17(5) block is excluded from the ITC claim regardless of whether it appears in GSTR-2B. The tax executive walks the Bucket 1 population against the block-class register maintained in the ERP and excludes the qualifying lines.

The tax manager independently reviews the four workings on Day 14, samples the Bucket 1 population against source invoices, and confirms the categorisation logic on Buckets 3 and 4. Anything the reviewer cannot trace to a documented rule is escalated to the controller before Day 15 sign-off. The DRC-01C ITC mismatch reply article documents what happens if a Rule 36(4) breach slips past this review and lands as a Rule 88D auto-notice — the response timeline is 30 days and the reply must cite the same working paper that Day 14 produced.

Day 15 — Controller sign-off and the at-risk queue

Day 15 closes the window. The controller signs off the ITC figure that will populate GSTR-3B Table 4. The signature is on a one-page working paper that carries the bucket reconciliation, the four reversal and block workings, and the net Table 4 figure. The signature releases the figure to the Day 18 GSTR-3B assembly and closes the window.

The at-risk queue is the second Day 15 deliverable. Every Bucket 2 invoice enters the queue keyed to invoice date and supplier GSTIN. The queue is a standing register — it does not close at the end of the window. Every subsequent GSTR-2B pull removes invoices that have landed and adds new invoices that have not. Escalation runs against calendar dates, not against reconciliation cycles.

• Tier 1 — 30 days after the missed 2B. Standard supplier follow-up letter goes out under the tax executive’s name. The letter carries the invoice number, invoice date, taxable value, and a request for filing status.
• Tier 2 — 60 days after the missed 2B. Escalated to the controller. Second follow-up letter, and the supplier’s key account owner in procurement is looped in.
• Tier 3 — Calculated backward from November 30. For a March invoice with a September Tier 2 firing without a filing, Tier 3 lands in September or October to leave two months before the permanent-loss trigger. For a June invoice with the same pattern, Tier 3 lands in September, October, or early November. The queue must be re-scored monthly against the November 30 clock so the Tier 3 date reflects the current runway.

The at-risk queue is the canonical High-Action-Priority detection control for the GSTR-2B stream in Terra Insight’s reconciliation process design method. Every High-AP failure mode carries a Severity 10 anchor; every Severity 10 anchor requires two independent detection controls, one of which must be either a system-enforced rule or an aging queue with an explicit escalation trigger. The at-risk queue is the aging queue.

When manual reconciliation outgrows the five-day window

The Day 11 to Day 15 cadence works for a finance team with roughly 200 or fewer active vendors under GSTR-2B on a single GSTIN with a stable AP process. Three thresholds break the cadence.

• 200-plus vendors on a single GSTIN. The IMS action cadence on Day 11, the vendor-side GSTR-1 follow-up letters on Day 15, and the at-risk queue refresh consume more analyst time than the window can carry. Above 500 vendors, the daily IMS refresh cannot be run inside a five-day window at all.
• Multi-GSTIN groups. The cross-GSTIN reconciliation, IMS action segregation by GSTIN, and intercompany ITC allocation compress the five-day window into a three-day window for the group controller — which forces the team to defer either the Rule 42 and 43 reversals or the Rule 37 and 37A tracker.
• Aggregator-heavy revenue models. Restaurants running four or more delivery platforms, hotels running four or more OTAs, and marketplace sellers running Amazon plus Flipkart plus one or two verticals each carry commission GSTIN-level GSTR-2B ITC pulls that fragment the reconciliation surface.

Above these thresholds, the runbook remains valuable as a training document and a review discipline, but the continuous detection layer — the at-risk queue, the IMS action monitoring, the supplier follow-up cadence — needs to move from the analyst’s spreadsheet to a system that runs on a daily rather than monthly cadence. This is the point at which Terra Insight’s GST reconciliation software installs the at-risk ITC queue as a first-class continuously-refreshed output against the Section 16(4) clock, and the manual runbook keeps its role as the discipline the system runs against, not the process the finance team runs by hand.

Where this fits

• The Reconciliation Playbook — monthly close pillar
• GSTR-2B ITC reconciliation failure modes — the design layer
• Section 16(4) ITC time bar
• Invoice Management System reconciliation
• IMS versus GSTR-2B three-way reconciliation
• Rule 37 and Rule 37A ITC reversal

Related reading

• Reconciliation failure analysis — the process design method
• DRC-01C ITC mismatch reply
• DRC-01B reconciliation reply
• GSTR-9C three-way mismatch reconciliation
• Reconciliation software for India — pillar
• TransactIG — reconciliation infrastructure

Frequently Asked Questions

What is the difference between the pre-IMS three-way match and the post-IMS four-way match?

Before October 2024, the GSTR-2B reconciliation ran as a three-way match across the purchase register, GSTR-2A (the dynamic auto-populated view), and GSTR-2B (the static locked view generated on the 14th). After October 2024, the reconciliation runs as a four-way match — purchase register, GSTR-2B, IMS action log, and the GSTR-3B claim register. IMS adds a decision axis that did not exist before; every inbound invoice must carry an explicit Accept, Reject, or Pending action from the recipient before the 14th, and missing an action defaults the invoice to Accept, which is the failure mode most likely to silently pull a wrongly issued or duplicate invoice into ITC.

Why does the controller sign off the GSTR-2B window rather than the tax manager?

Because the GSTR-2B window carries the only Severity 10 anchor in the reconciliation cadence. Section 16(4) permanently forfeits any ITC not claimed by the 30th of November following the end of the financial year to which the invoice relates. Every other window carries at most a Severity 9 exposure — Section 200A demand notices are recoverable through correction, DRC-01B replies work within a 30-day timeline. The GSTR-2B window is the only window where a mistake produces an irreversible cash outflow, and the sign-off must be at the level of executive accountability.

What are the five categorisation buckets for the Day 13 three-way match?

Bucket one is invoices in both the purchase register and GSTR-2B — matched, claimed in Table 4 net of Section 17(5) blocks and Rule 42/43 reversals. Bucket two is in the purchase register but not in GSTR-2B — the at-risk queue against the Section 16(4) deadline. Bucket three is in GSTR-2B but not in the purchase register — either a ghost invoice or a missed AP booking, both investigated on the same day. Bucket four is in GSTR-2B with an IMS Reject action taken — not claimed, and the reviewer confirms the rejection reason. Bucket five is in GSTR-2B with an IMS Pending action taken — deferred to a subsequent month. Every invoice lands in exactly one bucket.

How does the at-risk queue against Section 16(4) work?

The at-risk queue is a standing register of every purchase-register invoice whose supplier has not yet filed GSTR-1, keyed to invoice date, supplier GSTIN, and days remaining until the 30th of November of the following financial year. The queue is refreshed after every GSTR-2B pull. Escalation runs against calendar dates. Tier 1 fires 30 days after the missed GSTR-2B; Tier 2 at 60 days; Tier 3 is calculated backward from November 30 to leave two months of runway before the permanent-loss trigger. Above 200 vendors the queue must refresh daily rather than monthly, which is the threshold at which the manual runbook outgrows the reconciliation cadence.

When does the Day 11 to Day 15 manual runbook outgrow itself?

The cadence works for a finance team with roughly 200 or fewer active vendors on a single GSTIN with a stable AP process. Three thresholds break it — 200-plus vendors (where the IMS action cadence, the follow-up letters, and the queue refresh consume more analyst time than the window can carry); multi-GSTIN groups (where cross-entity reconciliation compresses the window); and aggregator-heavy models where four-plus platforms fragment the reconciliation surface. Above these thresholds the runbook remains a training discipline, but the continuous detection layer — the at-risk queue in particular — needs to move from the analyst’s spreadsheet to a system that runs daily against the Section 16(4) clock.

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published Invalid Date

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024