Almost every Indian business over a certain size has the same quiet problem. Tally holds the accounts. A CRM or a spreadsheet holds the customers. A website or a marketplace account holds the orders. A bank portal holds the payments.
None of them talk to each other, so a person does it. Someone opens two screens and types what's in one into the other. At month-end, someone reconciles the difference between what the systems each think is true.
Nobody planned this. It accumulated. And the usual proposal — migrate everything to a single ERP — costs more, takes longer, and disrupts more than most businesses can justify.
There's a middle path. You connect the systems you already have.
Why Tally is the hard part (and why it's still worth keeping)
Tally is genuinely good at what it does, your CA knows it, your compliance runs on it, and your team has used it for years. Replacing it is rarely the right call.
But it was designed as a desktop accounting application, not as a system meant to be talked to by other software. That creates three practical constraints:
It usually runs on a machine in your office, not in the cloud. Anything that wants to talk to it has to reach that machine. If it's switched off at 7pm, nothing syncs at 7pm.
Its integration surface is XML over HTTP, not a modern REST API. It works — reliably, actually — but it's older technology and it needs someone who's done it before. Generic connectors that "support Tally" often support only a narrow slice of it.
Your Tally has been customised. Every real Tally installation has years of custom ledgers, voucher types, cost centres and naming conventions that exist for reasons only your accounts team remembers. This is the actual difficulty in most Tally projects — not the technology, the archaeology.
None of that makes integration hard in an absolute sense. It makes it hard for someone who's never done it, which is why generic "connect anything to anything" tools tend to disappoint here.
What connecting Tally actually looks like
There are three approaches, and the right one depends on your volume and how quickly data needs to move.
1. Scheduled sync (the most common)
A job runs every 15 minutes, or hourly, or nightly. It reads new records from one system, transforms them into the shape the other system expects, and writes them across. Errors go into a log and a notification goes to someone who can act on it.
Good for: sales invoices from an e-commerce platform into Tally, ledger balances out of Tally into a dashboard, payment entries from a bank statement, inventory levels from Tally to a website.
Trade-off: data is up to one sync-interval old. For accounting, that's almost always fine.
2. Event-triggered sync
Something happens — an order is placed, a payment lands, a deal is marked won — and that event immediately fires the workflow. No waiting for the next scheduled run.
Good for: anything where a delay is visible to a customer. An order confirmation. A stock reservation. A payment receipt.
Trade-off: more moving parts, and it needs proper retry handling. If Tally's machine is off when the event fires, the workflow has to queue the record and retry rather than silently drop it. This is the single most common failure in badly built integrations.
3. A middleware layer
Instead of connecting five systems to each other in every direction — which becomes an unmaintainable web very quickly — everything connects to one layer in the middle. That layer holds the mapping rules, the retry logic, the error handling, and the audit log of what moved where.
Good for: three or more systems, or where you expect to add more later.
Trade-off: more to build up front. It pays for itself the moment you add the fourth system.
In practice: most businesses start with #1 for one specific pain point, prove it works, then grow into #3 as they add connections. That's a sensible order. Don't build a middleware layer for a single nightly CSV.
The four connections most Indian businesses need first
Website / e-commerce → Tally
An order is placed on Shopify, WooCommerce, Amazon or Flipkart. The sales voucher is created in Tally automatically with the right ledger, the right GST treatment and the right item codes. Stock adjusts.
What this removes: the daily job of someone re-typing yesterday's orders, and the end-of-month reconciliation between what the store sold and what Tally recorded. Where it gets complicated: GST treatment per state, marketplace commission and fee entries, and returns.
CRM → Tally
A deal is marked won in your CRM. The customer ledger is created or matched in Tally, and the invoice is raised without anyone re-entering the customer's details, GSTIN or address.
What this removes: duplicate customer masters, mismatched GSTINs, and the sales-to-accounts handover email. Where it gets complicated: matching an existing ledger rather than creating a duplicate. Name matching is unreliable — match on GSTIN or a stable customer code.
Tally → dashboard / reports
Outstanding receivables, ageing, ledger balances and daily sales pushed automatically to a dashboard, a Google Sheet or a WhatsApp message at a fixed time each morning.
What this removes: the Monday-morning report that someone builds by hand. Where it gets complicated: almost nowhere. This is usually the best first project — read-only, low risk, immediately visible value, and it proves the connection works before you let anything write into your accounts.
Bank statement → Tally
Statements pulled or parsed, entries matched against outstanding invoices, unmatched items flagged for a human.
What this removes: most of manual reconciliation. Where it gets complicated: matching logic. Aim to auto-match the obvious 70–80% and route the rest to a person. Any system claiming 100% automatic reconciliation is either over-promising or silently mis-matching, which is worse.
An example workflow, end to end
A jewellery retailer selling on their own website and on a marketplace:
1. Order placed on Shopify
↓ (webhook fires immediately)
2. Workflow receives the order
↓
3. Look up the customer in Tally by GSTIN or phone
├─ found → use the existing ledger
└─ not found → create the ledger with full address and GSTIN
↓
4. Map SKUs to Tally item codes
└─ unmapped SKU → hold the record, alert the ops team on WhatsApp
↓
5. Determine GST treatment from the delivery state
↓
6. Create the sales voucher in Tally
↓
7. Reduce stock in Tally; push the updated level back to Shopify
↓
8. Send the customer a WhatsApp confirmation with the invoice PDF
↓
9. Log the whole transaction with a reference ID
↓
10. If any step fails: retry 3× with backoff, then alert a human.
Never fail silently.
Steps 4, 5 and 10 are where projects succeed or fail. The happy path is easy. What separates a system you can trust from one you can't is what it does when a SKU isn't mapped, a GSTIN is malformed, or the Tally machine is off.
What it costs
Broadly, based on published Indian agency rates and how these projects scope:
| Scope | Typical build | Typical monthly |
|---|---|---|
| One-way read-only sync (Tally → dashboard/report) | ₹25,000 – ₹60,000 | ₹2,000 – ₹5,000 |
| One-way write (e-commerce → Tally, or CRM → Tally) | ₹60,000 – ₹1,50,000 | ₹5,000 – ₹12,000 |
| Two-way sync with monitoring and error handling | ₹1,50,000 – ₹4,00,000 | ₹10,000 – ₹25,000 |
The variable that moves the number most is how customised your Tally is. A standard installation with clean masters is straightforward. Fifteen years of custom voucher types and inconsistent ledger naming is where the days go — and that's discovery work, not development work, which is why it should be scoped before anyone quotes a build.
Questions to ask before you sign anything
- Have you connected Tally before? Ask for a specific example. Tally XML is not the same as "we integrate anything."
- What happens when the Tally machine is off? The right answer is the record queues and retries. Any other answer means you will lose data.
- Where does the middleware run — my server or yours? For financial data, insist on yours.
- How do I find out something failed? If the answer isn't a notification to a named person, you'll find out from a customer.
- Who owns the mapping rules? They should be documented and readable by you, not buried in someone's code.
- What's the plan when Tally releases a new version?
Key takeaways
- You do not need to replace Tally to make it talk to your other systems. Integration is far cheaper and far less disruptive than an ERP migration.
- Tally's integration surface is XML over HTTP on a machine in your office — workable and reliable, but it needs someone who has done it before.
- Start with a read-only report sync. Low risk, immediately visible, and it proves the connection before anything writes into your accounts.
- The hard part is never the happy path. It's unmapped SKUs, missing GSTINs, and the office machine being switched off. Judge a proposal on how it handles those.
- Insist the middleware runs on your infrastructure and that the mapping rules are documented in a form you can read.
- Match customer records on GSTIN or a stable code, never on name.
Tired of someone re-typing the same data into two screens?
Send us the list of systems you run and where the copying happens. We'll map the connections, tell you which one to build first, and give you a fixed price for it. If we think an integration isn't worth building, we'll say so.
Get my free automation plan → · WhatsApp us
Related: System & data integration services · What automation actually costs in India