TallyPrime and ServiceTitan integration

What moves between them

The main flow runs from TallyPrime into ServiceTitan. Purchase vouchers and inventory movements from TallyPrime are polled on a regular interval and synced into ServiceTitan as vendor bills and inventory transactions. The mappings are one-way: TallyPrime is the source of truth for purchasing and inventory counts, while ServiceTitan updates its records to match. Vendor names and item SKUs must align between the two systems for records to route to the correct accounts.

How ml-connector handles it

ml-connector requires a local agent running on the same machine or LAN as TallyPrime to bridge the cloud connector to port 9000, since TallyPrime is not internet-accessible. The agent polls TallyPrime at a regular cadence by sending Export Data requests with date filters, compares returned voucher IDs against the last-seen state, and forwards new or changed records to ServiceTitan. On the ServiceTitan side, ml-connector stores OAuth2 credentials encrypted, requests a new token when the current one approaches expiry (every 15 minutes), and validates the App Key on every call. Because TallyPrime has no native idempotency and concurrent requests can cause inconsistent behavior, ml-connector keeps all requests to TallyPrime strictly sequential. Vendor names and item codes are mapped by exact string match; mismatches are flagged in the audit log for manual review. Purchase orders marked received in ServiceTitan generate inventory bills automatically, but those bills are read-only and do not flow back to TallyPrime.

A real-world example

A mid-sized electrical contracting service runs TallyPrime for accounting and inventory at their main office, and uses ServiceTitan to dispatch technicians and manage jobs across three service territories. Before the integration, the accounting team entered purchase invoices in TallyPrime and then manually logged inventory transactions in ServiceTitan, often days later when invoices were processed. This created inventory blindspots where the field teams thought stock was available when accounting had not yet recorded a recent shipment. With TallyPrime and ServiceTitan connected, each purchase is synced automatically from TallyPrime to ServiceTitan within the polling interval, so inventory levels reflect reality and the teams dispatch with current stock visibility. Month-end reconciliation now matches without manual adjustment, and the accounting team has one less manual step to oversee.

What you can do

• •Sync purchase vouchers from TallyPrime into ServiceTitan as vendor bills with item details and amounts.
• •Keep ServiceTitan inventory levels in sync with TallyPrime stock movements and adjustments.
• •Map vendors by exact name match between TallyPrime ledgers and ServiceTitan vendor records.
• •Authenticate TallyPrime via local network access and ServiceTitan via OAuth2 with token caching and refresh.
• •Poll TallyPrime on a regular schedule with sequential requests, full audit trail, and automatic retry on timeout.

Questions

How does ml-connector access TallyPrime if it runs on a local port?

ml-connector uses a local agent that runs on the same machine or LAN as TallyPrime and bridges cloud requests to port 9000. The agent is installed and managed by the customer; ml-connector routes all TallyPrime API calls through it. The TallyPrime HTTP server must be manually enabled in Advanced Configuration by the user.

Can inventory changes in ServiceTitan flow back into TallyPrime?

No. The integration is one-way from TallyPrime into ServiceTitan. TallyPrime is the source of truth for inventory counts and purchase records. ServiceTitan's inventory bills are read-only and generated automatically from received purchase orders; they do not write back to TallyPrime.

What happens if a vendor name or item code does not match between the two systems?

ml-connector matches vendors by exact string and item codes by SKU. If a match is not found, the record is not synced and is logged in the audit trail with the mismatch reason. The record can be replayed after the vendor or item is created in the target system.