n8n + Tally Prime — building a real-time MIS pipeline

The problem statement

You're running a Pvt Ltd with ₹5-50 Cr turnover. Books are in Tally Prime. You want:

• A live dashboard showing today's sales, outstanding receivables, top 10 customers, and cash balance
• Updates every 15-30 minutes, not "tomorrow morning when the accountant exports"
• Accessible from a mobile browser, not just on the accountant's Tally machine
• Auto-emailed snapshots at 6 PM daily to founders
• Slack alerts when a high-value invoice clears or a receivable crosses 60 days

Tally Prime alone gives you (1) but not (2)-(5). n8n bridges the gap. Total infrastructure cost: ₹400/month VPS + ₹0 Google Sheets / Notion / Metabase. Setup time: 8-12 hours for a competent automation engineer. Maintenance: ~2 hours/month.

The architecture

Three layers:

1. Source — Tally Prime running on a Windows machine with ODBC server enabled on port 9000 (default). Or, less elegantly, scheduled XML exports to a folder.
2. Pipeline — n8n workflow polling the ODBC connection every N minutes, transforming the rows, deduping, enriching with GST rate / customer category, etc.
3. Landing — Where the data ends up for visualisation. Google Sheets is the easiest (no setup, mobile-friendly, formulas work). Notion is prettier but slower. Metabase + Postgres is the production-grade choice for ≥ 20 dashboards.

Setting up Tally ODBC (5 minutes)

1. Open Tally Prime → F1 (Help) → TDL & Add-on → Manage ODBC Server
2. Set "Enable ODBC Server" to Yes
3. Note the port (default 9000)
4. Tally must remain running on the machine; ODBC is in-process
5. Test connection from another machine: tnsping <tally-machine-ip> 9000

The n8n workflow — step by step

Step 1: Schedule trigger

Cron node firing every 15 minutes. For low-traffic businesses, 30 minutes is fine. Avoid < 5 min — Tally locks during ODBC query and may slow voucher entry.

Step 2: ODBC query node

Use n8n's "Database" node with ODBC driver. Connection string:

Driver={Tally ODBC Driver};Server=192.168.1.100;Port=9000

Sample query — today's sales by customer:

SELECT $Name AS customer,
       $LedgerName AS ledger,
       $Amount AS amount,
       $Date AS voucher_date
FROM Vouchers
WHERE $Date = $Today
  AND $VoucherTypeName = "Sales"
ORDER BY $Amount DESC

Tally ODBC uses TDL-style column names ($Name, $Amount). Returns JSON rows in n8n.

Step 3: Transform & enrich

Function node to:

• Parse Tally's date format (DD-MMM-YYYY) into ISO
• Convert $Amount (string with commas) to Number
• Add a "category" field (GST rate band, customer geography, etc.)
• Compute YTD running totals

const items = $input.all().map(item => ({
  date: parseTallyDate(item.json.voucher_date),
  customer: item.json.customer,
  amount: Number(item.json.amount.replace(/,/g, '')),
  gstRate: lookupGstRate(item.json.ledger),
  category: classifyCustomer(item.json.customer)
}));
return items;

Step 4: Dedupe + upsert to landing

n8n's "Google Sheets" node with an upsert mode keyed on voucher_id prevents duplicates across runs. For Postgres landing, use the SQL INSERT … ON CONFLICT pattern.

Step 5: Trigger alerts

IF node: if any row's amount > ₹5 L → branch to Slack node. If receivable age > 60 days → branch to email node. Chain conditional logic as the business demands.

Step 6: Error handling

Wrap the workflow with an "On Error" branch that posts to a #ops Slack channel. Tally ODBC fails for two reasons: (a) Tally has been closed, or (b) someone is doing data entry in the same voucher type (ODBC takes read-lock during query). Both are recoverable — retry in 60 seconds.

Polling vs webhook — and the Tally truth

n8n loves webhooks, but Tally Prime does not natively emit them. Three workarounds:

