Tally (TallyPrime) Integration Research

Date: 2026-05-14 Product: TallyPrime / Tally.ERP 9 (tallysolutions.com) — Tally Solutions Pvt. Ltd., Bangalore, India Current version: TallyPrime Release 6.0 (2025) — also TallyPrime Edit Log 6.0 Purpose: Evaluate whether Tally — the dominant SMB accounting/ERP software in India — has API capabilities that would let Orcha push processed AP invoices, sync reference data, and read back document status, before committing to integration work.

Important Context: What Tally Actually Is

Tally is on-premise desktop accounting software, not a cloud SaaS with a hosted API. This single fact dominates every part of this assessment and makes Tally structurally different from every cloud vendor Orcha has researched so far (Pleo, Qonto, Moss, Payhawk, Spendesk, etc.).

There is a "TallyPrime on Cloud" offering, but it is not a cloud API — it is the same desktop application running on a hosted Windows VM (Oracle Cloud Infrastructure, or AWS/Azure via partners), accessed over RDP. It does not change the integration model; it just moves the localhost.

Disambiguation — two unrelated products are both called "Tally":

• Tally Solutions / TallyPrime (tallysolutions.com, help.tallysolutions.com) — the Indian accounting software. This is what this document is about.
• Tally (tally.so, developers.tally.so) — a completely unrelated form-builder SaaS. It does have a modern REST API, OAuth, and Zapier/Make connectors. Every Zapier / Make / Workato / Pipedream "Tally" connector, and the developers.tally.so API docs, belong to the form builder — not the accounting software. Search results conflate them constantly; none of those connectors help us.

Why Tally still matters despite the awkward architecture: Tally is the default books-of-account for a very large share of Indian SMBs and the mid-market. If Orcha wants to serve Indian customers (or the India operations of multi-national customers), "we integrate with Tally" is effectively table stakes — but it is an agent/connector integration, not an API integration, and should be scoped as such.

1. Summary — Capability Matrix

Overall assessment. Tally's data capabilities are genuinely good: it is fully bi-directional. You can read masters and vouchers, and you can write ledgers, cost centres and purchase vouchers (with GST/HSN/inventory detail) through a well-documented XML interface. For the core Orcha job — "create a coded purchase voucher in the customer's books from a processed invoice" — Tally can absolutely accept that write.

The problem is not capability, it is reachability and operational shape:

1. Tally listens on localhost. Orcha's cloud cannot call it directly. Every real-world Tally integration solves this with an agent installed on the customer's Tally machine/LAN that bridges local Tally ↔ the vendor's cloud. Orcha would have to build, ship, and support such an agent — or rent one (see §5).
2. No events. There are no webhooks. Document lifecycle (posted / approved / cancelled) can only be discovered by polling the Day Book.
3. No PDF attachment, no approval API. Two of Orcha's six core integration needs simply are not in Tally's data model — they exist only as paid third-party TDL add-ons, which we cannot assume any given customer has installed.
4. It's a desktop process. Throughput, uptime, and concurrency are bounded by the customer's PC being switched on, Tally being open, and the right company being loaded.

This is closest in shape to the SAP S/4HANA on-premise research already in this folder: a capable system whose integration cost is dominated by connectivity, not by the API.

2. API Landscape

2.1 Integration surfaces

There is no central REST API, no OAuth, no developer portal, and no API keys. "Authentication" is simply whether your request can reach the Tally process, plus Tally's own internal user security on the loaded company.

2.2 How the HTTP interface is enabled

On the customer's TallyPrime: F12 (Configure) → Data Synchronization / Connectivity → set Tally as Server, default port 9000. The integrating app then POSTs to http://<tally-host>:9000 with Content-Type: text/xml. This is a built-in feature of every TallyPrime edition — no add-on licence required to switch it on.

2.3 XML envelope structure

<ENVELOPE>
  <HEADER>
    <VERSION>1</VERSION>
    <TALLYREQUEST>Import</TALLYREQUEST>   <!-- Import | Export | Execute -->
    <TYPE>Data</TYPE>
    <ID>All Masters</ID>                  <!-- or "Vouchers", or a report name -->
  </HEADER>
  <BODY>
    <DESC>
      <STATICVARIABLES>
        <SVCURRENTCOMPANY>Acme Pvt Ltd</SVCURRENTCOMPANY>
        <!-- for reads: <SVFROMDATE>, <SVTODATE> etc. -->
      </STATICVARIABLES>
    </DESC>
    <DATA>
      <TALLYMESSAGE>
        <!-- LEDGER / GROUP / COSTCENTRE / VOUCHER object goes here -->
      </TALLYMESSAGE>
    </DATA>
  </BODY>
</ENVELOPE>

• TALLYREQUEST = Export → read. Import → write. Execute → run an action/function.
• Dates are strictly YYYYMMDD.
• The import response returns a log: counts of vouchers/masters created, altered, combined, ignored, and errored.

