GST Return Filing and Reconciliation APIs Explained

"GST compliance API" is sold as one product and is really three. Filing submits returns on a taxpayer's behalf. Reconciliation matches your purchase records against GSTR-2B to protect input tax credit. Verification reads the public taxpayer record to tell you whether a counterparty is real, active and filing.

They have different licensing requirements, different price points by roughly two orders of magnitude, and different consequences when they fail. A mid-sized business evaluating "a GST compliance API" is usually being quoted for all three when it needs to buy them separately — and, importantly, in a particular order.

The three layers of a GST compliance stack

What a filing API actually does

A filing API takes structured invoice and summary data from your system and submits it to GST systems as a return, handling authentication, schema validation, the submit-and-file two-step and the acknowledgement that comes back. Because it acts on a taxpayer's behalf, it sits behind GSP-grade access and that taxpayer's authorisation.

What makes filing hard is rarely the transmission. It is everything upstream: your data has to be complete and correctly classified before it can be filed at all. HSN or SAC per line, place of supply derived correctly, credit notes linked to their originals, amendments handled as amendments rather than new documents. Filing surfaces every data quality problem you have, at a deadline, which is why teams find it painful. The returns themselves are explained in the GSTR-1 guide and the GSTR-3B guide, with deadlines in GST return due dates.

What a reconciliation API actually does

Reconciliation compares your purchase records against GSTR-2B — the auto-drafted statement of input tax credit available to you for a period, assembled from what your suppliers reported. The output is a set of buckets:

• Matched. Your invoice, their reported invoice, same values. No action.
• In 2B but not in your books. Usually an unbooked invoice or a document sent to the wrong place.
• In your books but not in 2B. The expensive one — your supplier has not reported it, and your credit on it is at risk until they do.
• Matched with differences. Amount, tax rate or invoice-number mismatches, usually requiring a tolerance rule and then a human.
• Duplicates. Almost always your side.

Two properties of GSTR-2B drive the design. It is static once generated for a period — it does not update as suppliers file late — so a missing invoice does not silently resolve itself inside that statement. And the Invoice Management System now sits in front of it, letting you accept, reject or keep documents pending before they flow into your 2B, which changes when in the month the work happens. Both are covered in GSTR-2B and the Invoice Management System.

Where GSTIN verification fits — and why it comes first

Reconciliation is a detection layer for problems that already happened. Verification is a prevention layer for a meaningful share of the same problems. Consider what actually produces the expensive reconciliation buckets:

Every row is visible before the invoice is booked, for well under a rupee. That is the argument for putting the cheapest layer first: it reduces the volume flowing into the expensive layers. Screening designs are in vendor onboarding and daily vendor monitoring.

Choosing for a mid-sized business

The questions that actually separate options, in the order worth asking them:

1. How many GSTINs do you file for? Multi-state registrations multiply everything, and per-GSTIN pricing is the norm. A business with twelve registrations is a very different customer from one with two.
2. What is the real integration point? If your data lives in SAP, Tally or an ERP, the connector quality matters more than the feature list — see ERP integration, SAP and Tally.
3. Who fixes an exception? An engine that produces 4,000 mismatches and no ownership model has moved the work rather than reduced it.
4. Where does counterparty screening sit? Some suites include it at a price that only makes sense at their volumes. Priced separately, it is usually a rounding error — compare against per-lookup pricing.
5. What happens at the deadline? Ask specifically how the platform behaves on the 20th, when the upstream systems are at their busiest and so is every other customer.

The order to build in

Businesses that sequence this well tend to go in the same order, and it is not the order vendors pitch.

1. Verification first. Cheapest, no licensing, deployable in a day, and it improves the input data for everything after it. Screen the vendor master once, then monitor.
2. Reconciliation second. Now running against a cleaner counterparty base, so the exception volume is lower and the exceptions that remain are genuine.
3. Filing automation last. The highest-stakes layer, and the one that depends most on the data discipline the first two steps establish.

Doing it in reverse — automating filing on top of a vendor master nobody has screened — is how businesses end up with an expensive platform producing thousands of exceptions a month that trace back to data problems a ₹0.50 lookup would have caught at onboarding.

Frequently asked questions