The three honest ways AI actually reads Tally
Tally Solutions exposes its data through three official channels and any reputable AI analytics layer will use one of them. None of these involve scraping a UI or reverse-engineering an undocumented surface.
- Built-in ODBC server. Enabled from F1 (Help) and listening on a local port. Schema-aware, fastest response times, the default channel KolossusAI uses for live querying.
- HTTP-XML interface. A documented request-response API where you POST a well-formed XML envelope describing the report you want and Tally returns XML back. We fall back to this for the handful of report shapes ODBC does not expose cleanly.
- On-machine agent. A small agent installed on the Tally machine itself which speaks one of the first two interfaces inside the network and forwards results out. Used when Tally runs on a desktop not directly reachable from the analytics layer, the most common deployment shape in Indian SMBs.
What matters about all three: they are official, documented, and read-only when used with default permissions. Nothing is being exported to a vendor cloud unless you explicitly choose a hosted deployment.
What the AI can actually see inside Tally
If a finance person can see a number on a Tally screen, the AI can answer a question about it. That covers the full transactional ledger and every standard MIS surface.
- Every voucher type. Sales, purchase, payment, receipt, journal, contra, credit note, debit note, stock journal, manufacturing journal - with line items, narration, party allocations, cost centre allocations, and bill references.
- All masters. Ledger masters with group, opening balance, GSTIN, address, contact. Stock items with unit, godown allocation, batch and expiry where configured.
- Full GST metadata. GSTIN of party, place of supply, HSN/SAC code, tax rate, IGST/CGST/SGST/cess split, reverse charge flag, and the GSTR-1 / GSTR-3B section the voucher will fall into.
- The standard MIS pack. Outstanding (bill-by-bill matching), ageing buckets, cost centre P&L, godown-wise stock, manufacturing variance - all queryable.
- Multi-company consolidation. Works as long as the companies are loaded in the same Tally instance, which is how most multi-GSTIN Indian businesses already run.
What it cannot see (and why that is fine)
Anything outside Tally is, well, outside Tally. The boundary is honest and worth understanding upfront.
- Anything not stored in Tally. Hand-drawn reconciliation notes, scanned purchase invoices in a Drive folder, the Excel register your sales team maintains separately, supplier quotations on email - none of these are inside Tally and therefore not in the AI's answer unless connected separately.
- UI-only TDL computations. TDLs that store data in standard Tally fields (most of them) are visible. TDLs that add new fields show up as custom columns. TDLs that only run UI-side without storing the result are invisible because there is no stored value to read. In practice this rarely matters because the underlying inputs are always stored.
- Write operations by default. Default permissions are read-only at every level. Write-back can be enabled per user (for instance, marking vendor invoices paid) and every write is logged, attributed, and reversible. Most customers leave write-back off for the first three months.
Security and audit posture
The default deployment is read-only with per-table and per-column permissions. Sensitive ledgers (director loans, payroll detail, related-party transactions) can be hidden from the AI entirely - the connector simply never sees those tables. Per-user permissions mean your sales head sees what they would see in Tally, and your finance head sees what they would see in Tally, no more.
Every query is logged: who asked, what they asked, the exact SQL or XML that ran against Tally, the row IDs returned, and the response shown to the user. This audit trail is what your statutory auditor wants when they ask how a number was computed. For regulated industries we deploy fully on-premise so Tally data never leaves your servers - see AI for Tally Prime users for the deployment shapes.
On the network side the connector lives inside your boundary. If you want zero outbound traffic from the Tally machine, the on-premise deployment runs the entire AI layer on a server inside your network and the only external traffic is your users' browser sessions to a private URL.
Multi-company and multi-GSTIN consolidation
Most Indian mid-market businesses run more than one Tally company. The AI layer reads all of them in the same query, regardless of whether you have a single legal entity or a multi-plant multi-GSTIN footprint.
| Single-company setup | Multi-company setup | |
|---|---|---|
| Typical pattern | One legal entity, one GSTIN, one Tally company | Multiple legal entities or GSTINs, one company each |
| Connector setup | Single ODBC channel | One channel per company, same Tally instance |
| Cross-company queries | Not applicable | Single query unions all companies automatically |
| Mixed Prime + ERP 9 | Either edition works | Phased migration handled in same query |
What changes for the finance team day to day
The first thing that goes away is the Friday evening export ritual. The owner stops asking the team for ad-hoc cuts of the same data and starts typing the question themselves. This sounds small but it removes roughly four to eight hours per week of "pull this for me" work from senior accountants who have better things to do.
The second change is in question quality. When asking is cheap, owners ask better questions. Instead of one weekly MIS pack with twenty fixed charts, you get a continuous conversation against live data. "Which Gujarat customers slipped from 30-day to 60-day this month and what is the common pattern" is a question nobody asks today because producing the answer takes three hours.
The third change is in audit and compliance posture. Every number the owner sees has a one-click drill back to the underlying Tally vouchers. Statutory audit conversations get shorter because the trail is already cleaner than the spreadsheet pipeline that used to feed the same MIS.
Common buyer concerns and our honest answers
- Is this secure for our financial data? Yes when deployed correctly. Read-only by default, per-column permissions, full audit log, deployment options ranging from managed cloud to fully on-premise. The honest caveat: any analytics layer is only as secure as the deployment shape you choose, so if your data sensitivity is high, choose on-premise and the question is settled.
- Will it slow down our Tally machine? ODBC reads are lightweight. Tally is single-threaded so a long-running query can momentarily slow a user typing a voucher, but in practice we throttle and queue queries so this is rare. We have customers running KolossusAI against Tally machines that book 500+ vouchers a day with no perceivable user-side slowdown.
- What if Tally itself crashes during a query? The query fails cleanly, the user sees an error, no data corruption. Tally's ODBC implementation is mature - it has been in the field since the ERP 9 days. We have not seen a Tally crash attributable to ODBC reads in production.