Which direction does data move between TallyPrime and Google BigQuery?

Data moves one way, from TallyPrime into Google BigQuery. Vouchers and master data are read out of Tally and loaded into BigQuery tables for reporting. BigQuery is the analytics destination, so ml-connector does not write accounting records back into TallyPrime.

How does ml-connector reach TallyPrime if it only has a local port 9000 server?

TallyPrime's HTTP server on port 9000 is reachable only from the local machine or LAN, never from the cloud. ml-connector talks to an on-premise local agent that forwards XML or JSON envelopes to the Tally process and relays the responses. TallyPrime must be running with the target company open for any export to succeed.

How are duplicate rows avoided when a sync retries?

TallyPrime has no idempotency keys and BigQuery streaming dedup is only best-effort over about a one-minute window. ml-connector maps each Tally voucher number to a stable insertId so a quick retry is deduplicated, and for large backfills it uses batch load jobs keyed by a caller-supplied jobId, which returns the existing job rather than creating a duplicate.

TallyPrimeGoogle BigQuery

TallyPrime and Google BigQuery integration

TallyPrime runs day-to-day accounting on the desktop. Google BigQuery is a cloud warehouse built for SQL analytics over large datasets. Connecting the two moves your Tally vouchers and master data into BigQuery tables so finance and operations can report across companies without exporting spreadsheets. ml-connector reads Tally through a local agent on a schedule you control and loads the rows into the dataset and tables you name. Because both systems are pull-only, the link is a one-way feed from TallyPrime into BigQuery on a fixed cadence.

How TallyPrime works

TallyPrime is a desktop application, not a hosted API, so all access runs against a local HTTP server on port 9000 that takes XML or JSON envelopes over POST, with the TALLYREQUEST field set to Export Data for reads and Import Data for writes. There are no per-resource URLs and no transport-level auth by default, so security comes from network controls and a local agent on the same LAN. Accounts are modeled as Ledgers, and transactions as Vouchers of type Sales, Purchase, Payment, or Receipt, alongside Purchase Orders and Stock Items, readable through the Day Book and collection exports. TallyPrime has no webhooks, so changes are detected by polling with SVFROMDATE and SVTODATE date windows.

How Google BigQuery works

Google BigQuery is a serverless data warehouse reached through the BigQuery REST API v2 over HTTPS, with every call carrying an OAuth 2.0 Bearer token. For a server-to-server connector the token comes from a Google service account using the JWT-bearer grant, with the bigquery scope and the dataEditor plus jobUser IAM roles for read and write. Rows are written either with the streaming insert endpoint insertAll, which supports best-effort dedup via insertId, or with batch load jobs submitted through the Jobs API. Reads run as asynchronous query jobs that are polled until DONE and paged with pageToken. BigQuery sends no webhooks, so any read-back is poll-based.

What moves between them

The flow runs one direction, from TallyPrime into Google BigQuery. On each scheduled run ml-connector exports new and changed vouchers for the date window since the last run, covering sales invoices, purchase bills, payments, and receipts, plus ledger and stock item masters, and streams them as rows into the BigQuery tables you map each entity to. Cadence is the polling interval you set, typically every 5 to 15 minutes, since Tally has no change stream. BigQuery is the reporting destination, not a source of accounting records, so ml-connector does not write transactions back into TallyPrime.

How ml-connector handles it

ml-connector cannot reach Tally from the cloud, so it talks to an on-premise local agent on the customer LAN that forwards envelopes to http://localhost:9000 and relays the responses. Each export specifies the company name in SVCURRENTCOMPANY and a date window in SVFROMDATE and SVTODATE, and dates are formatted strictly as YYYYMMDD or the request silently fails. The service account private key is stored encrypted, with its literal newline characters preserved so JWT signing does not break, and a fresh BigQuery token is fetched before the 3600 second expiry. Tally voucher numbers and master names are mapped to a stable insertId so a retried streaming insert lands inside BigQuery's roughly one-minute dedup window without duplicating rows; for large historical backfills ml-connector batches rows into load jobs keyed by a caller-supplied jobId instead. Tally returns errors as XML text rather than codes, so failures are parsed and surfaced, and the target table schema is checked first since adding nullable columns is safe but renaming them is not.

A real-world example

A wholesale distributor in India with around 120 staff runs three companies in TallyPrime across separate branches for accounting, inventory, and GST. Leadership wanted a single view of sales and outstanding bills across all three, but the only way to compare them was to export day books to spreadsheets and stitch them together by hand, which was a day of work each week and always out of date. With TallyPrime and Google BigQuery connected, every branch's vouchers and ledger balances flow into one BigQuery dataset on a 15-minute schedule, and the team builds dashboards on top in SQL. The weekly export ritual is gone and the numbers are current within minutes.

What you can do

Load TallyPrime sales invoices, purchase bills, payments, and receipts into Google BigQuery tables on a schedule.
Sync ledger and stock item master data so warehouse tables carry the same names and balances as Tally.
Reach the on-premise port 9000 server through a local agent that bridges the cloud connector to the customer LAN.
Authenticate BigQuery with a service account JWT-bearer token and keep it refreshed before each run.
Track Tally voucher numbers as BigQuery insertId values so a retried poll does not double-load rows.

Questions

Which direction does data move between TallyPrime and Google BigQuery?: Data moves one way, from TallyPrime into Google BigQuery. Vouchers and master data are read out of Tally and loaded into BigQuery tables for reporting. BigQuery is the analytics destination, so ml-connector does not write accounting records back into TallyPrime.
How does ml-connector reach TallyPrime if it only has a local port 9000 server?: TallyPrime's HTTP server on port 9000 is reachable only from the local machine or LAN, never from the cloud. ml-connector talks to an on-premise local agent that forwards XML or JSON envelopes to the Tally process and relays the responses. TallyPrime must be running with the target company open for any export to succeed.
How are duplicate rows avoided when a sync retries?: TallyPrime has no idempotency keys and BigQuery streaming dedup is only best-effort over about a one-minute window. ml-connector maps each Tally voucher number to a stable insertId so a quick retry is deduplicated, and for large backfills it uses batch load jobs keyed by a caller-supplied jobId, which returns the existing job rather than creating a duplicate.

Connect TallyPrime and Google BigQuery

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started