Tally Integration for Custom Software, Done Right

Nearly every system we build for an Indian business ends in the same place: the accounts are in Tally, and the accountant is not moving. That is usually the right call. Tally is what the accountant knows, what the auditor expects, and where the returns are prepared. The job of a custom system is to feed it cleanly, not to replace it.

Whether the new system saves the accountant time or creates work for them is decided almost entirely by how that connection is designed.

How data gets into Tally

1. XML over HTTPTallyPrime can run as a server on the machine where it is installed - by default on port 9000 - and accept XML requests that create masters and vouchers or export reports. This is the most direct route and the one most integrations use. It needs Tally running with the company open.
2. File importVouchers and masters prepared as XML files and imported by the accountant. Slower, but it keeps a person in the loop, and it works where the Tally machine cannot be reached at all.
3. ODBCTally also exposes its data through ODBC, which is convenient for reading reports into another system. It is a route for reading, not for writing entries.
4. TDL customisationTally's own definition language can add fields and reports inside Tally. It is useful, but it is code that has to be maintained across Tally releases, so we keep it to the minimum the job needs.

When Tally is on an office desktop

Tally usually runs on a computer in the office, and a web application runs on a server somewhere else. The two cannot simply call each other, and they should not be made to. The reliable pattern is a small connector on the Tally machine that asks the web application for pending entries, posts them into Tally locally, and reports back what happened. The connection is outbound only, so nothing in the office is exposed.

Masters before vouchers

A voucher refers to ledgers, stock items, godowns and cost centres by name. If a name does not match a Tally master exactly, the import fails, or worse, lands against the wrong master. So the integration has to own a mapping: every party, item and ledger in the new system linked to its master in Tally.

New masters need a rule too. Either the integration creates them under agreed conventions, or it holds the entry and asks the accountant. What it must not do is let spelling drift - a trailing full stop, a changed abbreviation - quietly create a second ledger for the same party.

Never post twice

The most common integration failure is the duplicate voucher. Tally accepts an entry, the network drops before the reply arrives, and the system sends it again. Both copies are in the books, and the totals are wrong in a way that takes an afternoon to find.

1. A stable identity for every entryEach voucher carries an identifier from the source system, and the integration checks for it before creating anything. Sending the same entry twice then updates or skips it instead of adding a second one.
2. A posting logEvery attempt recorded with what was sent and what Tally replied, so a missing or doubled entry can be traced in minutes rather than reconstructed.
3. ReconciliationA regular comparison of totals by day and by ledger between the two systems, which catches the cases nobody noticed at the time.
4. Careful retriesConnection failures are retried automatically. Anything Tally rejected goes to a person with the reason, rather than being retried until it lands somewhere wrong.

Detail or summary

Not every transaction belongs in Tally as its own voucher. The choice is per transaction type, and it is worth making with the accountant rather than for them.

• Sales invoices usually go in one by one, because where returns are prepared from Tally the invoice-level detail has to be there.
• Payroll usually goes in as one reviewed journal a month, split by cost centre, rather than a voucher per employee.
• High-volume counter receipts often go in as a daily summary by payment mode, with the detail kept in the source system.
• Stock movements depend on whether stock is valued in Tally at all. If the new system owns inventory, Tally often needs only the accounting effect.

The GST details that break returns

• GSTIN, place of supply and HSN or SAC carried on every line, so each voucher is complete for returns without editing in Tally.
• Tax ledgers mapped by rate and type, CGST and SGST against IGST, rather than one tax ledger for everything.
• Rounding done the same way in both systems. Otherwise totals disagree by a rupee, and after that nobody trusts either.
• Credit notes linked to the invoice they correct, not posted as free-standing negative entries.
• A voucher dated into a closed period refused by the integration, rather than quietly posted into a month the accountant has finished.

Zoho Books and other ledgers

Zoho Books has a documented REST API, which removes the office-machine problem entirely. Everything else in this article still applies: the mapping of masters, a stable identity for each entry, the posting log and the reconciliation. They are what make an integration with any ledger trustworthy, and they are the parts most often left out.