How to Integrate TallyPrime With Your CRM, ERP or Custom App
TallyPrime can take invoices from your CRM or ERP and hand data back, but only if the integration is designed around how Tally actually runs. Here are the methods it supports, and the design decisions that matter more than the transport.
By Shuvam, Founder of KodeBiz · Updated 5 Oct 2026
How to integrate Tally with other software: the short answer
To integrate Tally with other software, you enable TallyPrime's built-in HTTP server and have the other system send it structured requests, in XML or (from TallyPrime 7.0) native JSON, to create ledgers and vouchers or to pull data out. Because TallyPrime is a Windows desktop application, those requests only work while Tally is running with a company loaded and reachable on its port, 9000 by default, so a cloud CRM or ERP usually reaches it through a small connector on the same network.
That is the transport, and it is the easy part. Most Tally integrations that break do so for design reasons: nobody decided which system owns a customer's GSTIN, a retry posted the same invoice twice, or Tally was closed over a weekend and nobody noticed the queue. This guide covers both: the methods TallyPrime supports, then the decisions an IT lead should settle before anything is built.
The integration methods TallyPrime supports
When people ask about a Tally API, they usually mean this HTTP interface. TallyPrime acts as a server on the machine where it is installed: an external application posts a request, and Tally replies with data or with the result of an import. It can also act as a client, sending requests out to other systems. Tally's documentation covers these routes.
The port is set in TallyPrime's client/server configuration (Exchange, then Configure). If another program already uses 9000, Tally's help says to enter a different port and restart TallyPrime. For trying requests before writing any code, TallyPrime Developer includes Tally Connector, which sends an XML or JSON request and shows the response.
- XML over HTTP: the long-standing route. Each request is an XML envelope with a header (Import or Export, and the kind of data) and a body. An import reply reports how many records were created, altered or failed with errors, plus the ID of the last voucher imported.
- JSON over HTTP: native from TallyPrime 7.0, with the request type carried in HTTP headers. Earlier releases could exchange JSON only through custom TDL code that mapped it to Tally's own structure.
- ODBC: lets Excel or a reporting tool run SQL queries against Tally data through a data source named after the port, such as TallyODBC64_9000. Tally's own examples are read queries, so treat ODBC as a reporting route, not a way to post vouchers.
- TDL customisation: Tally Definition Language is Tally's own language for screens, reports and logic. With it, TallyPrime itself can push approved vouchers to an external endpoint, or fetch data from one, instead of waiting to be called.
- File import and export: masters and transactions from XML, from JSON (7.0 onwards) or, since TallyPrime 4.0, from any Excel workbook mapped to Tally fields. Good for migrations and one-off batches, not for a live sync.
Tally integration with a cloud CRM: the desktop problem
Tally's integration prerequisites are short: TallyPrime must be running on a known port, and at least one company must be loaded. Everything else follows from that. If the accountant's PC is switched off at 7 pm, the integration stops at 7 pm. If someone closes Tally to take a backup, requests fail until it is reopened.
A cloud CRM or ERP cannot simply call a PC inside your office, and we would not open TallyPrime's port to the public internet to make that possible. The usual pattern is a small connector, or agent, installed on a machine on the same network as TallyPrime. It makes outbound HTTPS calls to the cloud application, collects the records waiting to go to Tally, posts them locally, and reports each result back. No inbound firewall rule is needed.
There are two alternatives. A TDL customisation can make TallyPrime push vouchers out to your application itself, which suits a design where Tally initiates the sync, but it still needs Tally running. And if your TallyPrime runs on one of Tally's hosted offerings, check what that offering supports first: at the time of writing, Tally's help says syncing with local applications is available for TallyPrime on AWS but not for TallyPrime Cloud Access.
Whichever route you choose, run TallyPrime on an always-on machine, not a laptop that goes home in a bag.
ERP integration with Tally: decide what syncs and who owns it
Tally data splits into masters and vouchers. Masters are the reference records: party ledgers for customers and suppliers, other ledgers, stock items, units, godowns. Vouchers are the transactions that use them: sales invoices, receipts, payments, credit notes, journals. A sync has to post masters before the vouchers that reference them, because a voucher naming a ledger Tally does not have cannot post cleanly.
For each entity, write down which system is the source of truth, which way data flows, and how often. A typical split for an SME looks like the list below, but yours should come from how your teams actually work.
Frequency should follow need, not ambition. An approved invoice may need to reach Tally straight away; an outstanding-balance view for the sales team can refresh hourly. And give every field exactly one owner. Two systems that are both allowed to edit a customer's address is how a two-way sync ends up overwriting itself.
- Customers: created in the CRM when a deal is won, pushed to Tally as a party ledger, with accounts owning the GST details from then on
- Stock items: owned by whichever system manages the item master (often Tally, sometimes the ERP), never both
- Sales invoices: raised in the ERP, posted to Tally as sales vouchers once approved
- Receipts: recorded in Tally against the bank, with outstanding balances read back to the CRM on a schedule
Duplicates, GST and failures: where Tally syncs break
Duplicate prevention comes first. Networks time out, and a connector that retries an invoice it already posted creates a second sales voucher. Give every outgoing record a unique ID from its source system, store the Tally voucher ID returned for it, and check that mapping before any retry. Tally's file import asks what to do with duplicate masters, but a live voucher sync has to prevent duplicates on its own side.
GST fields are where a sync can succeed technically and still be wrong. In TallyPrime, a party ledger carries the registration type, GSTIN/UIN and place of supply, and a stock item carries its HSN/SAC and GST rate. If the CRM creates a customer with a missing GSTIN or the wrong state, the invoice posts and the problem surfaces at return filing. Validate those fields before posting, and agree who owns them.
Failures come in two kinds that need different handling. When Tally is closed or unreachable, queue the record and retry with backoff. When Tally rejects a voucher (the sample error in Tally's own docs is "Voucher totals do not match!"), retrying will not help: route it to a person with the error text and the record attached.
Finally, keep a per-record sync log: last attempt, last success, last error, and the Tally ID. That is what lets someone in accounts answer "is this invoice in Tally yet?" without calling a developer.
Common mistakes in Tally integrations
Most of the problems in existing Tally integrations trace back to a short list. None of them are about XML versus JSON.
- Treating any reply from Tally as success: the created, altered and error counts in the response are what confirm a voucher posted
- Matching parties by name, so "ABC Traders" and "ABC Traders Pvt Ltd" become two ledgers
- Posting vouchers before the ledgers and stock items they reference exist in Tally
- Running the sync from an accountant's laptop that is off on evenings and weekends
- Letting two systems edit the same field and calling it a two-way sync
- Testing against live books instead of a copy of the company
- Writing errors to a log file on the Tally machine that nobody reads
How we approach Tally integrations at KodeBiz
We've moved invoices between Tally and a custom ERP, and TallyPrime is part of the connector library we reuse across integration projects. Each one still starts with a requirement study. We sit with your accounts team and the people who use the other system, look at how Tally is set up (ledger groups, voucher types, numbering), and walk real invoices, credit notes and GST cases through the proposed flow, including the awkward ones.
That becomes a written scope you agree before we build: the field map, the source-of-truth table, direction and frequency for each entity, and what happens when Tally is closed or rejects a record. We then design and build the connector with its retries and per-record sync log, test it against a copy of your company using those same real cases, and train accounts to read the log and clear rejected records before go-live. Support continues after that. Timelines are agreed once the requirement study is done, because the field map is what decides the effort.
Integrating Tally means posting XML or JSON to TallyPrime's HTTP server, which only works while Tally is running and reachable, so cloud systems need a local connector. The transport is the easy part: decide who owns each record, prevent duplicates, validate GST fields, and log every record's sync status.
Frequently asked
What is Tally integration?
Tally integration means connecting TallyPrime to another system, such as a CRM, ERP, online store or custom app, so data moves between them without retyping. Typically the other system creates party ledgers and sales vouchers in Tally and reads back balances or reports. It runs over TallyPrime's HTTP interface in XML or JSON, with ODBC for reporting and TDL for syncs that Tally starts itself.
Does TallyPrime have an API for integration?
Yes, in the form of a built-in HTTP server. When enabled, TallyPrime listens on a port (9000 by default) and accepts XML requests, and from TallyPrime 7.0 native JSON requests, to import masters and vouchers or export data. It is not a hosted cloud API: it lives on the Windows machine running TallyPrime, so that machine has to be on and Tally open with a company loaded.
Can a cloud CRM connect to Tally directly?
Not usually, because TallyPrime runs on a machine inside your network. The safer pattern is a small connector on that network that makes outbound calls to the CRM, picks up pending records, posts them to TallyPrime locally and reports results back. That way you never have to open Tally's port to the internet.
What happens if Tally is closed when the CRM sends an invoice?
With a well-designed integration, nothing is lost. The connector queues the invoice, retries with backoff until TallyPrime is reachable again, and the sync log shows it as pending rather than posted. Without a queue, the request simply fails and the invoice is missing from Tally until someone spots the mismatch, often at month end.