GSTR-2B Reconciliation for CA Firms: A Step-by-Step Guide

A purchase register entry for "M/s. Rajesh Enterprises" and a GSTR-2B entry for "RAJESH ENTERPRISES PVT LTD" are the same vendor to a human and different strings to a naive matching script. Multiply that across split GSTINs, partially settled invoices, and values that round differently between systems, and exact-match reconciliation produces a mismatch queue that's mostly noise — real exceptions buried under formatting differences.

Useful reconciliation logic matches on GSTIN plus a tolerance band on invoice value and date, with fuzzy vendor-name matching as a fallback rather than the primary key. Rounded values, partially settled invoices, and minor date shifts between when a supplier issued an invoice and when it appears in GSTR-2B shouldn't each generate a manual review item.

Not every matched invoice is automatically claimable, and not every unmatched invoice is automatically ineligible. A useful reconciliation output splits invoices into three buckets — safe to claim, needs review, and can't claim — computed separately from the raw purchase register and from GSTR-2B, with a net-claimed figure that reflects reversals and re-claims, not just a gross match count.

The firm-level version of this problem isn't matching logic — it's doing that matching consistently across every client without re-running the same manual process per GSTIN. One-click reconciliation with configurable rules per client, bulk accept/reject/pending actions, and live counters for reconciled, reversal, pending, and reclaim status are what separate a firm handling 20 clients from one handling 200.