mb mybillbook private beta

2026-05-11 · 8 min read · Product

Why GSTR-2B reconciliation is still done in Excel

Every chartered accountant in India does the same thing on the 15th of every month. They log into the GST portal, download the GSTR-2B JSON for each of their clients, paste it into Excel alongside the client's purchase register, and start cross-ticking invoice numbers by hand. It takes hours. It is the single most common manual task in mid-tier CA practices in this country.

What 2B reconciliation actually solves

GSTR-2B is the GST portal's auto-drafted view of what your suppliers reported they sold to you. It's the official answer to "how much input tax credit (ITC) am I entitled to claim?". If you claim ITC from a bill that doesn't appear in 2B, the portal flags a mismatch and your business is at audit risk. If you don't claim ITC on a bill that does appear in 2B, you're leaving money on the table.

The reconciliation answers four questions:

  1. Which of my booked purchases match what the supplier filed? (the trivial case)
  2. Which match by invoice number but disagree on tax amounts? (the over- or under-claim risk)
  3. Which of my booked purchases haven't been filed by the supplier yet? (chase them)
  4. Which supplier filings haven't been booked yet in my books? (record them, or flag a fake invoice)

Why Excel is the wrong tool

Excel doesn't know what a GSTIN is. It can't tell a 4-digit HSN code from a 6-digit one when comparing rows. It can't apply a ±₹1 tolerance per tax field while keeping a ±7-day tolerance on the invoice date. It can't preserve "this discrepancy was reviewed and accepted by the CA" across re-uploads. Most importantly: it makes a CA do this for every client every month.

A typical mid-tier CA firm handles 50–200 GST-registered clients. That's 50–200 monthly reconciliations. At 30 minutes each (the fast case), that's 25–100 hours a month — a full team-member's work just on Excel cross-ticks.

Why competing SaaS hasn't solved it

Zoho Books has GSTR-2B reconciliation. So does Tally. So does ClearTax. So why is Excel still the default?

Three reasons:

How mb does it differently

Three design choices.

1. Reconciliation is in every paid tier, including the cheapest.

The wedge is not the recon engine itself — there's nothing technically secret about hash-keyed matching with tolerances. The wedge is making it the entry-level feature instead of the upsell-tier feature. A CA can hand the cheapest mb plan to every client and reconcile 100 GSTINs without escalating costs.

2. Inline-create from "missing in books".

When the recon view shows a supplier's filed bill that doesn't exist in your books, you click "Create bill". The purchase form opens with the supplier auto-resolved (by GSTIN), the invoice number, date, place-of-supply, amounts, and one default line pre-filled. Save → that row reclassifies as Matched on the next page load.

In Zoho, the equivalent flow is: open a new tab, navigate to Purchases, click New, type out 8 fields, save, come back. Inline- create is what makes the wedge actually save time in practice.

3. Tolerances tuned to what CAs already do.

mb's matching engine ships with sensible defaults derived from talking to CAs:

The matching engine is a pure-Go function — gstr2b.Match(books, portal, tolerances) []MatchResult — with 18 table-driven test cases pinning the exact boundary behaviour. Δ sign matters: positive means books over-claimed (audit risk, rendered red); negative means under-claimed (ITC on the table, rendered amber).

What this looks like

Three clicks. Upload the GSTR-2B JSON. See the 4-bucket diff. Click through the "missing in books" tab and create each bill with one pre-filled form. The half-day of Excel becomes a five-minute task.

That's the wedge. Not "we built recon" — every competitor did. "We made recon the cheap, fast default."

Want to see it live? Request beta access. Want the technical detail? Read the feature page.