• Polling (recommended) — n8n polls Tally every N minutes. Simple, reliable, but always 0-15 min stale.
• TDL trigger — write Tally TDL code that fires an HTTP request to n8n on voucher save. Complex; requires a Tally developer. Real-time but fragile.
• File-watch — Tally auto-exports a fixed-name XML on voucher save (TDL config); n8n's "watch folder" node picks it up. Middle-ground; near-real-time but disk-IO-heavy.

For 90% of SME MIS use-cases, polling at 15-minute cadence is the right answer. The marginal value of true real-time rarely justifies the TDL development cost.

Landing layer — pick by team size

Team size	Landing	Why
Solo founder, ≤ 3 dashboards	Google Sheets	Zero setup, mobile-friendly, formulas, native sharing
5-10 people, 5-10 dashboards	Notion database + views	Prettier, role-based sharing, comments
Finance team of 3+, 10+ dashboards	Postgres + Metabase	Real BI: drill-down, scheduled reports, SQL
Multi-entity / multi-company	Postgres + Metabase + dbt	Centralised data warehouse with cross-entity rollups

Common queries we ship

• Daily sales by customer — top 20, with previous-day comparison
• Outstanding receivables ageing — 0-30, 31-60, 61-90, 91+ days
• Cash & bank position — all banks, all currencies, with previous-week trend
• GSTR-1 pre-check — sales summary by GSTIN + tax rate, formatted for upload
• Top-10 customers YTD — with quarterly growth rates
• Vendor payables ageing — for MSME Sec 43B(h) compliance — see our MSME brief
• Stock value by godown — for multi-location businesses
• Daily working-capital cycle — DSO + DIO − DPO trends

The "what about audit trail?" question

Reading data from Tally via ODBC is read-only and doesn't touch Tally's edit log. So MIS extraction is fully compatible with the audit-trail mandate (see Aqeel's brief). The n8n workflow never modifies vouchers — it queries, transforms and forwards.

Where you should be careful: writing data back to Tally from n8n (auto-creating purchase vouchers from a vendor portal, for instance). That writeback would log under the n8n user's Tally credentials in the edit log. Make sure the writeback user is named clearly (e.g. n8n-bot with a unique password), not a shared admin account.

The full Finclar architecture (for reference)

For our retainer clients we typically deploy:

• Tally Prime 4.0+ on a Windows VM (Hetzner / DO / AWS Lightsail) with edit log enabled
• n8n self-hosted on Ubuntu, same network as the Tally VM, behind Cloudflare Tunnel
• Postgres on the same instance for landing
• Metabase on a separate small VPS (₹400/mo) for dashboards
• Cloudflare R2 for file storage (PDF reports, exported invoices)
• Slack workspace integration for alerts
• Daily Postgres dumps to R2 for backup

Total monthly infrastructure cost for a typical ₹20 Cr-turnover client: ₹1,200-1,800/month. Build cost: ₹85K-1.4 L one-time depending on the number of dashboards. Most clients ROI in < 6 months via founder time savings + faster receivables collection from better visibility.

When this pipeline isn't worth it

• Turnover < ₹2 Cr — too few transactions, the daily Excel export is fine
• Single decision-maker who's also the accountant — they see the data in Tally directly
• Highly seasonal business with 3 months of activity — manual works
• If you're considering switching to Zoho Books anyway — wait for the migration, then Zoho's native APIs make this much easier

How to start

If you're interested in setting this up:

1. Make sure your Tally Prime is 4.0+ (older versions have flakier ODBC)
2. Enable ODBC server and test from a second machine on your network
3. Decide your landing layer (Sheets is fine for v1)
4. Spec out 3-5 dashboards you actually need (don't build everything; build what you'll check daily)
5. Either DIY (allow 2-3 weekends if you're an engineer) or have us run the project (1-2 weeks fixed-fee, ₹35-60K for a Sheets-landing setup)

For the full menu of automation services see /automation. The Tally + n8n stack is the most common starting point for our SME clients.