Tally
Keep Tally. Stop typing into it twice.
Most companies that outgrow Tally operationally still want it for statutory accounting — and they should. The problem is not Tally; it is the person re-keying the same transaction into it every evening.
The short answer
Integrate with Tally through its XML/HTTP interface, which accepts vouchers and masters and returns data over a local port. It is a genuinely workable interface with two hard constraints: Tally must be running with the right company open, and it has no concept of a queue — so the reliability has to live entirely on your side.
Interfaces
How it actually exposes data.
The interfaces, the pitfalls, and how we handle each.
Tally XML over HTTP
The primary route. Tally listens on a local port and accepts XML requests to post vouchers, create masters and export data. Well-documented, stable across versions, and the one most integrations should use.
TDL extensions
Tally's own extension language, for behaviour the standard interface will not do. Powerful and a maintenance liability — anything written here is a second codebase in a language your team probably does not read.
ODBC
Read-only reporting access. Convenient for pulling data out, and unsuitable for anything transactional.
Scheduled file exchange
The pragmatic option for multi-branch setups where each unit runs its own Tally on a machine your platform cannot reach directly.
What goes wrong
The failures that are not in the documentation.
Every one of these has cost somebody a release. They are the reason the design below looks the way it does.
Tally has to be open, and sometimes it is not
The interface exists only while the application is running with the correct company loaded. Somebody closes it, or opens a different company, and posting silently stops. Every robust Tally integration is really a queue plus a health check.
Posting without a queue
There is no server-side buffering. If your platform posts directly and Tally is unavailable, the transaction is simply lost. A durable outbox on your side is not optional.
Master data drift
A ledger renamed in Tally breaks the mapping silently, and the failure surfaces at month-end as unmatched entries. Masters need to be synchronised and reconciled, not mapped once at go-live.
Multi-company and multi-branch assumptions
Groups often run a Tally company per unit. An integration designed against one company needs rework to handle several, so it is worth knowing the real structure before the design, not after.
Method
What we build in front of it.
- 01
Decide what Tally is authoritative for
Usually statutory books. Everything else is authoritative in the platform, and Tally receives a posting. Ambiguity here is what produces two systems that disagree.
- 02
Build a durable outbox
Every posting queued, retried with backoff, and visible when it fails. This is the difference between an integration that runs unattended and one someone checks every morning.
- 03
Synchronise masters both ways
Ledgers, items, cost centres and parties, with a reconciliation report that names drift rather than waiting for month-end to reveal it.
- 04
Give finance a view they trust
A screen showing what posted, what did not, and why. Without it, the accounts team keeps their parallel spreadsheet — and the integration has not actually replaced anything.
Questions
What people ask before starting.
Next step
Need to connect to Tally?
Bring the constraint everyone has been working around. Forty-five minutes with an engineer who has done this before is usually enough to tell you whether it is a week or a quarter.
- No sales deck
- An engineer on the call, not an account manager
- NDA before you share anything