2.4 Official tooling

• TallyHelp Developer Reference — help.tallysolutions.com/developer-reference/ — the canonical docs for the XML interface, TDL, and integration capabilities.
• TallyPrime API Explorer — tallysolutions.com/tallyprime-api-explorer/ — an official interactive sandbox to build/validate XML and JSON requests for both reads and writes (masters: ledgers, groups, stock items, units; transactions: payment, receipt, sales, purchase). This is the most "modern" piece of Tally's official API story and is the right starting point for a build.
• TallyPrime Developer — the paid IDE for writing TDL (syntax highlighting, debugger, multi-project). Needed only if Orcha chooses the TDL route.

3. Write Capability Verification

Write is confirmed and well documented. This is not an inferred capability — Tally's entire Import request type exists to write data in.

Writable masters: Groups, Ledgers, Cost Categories, Cost Centres, Stock Groups, Stock Items, Units of Measure, Godowns, Voucher Types, Currencies.

Writable transactions: all voucher types — Purchase, Sales, Payment, Receipt, Journal, Contra, Debit/Credit Note, etc. Vouchers can be created, altered, cancelled, and deleted (the operation is set via an ACTION attribute on the object). Purchase vouchers accept supplier invoice number, GST/tax detail, HSN codes, and inventory lines.

Constraints / gotchas:

• Masters before transactions — a voucher referencing a ledger/stock item/cost centre that does not yet exist will be rejected. Orcha must sync (or upsert) reference data first.
• Vouchers must balance — total debit must equal total credit, or the import errors.
• Duplicate handling is explicit: DupModify (overwrite), DupCombine (merge), DupIgnoreCombine (skip if exists) — set in the request DESC.
• Error reporting is weak — failures land in the Tally.imp log file on the customer's machine; the XML response is terse. Expect to invest in defensive validation before sending.
• No documented rate limits or batch caps — but this cuts both ways: throughput is bounded by a single desktop CPU, and large imports block the Tally UI.

Community corroboration: multiple independent toolkits write to Tally via this exact interface — the tally-integration Python package on PyPI, community repos (e.g. NoumaanAhamed/tally-prime-api-docs, aadil-sengupta/Tally.Py), and a large ecosystem of "Excel-to-Tally" converters. The write path is heavily exercised in the wild.

4. iPaaS & Middleware Discovery

4.1 Mainstream iPaaS — none

There is no Zapier, Make.com, Workato, Celigo, n8n, or Tray.io connector for TallyPrime the accounting software. Every "Tally" app on those marketplaces is the unrelated tally.so form builder (see disambiguation note above). This is expected — mainstream iPaaS connectors assume a reachable cloud endpoint, which Tally does not have.

4.2 Unified accounting APIs

RootFi/Commenda is the single most important finding in this section: it is a working existence proof that a cloud product can integrate with on-premise Tally bi-directionally, and it is the one path where Orcha would not have to build and maintain its own connector agent.

4.3 India-specific middleware & API-as-a-service

A whole cottage industry exists specifically to put an API in front of Tally:

These all use the same underlying XML/HTTP or ODBC interface — they are convenience wrappers, and they all still require something running next to Tally.

4.4 Competitive signal — Suvit / Vyapar TaxOne

Suvit (rebranded Vyapar TaxOne) is an Indian accounting-automation product that does almost exactly what Orcha does: it ingests invoices/bills/receipts/bank statements (photo or PDF), extracts the data with AI, creates vouchers, and pushes them straight into Tally — no manual entry. This is simultaneously (a) hard proof that Orcha's intended use case is technically achievable into Tally, and (b) a note that this space already has India-native incumbents.

5. Alternative Channels & The Connectivity Problem

Because Tally has no reachable cloud endpoint, "how do we reach it" is a first-class architecture decision, not a footnote.

Bottom line: options A and B are the only ones that give a product-grade experience. A is more work but more control; B trades money and a dependency for speed-to-market.

6. Licensing & Access Requirements

6.1 What the customer must already own

Good news: the XML/HTTP API is included in every TallyPrime edition at no extra cost. There is no "API module" to buy, no API-user seat, no per-call metering from Tally itself. This is the opposite of vendors that gate API access behind an Enterprise tier.

6.2 What may cost extra

6.3 What the customer's admin must do before Orcha can connect

