Connecting Custom Software to TallyPrime

Most Indian businesses we build software for keep their books in Tally, and they're right to. Their accountant knows it, their CA files from it, and replacing it would be a bigger project than whatever they actually asked for. So the question is how to make a dealer portal, an order system or a field sales app talk to Tally without someone retyping entries.

A thread on r/n8n this year had a familiar problem: "Tally Prime API posting duplicate invoices (3–4 entries per JSON)". This post is about avoiding that.

Keep Tally as the books

The pattern that works is simple to say. Your custom system owns the operations: enquiries, orders, dispatch, schemes, visits. Tally owns the accounts. Data moves one way for each kind of record, and both sides agree on which system created it. Most integration trouble starts when both systems can create the same thing.

For BACF, a fertiliser and agro-chemicals business, we built an internal platform covering inventory and order workflows, attendance and payroll, field-sales dashboards, incentives and a dealer loyalty programme. Every one of those touches money at some point, which is why the boundary with accounts has to be decided early.

The ways in

Tally's own documentation describes the options:

1. XML over HTTP. TallyPrime can act as a server, client or both, set under Exchange > Data Synchronization. It listens on a port you choose (9000 is the usual example), at least one company must be loaded, and requests are XML in UTF-8, UTF-16 or ASCII. Your software sends a request and gets a response with what was created or what went wrong.
2. File import. TallyPrime imports masters and transactions from XML, and since Release 7.0 from JSON too. Useful for batch jobs and as a fallback.
3. TDL customisations inside Tally that push or pull data. Powerful, but they live inside each Tally installation, so they're harder to version and support.

For most custom systems, we use XML over HTTP through a small bridge service, with file import as the manual fallback.

The bridge pattern

Don't let your web app call Tally directly. Put a bridge in between:

• The web app writes each accounting event (invoice, receipt, credit note) to a queue with a status.
• A bridge service on the same network as Tally picks up pending events, posts them, and records Tally's response.
• Failed events stay in the queue with the error, and someone can see and fix them on a screen.

Tally is a desktop application. It gets closed for the night, restarted for an update, or has a different company loaded. With a queue, those moments mean a delay, not lost or duplicated data.

Why duplicates happen

Duplicates nearly always come from retries. The request reaches Tally and the voucher is created, but the response is lost or times out, so the sender tries again. Or two workers pick up the same event. The fixes:

• Give every event a unique ID from your system and store it on the voucher, in the voucher number or a reference field.
• Before retrying, check whether a voucher with that ID already exists.
• Make one worker responsible for each company, so events aren't posted in parallel.
• Read Tally's response properly. It reports how many records were created, altered or failed, and an HTTP success alone doesn't mean the voucher went in.

Masters first

A voucher fails if it refers to a ledger, stock item or unit that doesn't exist in Tally. Decide which masters your software may create (often party ledgers for new dealers) and which only the accountant creates (GST ledgers, stock groups). Sync masters before transactions, and match names exactly.

Hosting

Tally has to be running for the bridge to post. Options are a dedicated machine in the office, a Tally on cloud setup, or a server your IT team manages. Whichever you choose, someone should get an alert when the queue stops moving.

If you're still deciding whether to keep Tally at all, our ERP guide for manufacturers compares the options, and moving from Excel to an operating layer covers what to build first.