How to Verify GST Numbers Directly Inside Tally

The practical way to verify GST numbers in Tally is not to build TDL that calls an API — it is an export, verify, re-import loop: export your ledger masters as XML, check each GSTIN against a verification API outside Tally, then re-import the corrected data. TallyPrime has no live connection to GSTN records, so this three-step loop is what most real deployments actually use.

The TallyPrime reality check

TallyPrime is very good at enforcing structural rules on a GSTIN — 15 characters, correct state code prefix, valid PAN segment, a checksum that matches. What it cannot do is tell you whether that GSTIN was ever actually issued by the GSTN, or whether it has since been cancelled or suspended. A vendor ledger with a perfectly formatted but fake or lapsed GSTIN will sail through Tally's own validation without a warning.

This matters for input tax credit risk: if a vendor's registration is cancelled and you continue booking purchases against their old GSTIN, the ITC on those invoices can be disputed later. Most finance teams that run Tally as their books of record solve this with a periodic external check rather than trying to wire real-time verification into every voucher entry screen.

Step 1: export ledger masters as XML

Tally's own XML export (Gateway of Tally → Display More Reports → List of Accounts, or via ODBC/XML export from Ledger masters) gives you every ledger under Sundry Debtors and Sundry Creditors, including the GSTIN/UIN field where it has been recorded. A trimmed export for a single ledger looks like this:

<ENVELOPE>
  <BODY>
    <DATA>
      <TALLYMESSAGE>
        <LEDGER NAME="Acme Traders" RESERVEDNAME="">
          <PARENT>Sundry Creditors</PARENT>
          <GSTREGISTRATIONTYPE>Regular</GSTREGISTRATIONTYPE>
          <PARTYGSTIN>27AAACR5055K1Z7</PARTYGSTIN>
          <LEDGERSTATE>Maharashtra</LEDGERSTATE>
        </LEDGER>
      </TALLYMESSAGE>
    </DATA>
  </BODY>
</ENVELOPE>

You can pull this in bulk through Tally's HTTP XML interface (if enabled on the Tally server) or by exporting the "List of Ledgers" report to XML from the menu. Either way, the output is a flat set of <LEDGER> blocks you can parse with any XML library.

Step 2: verify the GSTINs

Once you have the GSTIN values extracted, loop over them and call a verification API. A short Python script is the fastest way to do this outside Tally:

import xml.etree.ElementTree as ET
import requests
import time

API_KEY = "YOUR_API_KEY"
ENDPOINT = "https://gstinapi.com/api/get-taxpayer-info/{}"

tree = ET.parse("ledger_export.xml")
results = []

for ledger in tree.iter("LEDGER"):
    name = ledger.get("NAME")
    gstin_el = ledger.find("PARTYGSTIN")
    if gstin_el is None or not gstin_el.text:
        continue

    gstin = gstin_el.text.strip()
    resp = requests.get(
        ENDPOINT.format(gstin),
        headers={"X-API-Key": API_KEY},
        timeout=10,
    )

    if resp.status_code == 200:
        data = resp.json()
        results.append({
            "ledger": name,
            "gstin": gstin,
            "legal_name": data.get("legalName"),
            "status": data.get("status"),
        })
    else:
        results.append({"ledger": name, "gstin": gstin, "status": "LOOKUP_FAILED"})

    time.sleep(0.2)  # be polite to the rate limit

Step 3: re-import the corrected masters

For ledgers where the API confirms the legal name and an Active status, generate an updated XML in Tally's import format and bring it back in through Gateway of Tally → Import Data → Masters. For ledgers that come back Cancelled or Suspended, it is usually better to leave the master untouched and instead write the result to a review report — someone in accounts payable should decide whether to hold future payments to that vendor, not the script.

This is also a good moment to reconcile against your GSTR filing due dates if a vendor's filing history looks behind schedule — a lapsed filer is a much bigger ITC risk than a merely late one.

Why TDL is not the whole answer

It is worth being honest about TDL here rather than promising something it cannot reliably deliver. TDL was built to customise Tally's screens, reports, and vouchers — not as a general application runtime. Outbound HTTP support exists in some TallyPrime releases via specific TDL constructs, but it is inconsistent across versions, undocumented for production use, and most on-premise Tally installs do not have outbound internet access configured for the application at all. Building and maintaining a TDL add-on that calls a REST API directly is realistically a niche, higher-effort path compared to the export/verify/import loop described above, which works against any Tally version that can export and import XML.

If your team already has an in-house TDL developer and a hardened network path out of the Tally server, an in-product call is possible in principle. For most teams, running verification as an external step — triggered from a script, a scheduled job, or a small internal tool — is simpler to build, easier to audit, and does not depend on a specific Tally release.

Automating the loop on a schedule

Once the three steps work manually, wrap them in a scheduled job (cron, a Task Scheduler entry, or a small queue worker) that exports ledgers weekly or monthly, verifies them, and drops a report of mismatches and cancelled-status vendors into a shared folder or a Slack channel. This keeps your Tally ledger book aligned with live GSTIN status without anyone needing to remember to run it by hand. Each successful lookup consumes one credit against your API plan; a monthly sweep of even a few thousand vendor ledgers is inexpensive compared with the ITC exposure it catches.

Frequently asked questions