1. Install TallyPrime (already done in practice).
2. In F12 → Configure, enable Tally as an HTTP server and confirm the port (default 9000).
3. Ensure the right Company is loaded in Tally whenever a sync runs.
4. Make the Tally machine reachable by the chosen channel — install Orcha's agent (A), install the unified-API agent (B), or set up the hosted bridge (C). This is the real work and is per-customer.
5. Keep Tally running during sync windows (it's a desktop app — if the PC is off, integration is off).
6. Optionally, configure Tally user security so the integration runs under a defined Tally user.
7. Ensure required company features are enabled (e.g. Cost Centres, Inventory, GST) — masters/vouchers that use a disabled feature will be rejected on import.

6.4 Customer-facing setup checklist (for an Orcha onboarding doc)

• TallyPrime installed, licensed, on a supported version (TallyPrime 6.x recommended)
• Tally configured as HTTP server (F12), port noted
• Required company features on: Cost Centres, Inventory (if used), GST
• Connectivity method agreed: Orcha agent / unified API / hosted bridge / file drop
• If agent: agent installed on the Tally machine, allowed through local firewall/AV
• A dedicated Tally user created for the integration (recommended)
• Agreement on which Company name the integration targets
• Sync-window expectations set (machine on, Tally open, correct company loaded)

7. Orcha-Specific Deep Dive

Orcha Integration Capability Summary

Net: four of Orcha's six core data needs are cleanly met; "attach PDF" and "approvals" are not, and "status" is poll-only. None of that is the hard part — the hard part is connectivity, which is a build-or-buy decision before any XML is written.

8. Recommended Path Forward

Architecture decision

Recommended phased plan

1. Phase 0 — De-risk connectivity (decide build-vs-buy). Before any feature work, get a current quote and product status from Commenda (post-RootFi) for their Tally connector + unified API, and scope what an Orcha-built agent would cost to build and support. This decision gates everything else. Recommendation: start on RootFi/Commenda to validate demand, keep "build our own agent" as the scale play.
2. Phase 1 — Reference data sync. Read the customer's ledgers, groups, cost categories and cost centres into Orcha so invoice coding validates against real master data. Build and test reads against the TallyPrime API Explorer first.
3. Phase 2 — Push purchase vouchers. Write coded purchase vouchers (with GST/HSN and cost-centre allocations). Upsert any missing masters first. Decide the approval posture: push as a normal voucher, or push as an Optional Voucher for a human to regularise in Tally.
4. Phase 3 — Status read-back. Poll the Day Book on a schedule; reconcile pushed vouchers (posted? altered? cancelled?) and infer "paid" from linked payment vouchers. Set customer expectations that this is near-real-time, not event-driven.
5. Phase 4 — Decide on PDF/approvals. Accept that the source PDF stays on Orcha's side (link out, don't attach), unless a specific customer has a Document Attachment TDL add-on worth integrating with. Treat real approval workflow as out of scope for Tally.

Headline recommendation

Tally is integrable and the data model fits Orcha's AP use case well — but treat this as an on-premise connector project, not an API project. Budget the effort against connectivity (build or rent an agent), not against XML. The fastest credible route to a working Indian-market integration is RootFi/Commenda's unified API (subject to confirming its post-acquisition status); building Orcha's own connector agent is the higher-control, higher-cost alternative worth revisiting once Tally demand is proven.

9. Sources

Official Tally documentation

• Integration with TallyPrime — TallyHelp
• Integration Methods and Technologies — TallyHelp
• Developer Reference — TallyHelp
• Integration using XML Interface — TallyHelp
• Case Study 1 — XML Request and Response Formats — TallyHelp
• Tally Definition Language (TDL) — TallyHelp
• TallyPrime API Explorer
• TallyPrime Developer
• Tally Integration (official overview)
• Release Notes — TallyPrime 6.0 — TallyHelp
• Licensing TallyPrime — TallyHelp
• Export / Import Data — Masters and Vouchers — TallyHelp
• TallyPrime on Cloud

Community / developer

• NoumaanAhamed/tally-prime-api-docs (GitHub)
• aadil-sengupta/Tally.Py (GitHub)
• tally-integration (PyPI)
• TallyXML — Postman public collection

Unified API / middleware

• RootFi — Tally Prime integration
• RootFi — bi-directional sync with Tally Prime
• RootFi — Tally ERP9 integration
• Commenda — Integrations (RootFi acquired by Commenda, ~March 2025)
• Merge — accounting integrations
• api2books.com — pricing
• tallyprimeapi.com — GET API pricing
• CData — Tally drivers

Pricing & licensing

• TallyPrime Pricing 2025 — Antraweb
• TallyPrime Pricing — SaaSworthy

Competitive / ecosystem

• Suvit / Vyapar TaxOne — data automation into Tally
• TallyPrime Transaction Authorisation Module — Antraweb
• Multi-file Attachment Module for TallyPrime — Antraweb

Verification flags (could not be fully confirmed in this pass)

• RootFi → Commenda post-acquisition product name, pricing, and whether the standalone unified API is still independently sold — RootFi/Commenda docs pages were not directly retrievable; confirm with Commenda sales.
• TallyPrime Developer pricing — not published; sales contact required.
• Whether any connectivity feature is gated behind active TSS — base XML/HTTP appears not to be, but confirm for the chosen design.
• Exact XML tag names for cost-centre allocations inside a voucher — attested but should be confirmed against the live TallyPrime API Explorer during Phase 1.