
Let's be honest about how GST credit reconciliation actually works at most FMCG companies: someone on the finance team downloads GSTR-2A/2B data, pulls a purchase register from Tally or Zoho, and matches invoices by supplier and amount. If the numbers are close enough, the file gets marked as reconciled, and the team moves on to the next return period.
At the invoice level, this works. At the SKU level, it falls apart — and that's where the real money is hiding.
Party-level reconciliation answers one question: did this supplier file the invoices I'm claiming ITC against? That's necessary, but it's not sufficient. The problems that actually cost FMCG brands money live one layer deeper.
Rate mismatches inside valid invoices. A single invoice might cover 30 SKUs across 5%, 12%, and 18% slabs. If even one SKU is classified at the wrong rate, the invoice total can still look correct while the ITC on that line item is wrong. Across thousands of invoices per month, this adds up.
HSN code inconsistencies. Your system says a product is 2106 90 99. Your distributor filed it as 2106 90 20. The invoice matches, the amount matches, but the classification doesn't — and that's what an assessing officer will look at.
Credit notes that don't net off cleanly. Returns and credit notes need to reverse ITC against specific SKUs at the correct rate. Party-level reconciliation often treats them as lump-sum adjustments, leaving phantom credits or excess reversals in your books.
The key point: Party-level reconciliation catches missing invoices. SKU-level catches rate mismatches, HSN inconsistencies, and incorrect ITC that party-level checks miss entirely.
Priya heads finance at a mid-sized packaged foods company in Ahmedabad — roughly 180 distributors, 400+ SKUs across snacks, beverages, and ready-to-eat categories spanning three GST rate slabs.
Every quarter, her team reconciled at the party level. Totals matched within tolerance, and the file was closed. But when they ran their first SKU-level reconciliation using an AI tool connected to their Tally data, the results were uncomfortable.
Eighteen SKUs in the 12% slab had been filed by distributors at 18% — and the company had been claiming ITC at the higher rate. On the other side, a set of newer beverage SKUs classified at 5% had been filed by several distributors at 12%, meaning the company was under-claiming ITC on those products. Net exposure across one quarter: ₹18.4 lakh.
The invoice totals had been matching all along. The party-level reconciliation never flagged it because the differences offset each other at the aggregate level. It took SKU-level matching to isolate where the overages and shortfalls actually sat.
Priya's team spent two days cleaning up the mismatch — reclassifying the affected line items, filing amendments, and sending corrected HSN details to the distributors involved. Without the SKU-level reconciliation, the exposure would have continued compounding quietly every quarter.
Vikram runs finance operations for a personal care brand in Pune — 90 distributors, mostly in Maharashtra and Karnataka. His recurring headache was credit notes. Distributors would raise return claims, his team would issue credit notes, and the GST reversals would go through — but something always felt slightly off during quarterly reviews.
When his team switched to AI-powered reconciliation at the SKU level, the system flagged a pattern: one distributor in Belgaum was consistently claiming returns on a specific set of face wash SKUs, but the quantities on the credit notes didn't match the original billed quantities for those products in that period. The distributor had been raising return claims that mixed SKUs from different invoices — some from the current quarter, some from two quarters prior — and the lump-sum credit notes his team had been issuing didn't break it down cleanly enough for proper GST reversal.
The result was roughly ₹3.2 lakh in ITC that should have been reversed but wasn't spread across four months. Not fraud — just a sloppy process on both sides, invisible until someone looked at the SKU-level detail.
More importantly, the same pattern was present (at smaller amounts) across six other distributors. Once flagged, Vikram's team tightened the credit note process to require SKU-level breakdowns on all return claims — a policy change that came directly from what the reconciliation surfaced.
Volume. A mid-sized FMCG brand processes 10,000–50,000 invoice line items per month. Each needs matching by SKU, HSN, rate, and taxable value — not just invoice number and amount.
Data inconsistencies. Your Tally data records a product one way. The distributor's system uses a different code, a truncated name, or a slightly different HSN. These aren't errors — they're normal variations that break exact-match logic.
Timing gaps. Invoices raised in one month appear in GSTR-2A/2B in the next. Credit notes complicate the timeline further.
Scattered data. Multi-state brands have data across GSTINs, Tally or Zoho instances, and return periods. Consolidation is a challenge before reconciliation even starts. (Related: How AI is transforming distributor margin analysis for FMCG brands)
In short: The data exists — in Tally, Zoho, and the GST portal. It's the volume, format inconsistencies, and fragmentation that make manual SKU-level reconciliation impractical.
An AI reconciliation tool connects directly to your accounting system and pulls purchase and sales data at the line-item level, while ingesting GSTR-2A/2B from the portal. Connecting Tally takes minutes — no migration, no IT project. (Related: How to connect Tally data to Fire AI in 5 minutes)
Instead of exact-match logic, AI uses fuzzy matching to handle abbreviated names, transposed HSN digits, rounding differences, and timing mismatches. Clean matches are auto-reconciled. Exceptions get flagged with a reason code — not dumped into a generic "mismatched" bucket.
AI sorts mismatches by type and financial impact:
Instead of monthly fire drills, AI reconciles continuously. When a previously missing invoice appears in the next GSTR-2A/2B cycle, the system auto-resolves it without anyone rerunning the full process.
How it works: Connect Tally or Zoho → AI pulls line-item detail → matches against GSTR-2A/2B at SKU level → categorises mismatches by risk → stays current as new data arrives.
SKU-level GST reconciliation naturally surfaces discrepancies between primary billing (what you invoiced) and secondary sales (what actually sold through). Patterns emerge that are invisible at the aggregate level: a distributor consistently returning specific SKUs, mismatches between billed and GST-reported quantities that could signal stock diversion, and credit notes that don't align with actual return volumes. (Related: Channel deduction reconciliation for FMCG brands)
For brands tracking distributor profitability, this feeds directly into margin analysis. (Related: Distributor margin analysis: an AI-powered approach)
Why it matters: SKU-level reconciliation creates a data foundation that goes beyond compliance — revealing billing vs. secondary sales gaps and feeding into distributor profitability analysis.
Native Tally and Zoho integration — direct data pull, not CSV uploads.
SKU-level granularity — line-item matching including HSN and rate slab validation.
Intelligent fuzzy matching — handles naming variations, timing differences, and rounding tolerances.
Exception workflows — categorisation by type and impact, with resolution tracking.
Multi-GSTIN support — consolidated view across state registrations.
Connect your Tally or Zoho Books data, ingest your latest GSTR-2A/2B, and run a reconciliation at the SKU level. Most brands see value in the first run — mismatches that sat undetected for months surface within hours.
From there, continuous reconciliation means you're always audit-ready instead of scrambling every return period.
Ready to see what your SKU-level GST reconciliation looks like? Connect your Tally data to Fire AI → here
The scenarios described above are based on real reconciliation patterns observed across FMCG companies. Names, locations, and specific figures have been changed to protect confidentiality.
Posted By:

Ishita Shah
Content Editor, FireAI
10+ years of leading Product Management, New Ventures and Project roles at Delhivery, Zomato, and eInfo Solutions. Notion Affiliate and Member of Insurjo Cohort.