GST invoice reconciliation: build it or buy it?

Every month someone in your finance team downloads GSTR-2B, exports the purchase register from Tally, Zoho Books or SAP B1, and starts matching rows in Excel. At 300 invoices a month that is an irritation. At 1,500 invoices across 200 vendors it is a three-day exercise, and the rows that fail to match are usually the ones holding your input tax credit. The squeeze lands hardest on mid-market B2B companies — big enough to have real volume, too small to justify a dedicated tax technology team.

What does GST invoice reconciliation automation actually replace?

It replaces three manual steps: matching your purchase register against GSTR-2B, flagging the mismatches, and chasing vendors for the invoices or corrections behind them. The matching itself is the easy part — a GSTIN-plus-invoice-number join with tolerance for rounding, freight and credit notes. The expensive part is everything around it: normalising vendor names across 200 masters, handling invoices booked in one month and reported by the vendor in another, spotting credit notes the vendor never reported, and keeping a trail of who was asked to fix what and when. Automation that only does the join saves you a day a month. Automation that also owns the follow-up loop is what actually protects ITC before the Section 16(4) deadline closes.

When does building in-house genuinely make sense?

Building is the right call when your invoice formats are stable, your volume is high, and you already have engineers who own your ERP or billing stack. A company processing 5,000-plus purchase invoices a month from a few hundred regular vendors, with a clean vendor master and a team that already writes internal tools, will usually get a better fit from a purpose-built internal matcher than from a vendor's generic product. Building also makes sense when your reconciliation logic is genuinely unusual — multi-GSTIN entities, inter-company flows, project-wise ITC allocation — and no off-the-shelf tool models it without heavy configuration. The honest test: if you cannot name the engineer who will still be maintaining it in eighteen months, you are prototyping, not building.

Where does the build case quietly fall apart?

It falls apart on maintenance and edge cases, not on the first version. Version one takes a competent team four to eight weeks and works beautifully on the invoices you designed it around. Then the formats shift. Vendor PDFs arrive scanned, rotated, or as photographs of a printout. Credit notes and debit notes need their own matching rules. Reverse charge, imports, SEZ supplies and works-contract invoices each bend the logic differently. GSTR-2B files change shape occasionally and portal downloads break without warning. And every invoice PDF you store carries PAN, GSTIN and bank details, so the DPDP Act applies to your little internal tool exactly as much as to a purchased one.

What does a three-year cost comparison actually look like?

It usually lands within 30-40% of each other, which is why the decision should turn on ownership rather than price. Take a company processing 1,200 purchase invoices a month across 180 vendors, with two people spending three days each at month-end:

• Manual effort: about 48 person-hours a month. At a loaded cost of ₹600-800 an hour, that is ₹3.5-4 lakh a year — before the ITC you quietly lose on unmatched invoices.
• Building: six to eight weeks of one engineer's time, roughly ₹2-3 lakh loaded, plus 15-20% of that every year in maintenance and format fixes.
• Buying: typically ₹15-40 per invoice, or ₹20,000-50,000 a month at this volume, so ₹2.5-6 lakh a year depending on the tool and the contract length.

Over three years the totals are close. What differs is who carries the risk when a format breaks in the middle of a filing week.

What is the middle path most mid-market teams actually need?

Most mid-market teams should buy the matching engine and keep the vendor follow-up in-house or lightly automated. The matching engine is close to a commodity — someone has already solved 2B parsing, tolerance rules and audit trails, and the regulatory surface keeps moving under you. The follow-up is where your process is genuinely specific: which vendor contact gets the email, whether a WhatsApp nudge works better, how escalations reach the purchase team, what a mismatch statement should say. Plenty of teams run the matcher on a monthly cycle and then send vendor-wise mismatch statements automatically, which is the sort of work covered under GST billing automation. If your invoices arrive as scanned PDFs, solve document extraction first — bad input makes every downstream match unreliable, no matter how good the engine.

Where to start

Start with one month of data. Export your purchase register and GSTR-2B for the same period, count the rows that do not match, and put a rupee value on the ITC sitting in that gap. If the number is small and the vendor list is short, a tighter spreadsheet process will do for another year. If it is large and the vendor list is long, you have a business case — and the next step is scoping the follow-up loop before you evaluate a single tool. That scoping is the kind of work Maysan Labs does alongside finance teams, treating matching, extraction and vendor follow-up as one process rather than three separate purchases.