Tally API integration for your website, CRM and ERP

Many Indian businesses keep their accounts in Tally and run everything else elsewhere: a website taking orders, a CRM raising invoices, an ERP handling purchasing and stock. Without an integration, someone types those entries into Tally again. An integration lets your software send them to Tally directly, and read back what it needs, such as balances or stock.

It suits businesses whose transactions already live in a system of their own: a custom ERP, a GST billing system, an inventory tool or an online store.

It is not always worth building. If your sales run on a popular platform, ready-made Tally integration software may already connect it, and buying a connector is cheaper than a custom build. At a handful of invoices a week, a periodic file import may be enough. And if what you need is a new screen or report inside Tally itself, that is TDL work, which a Tally partner does best; I work on the integration side and can work alongside them.

TallyPrime, and Tally.ERP 9 before it, can act as a server on the machine where it runs, on a port you set in its configuration (commonly 9000). Other software sends XML requests over HTTP to export masters, vouchers or reports, or to import data that creates or alters ledgers, stock items and vouchers. Newer TallyPrime releases also accept JSON, and ODBC suits reading data into reports. Tally has to be running with the right company loaded. This is what people usually mean by Tally Prime API integration.

The catch is where Tally lives: usually on an office PC, while your web application runs on a cloud server that cannot reach it. That port should never be opened to the internet, because it was designed for a trusted network. So the real question is how the two sides meet:

• A connector or middleware on the Tally side. A small program on the Tally machine fetches pending entries from your web app over HTTPS, posts them to Tally locally and reports back. Nothing is exposed. On a previous project I worked with exactly this kind of setup: a middleware application watched the requests arriving on a set port and passed each one on to the address configured in it. I did not build that middleware, but I know how the pieces fit and where they fail.
• A secure tunnel or VPN between your server and the Tally machine.
• Same network. An application on a server in the same office can talk to Tally directly.
• Hosted Tally. If Tally runs on a remote server, the connector runs there.

Masters are the lists vouchers depend on: party ledgers, sales and purchase ledgers, the CGST, SGST and IGST ledgers, stock items with units and godowns. Vouchers are the transactions: sales, purchases, receipts, payments, journals, credit and debit notes. A voucher naming a ledger Tally does not have will fail, so mapping masters comes first.

Mapping is where most of the thinking goes. Each customer in your app must point to exactly one Tally ledger, and each tax rate to the right sales and GST ledgers. Existing Tally data often has duplicates, such as ABC Traders and A.B.C. Traders, and we settle those before the first sync.

Then we agree, per type of data, which system is the source of record:

• Tally usually owns accounts: the chart of ledgers, opening balances, adjustments and anything your accountant posts by hand.
• Your app usually owns operations: orders, quotations, dispatch and the invoices it raises, which are pushed to Tally one way.
• Two-way sync is useful for reading payments, outstanding bills or stock back from Tally into your app.
• Editing the same record in both places is where conflicts come from, so I design it out: each record has one owner, and the other system only receives it.

A voucher posted twice is worse than one not posted at all, because it quietly inflates sales or stock. So nothing goes straight from a button click to Tally. Each entry is written to a staging table with a status (pending, posted, failed or held), and a queued job sends it. The job checks whether that source record already reached Tally, then stores Tally's response and a reference tying the voucher to your record. Running the sync again only sends what is still pending.

Failures are handled by cause. If Tally is closed or the connection drops, the job retries later on its own. If Tally rejects the entry, say for a missing ledger, retrying will not help, so the entry is held with the exact error for someone to fix and resend. A daily reconciliation compares counts and totals in your app against Tally, so a gap shows up in a report, not at year end.

I built the same pattern, staging tables, entity mapping, configurable behaviour and a log of every call, for a sync with a separate accounting system on the AI invoice capture project. Amounts are kept as fixed decimals throughout, so totals in your app, in the PDF and in Tally match to the paisa.

Tally integration with website orders is a common first project: each paid order becomes a sales voucher, against the customer's ledger or a single online-sales ledger if your accountant prefers, and stock is read back from Tally on a schedule. The order number travels with the voucher, so any entry can be traced back to its order.

When a client asks for Tally API integration for e invoice generation, the first question is where the invoice is raised. If your own software raises it, the IRN and QR code can come from the government's invoice registration portal through a GST Suvidha Provider's API, and the voucher then goes to Tally with the invoice reference. If invoices are raised in Tally, recent TallyPrime releases have e-invoicing built in, and the integration should leave that step to Tally. Either way, generate each e-invoice once, in one place. Purchase bills can start upstream, with AI invoice processing reading supplier invoices for a person to confirm.

I do not publish prices, because two integrations that sound alike can differ by weeks of work. After a call and a look at both systems, I send a fixed quote. The main drivers are:

• Where Tally runs and how your app will reach it: same network, connector, tunnel or hosted copy
• How many voucher types and masters are involved, and whether inventory is tracked in Tally
• One-way posting, or two-way with balances, payments or stock read back
• The state of your existing ledgers: duplicates and inconsistent names must be cleaned up first
• Several companies or branches, and whether they run on one Tally or several
• Whether your own software needs building or changing, through API development or a new module