GSTR-2B reconciliation shouldn't eat your weekend. Here's why it does.

Every month, there's a fixed ritual in most CA offices. The client sends the purchase register — usually an Excel downloaded from Tally, sometimes a CSV, occasionally a handwritten list photographed and WhatsApp-ed. The CA or their senior downloads the GSTR-2B from the portal. Then begins the VLOOKUP.

Invoice numbers don't match because the client types 'INV/2025-26/001' and the supplier files 'INV-001'. GSTINs have one transposed digit. Amounts differ by the exact GST amount because the client books the net and the supplier files the gross. By the end, you have a 'mismatches' tab with thirty rows that need someone to call the vendor.

This is not a technology problem that's been unsolved. It's just that the available tools weren't designed for how Indian CAs actually work.

Why the mismatch problem is harder than it looks

The naive solution is: match GSTIN + invoice number + date + amount. In practice, none of those four fields are reliable matching keys. Vendor GSTINs are correct in the books about 80% of the time (the rest have old GSTINs, cancelled-then-reactivated GSTINs, or spelling variants). Invoice numbers are not standardised — every tally instance formats them differently. Amounts differ because of rounding, because of the net-vs-gross issue, or because the supplier revised the invoice after your client booked it.

The real matching logic needs to be fuzzy on the invoice number, exact on the GSTIN (after normalisation), within-tolerance on the amount, and aware that the supplier might have filed the same invoice in the prior or next period's 2B if they filed late or early.

What MeshMatch actually does

MeshMatch takes your client's purchase register (CSV export from Tally, Excel, whatever format) and the GSTR-2B JSON from the portal and runs a multi-pass reconciliation:

• Pass 1: Exact GSTIN + normalised invoice number + amount within 1%. This catches the clean matches and typically resolves 70-75% of lines immediately.
• Pass 2: Fuzzy invoice number matching within the same GSTIN — catches the format-variant problem (INV001 vs INV/001 vs 001).
• Pass 3: Timing check — looks in the prior and next period 2B for lines that didn't match in the current period, catching late and early filers.
• Pass 4: GSTIN normalisation pass — catches transposed digits, old GSTINs, and similar structural variants.

What's left after all four passes

After the four passes, what remains is genuinely problematic: vendor didn't file (default), amount too different to be a rounding issue, or invoice truly missing from books. These are sorted by ITC-at-risk amount so the highest-value issues surface first.

For each unresolved mismatch, MeshMatch shows the vendor's filing reliability score — built from their historical behaviour across your client base. A vendor who has a pattern of late filing is categorised differently from one who has never filed at all, which is different again from one who filed the invoice under a different GSTIN.

The output is a resolution workspace: for each mismatch, you choose Claim (ITC is supportable despite 2B gap), Reverse (pull back the ITC), or Outreach (send the vendor a reconciliation request). The decisions are recorded for your audit trail.

The compliance consequence of getting this wrong

From a risk standpoint, ITC claimed in 3B that doesn't appear in 2B is the number-one trigger for GST scrutiny notices right now. The department's ADVAIT system flags these automatically. For any month where your client has a significant 2B gap, having a documented reconciliation with clearly reasoned resolutions on each mismatch is no longer optional — it's your primary defence if a notice arrives.

MeshMatch generates an audit-ready PDF of the reconciliation — matched, mismatched, resolved, and ITC-at-risk summary — that you can keep with your client's workpapers. A ten-minute review process per month, not a two-hour Excel exercise.