Both GSTR-2A and GSTR-2B pull from the same underlying data — your suppliers’ GSTR-1 filings — which is exactly why the two get confused. They answer different questions, and only one of them is what your ITC claims are actually reconciled against.
GSTR-2A: a live, moving view
GSTR-2A is dynamic. It updates continuously as suppliers file or amend their GSTR-1 returns, even for periods that have technically closed. Pull it today and pull it again next week and the numbers can differ, because a supplier who filed late or amended a return changes what shows up. That makes it useful as an ongoing view of what’s been reported against your GSTIN, but unreliable as a fixed point to reconcile a specific tax period against — the ground keeps shifting under it.
GSTR-2B: a static, monthly snapshot
GSTR-2B is generated once a month and then frozen. It draws on GSTR-1 filings up to a fixed cutoff date, and doesn’t change afterward regardless of what suppliers do later. That stability is the entire point — it’s what the GST portal itself intends businesses to use for determining eligible input tax credit for a given period, precisely because it won’t move under you mid-reconciliation.
Why the distinction matters for ITC
Claiming input tax credit against a moving target creates a reconciliation problem that never fully closes — a supplier amendment three months later can retroactively change what GSTR-2A said, but your books for that period are already closed. GSTR-2B avoids that by design: what it says for a period is what it says, permanently. Reconciling ITC claims against GSTR-2B, not GSTR-2A, is what keeps a business’s claimed credit aligned with what the tax authority will actually recognize for that period.
What this means in practice
A reconciliation workflow built around GSTR-2B needs to pull that statement from the portal each period, match it line by line against purchase records, and flag anything that’s only in one side — an invoice you have that the portal doesn’t show, or a portal entry with no matching purchase record. That’s a matching problem, not a data-entry one, and it’s the same shape of problem regardless of which tool runs it.
See how this runs as part of an AP workflow, synced to Tally Prime rather than handled as a separate spreadsheet exercise.