Integrating GST Verification into Your ERP Workflow

GST verification belongs inside your ERP's master-data workflow, not as a one-off spreadsheet check before go-live. The practical pattern is the same across SAP, Oracle, NetSuite, Zoho and Odoo: call a GSTIN verification API at record creation, at every change request, and on a recurring schedule, then store the result against the vendor or customer record as evidence.

Where verification belongs in the master-data lifecycle

Most ERP implementations treat GSTIN verification as a one-time gate: someone checks the number when the vendor or customer master record is first created, and never again. That misses two of the three moments where a bad GSTIN actually causes damage.

• Creation. Before a new vendor or customer master record is released for transacting, confirm the GSTIN is well-formed, registered, and Active. This is the check most ERP rollouts already have, usually as a manual step or a basic format regex.
• Change request. Any time a workflow updates the GSTIN field, the legal name, or the registered address on an existing master record, re-run the check. Vendor master change requests are a known fraud vector — a compromised approval workflow that quietly swaps a bank account or GSTIN is exactly what a real-time check catches before the next payment run.
• Periodic revalidation. A GSTIN that was Active at onboarding can be cancelled or suspended months later without anyone in your organisation finding out, because nothing forces the vendor to tell you. A scheduled batch job — nightly, weekly or monthly depending on your risk appetite — that re-checks the active vendor master closes this gap.

Building this as three separate manual processes is where most implementations go wrong. It should be one reusable check, called from three different triggers in the workflow engine your ERP already has (SAP workflow, Oracle approval hierarchies, NetSuite workflow manager, or a scheduled script in Zoho or Odoo).

The "one GSTIN per state per legal entity" modelling problem

A single legal entity, identified by one PAN, registers a separate GSTIN for every state or union territory it has a place of business in. A vendor with warehouses in Maharashtra, Karnataka and Delhi legitimately holds three different GSTINs, all under the same legal name. This breaks the assumption baked into a lot of legacy vendor masters: one vendor record, one tax ID field.

The fix is structural, not procedural: model GSTIN as a child table linked to the vendor or customer header, with one row per state of operation, each carrying its own verification status and last-checked date. A purchase order or sales order should reference the specific GSTIN tied to the ship-from or ship-to state, not a single default value on the vendor header. Getting this wrong is a common root cause of place-of-supply errors downstream in invoicing — see our companion piece on adding GST verification to invoicing software for how the same state-code logic plays out on the billing side.

Storing verification evidence for audit

A pass/fail flag on the vendor record answers "is this vendor's GSTIN valid right now" but not "was it valid when we processed that payment in March." Internal audit, statutory audit, and your own accounts payable team will all eventually ask the second question, usually after the fact.

The reliable pattern is an append-only verification log, separate from the master record itself:

Retaining the full API response (or at least the fields above) as JSON alongside the transactional record costs very little storage and is the single most useful thing you can hand an auditor who asks "prove this vendor was compliant when we paid them."

A generic integration architecture that works for any ERP

Strip away the ERP-specific plumbing and the architecture is the same five steps everywhere: capture the GSTIN, queue a verification job, call the API, write the result back to the master record, and log the evidence. A minimal version looks like this:

1. Master data event fires (create / change request / scheduled batch)
2. Middleware picks up the GSTIN + record ID, calls:
   GET https://gstinapi.com/api/get-taxpayer-info/{gstin}
   Header: X-API-Key: YOUR_API_KEY
3. Response parsed for: status, legal_name, registration_date
4. Write back to ERP:
   - vendor/customer master: verification_status, last_checked_at
   - append-only log table: full response + trigger + timestamp
5. If status != Active, route to an exception queue for manual review
   before the record can be used on a new transaction

Step 2 is the only part that differs meaningfully between systems, and it is purely a connectivity question, not a business-logic one:

• SAP typically calls out via an RFC-enabled function module wrapping an HTTP client, or through middleware like SAP PI/PO or Integration Suite. We cover this in more depth in integrating a GST verification API with SAP.
• Oracle (Fusion or E-Business Suite) generally routes through Oracle Integration Cloud or a custom PL/SQL wrapper calling out via UTL_HTTP or a Java concurrent program.
• NetSuite can call the API directly from a SuiteScript user event or scheduled script, since SuiteScript supports outbound HTTPS natively.
• Zoho (Books/Creator) can use Deluge's built-in invokeurl to call the endpoint directly from a workflow rule with no separate middleware.
• Odoo can wrap the call in a small Python method on the partner model, triggered from a scheduled action or an onchange handler.

None of these need the vendor to build anything custom on the API side — the endpoint returns the same JSON regardless of the caller, so the integration effort is entirely on your side, in whichever language your middleware layer runs.

SAP, Oracle, NetSuite, Zoho or Odoo — does the ERP actually matter?

For the verification logic itself, no. The decision points — when to check, how to model multi-state GSTINs, what to log — are identical regardless of platform. What differs is connectivity effort and where the middleware lives.

For a deep dive on the SAP case specifically — including the RFC-vs-OData decision and vendor master field mapping — see how to integrate GST verification with SAP systems rather than treating this post as SAP documentation.

Who owns the check: procurement, finance, or IT

In practice, the check crosses three teams and works best when none of them owns it exclusively. Procurement cares about it at vendor onboarding, finance cares about it before payment runs, and IT owns the actual integration and the audit log. Assigning a single business owner for the "GSTIN verification policy" — how often to re-check, what counts as an exception, who reviews a failed check — prevents the common failure mode where the integration works technically but nobody acts on a Cancelled status it surfaces.

This is also where the exception queue from the architecture above earns its keep: a record flagged "GSTIN not Active" should block further transactions until a named role signs off, not silently fail or silently pass through.

Frequently asked questions