TallyPrime and Tipalti integration

What moves between them

The primary flow is from Tipalti into TallyPrime. When an invoice is received or updated in Tipalti, ml-connector converts it to a TallyPrime purchase voucher and posts it to the target ledger and group mapped from Tipalti GL accounts and supplier master data. When a payment is submitted and completed in Tipalti, ml-connector creates a TallyPrime payment voucher. Payee changes in Tipalti sync to TallyPrime groups and master ledger entries. TallyPrime is read-only from Tipalti's perspective; ml-connector does not write payment or invoice data back into Tipalti. The sync is triggered by Tipalti IPN webhooks when available, with a polling fallback on a configurable schedule (minimum 5-15 minute intervals) when webhooks are not configured.

How ml-connector handles it

ml-connector runs a local agent that communicates with TallyPrime on port 9000 using XML or JSON envelopes with the company name and optional credentials. It receives Tipalti IPN webhook events and verifies the HMAC-SHA256 signature using the API key. For each invoice or payment event, ml-connector builds a TallyPrime voucher (purchase, payment, or receipt type) and imports it via an XML POST to the local TallyPrime server. Before importing, it maps Tipalti GL accounts and supplier IDs to TallyPrime groups and ledger names, ensuring the voucher lands on valid accounts. Since TallyPrime has no native idempotency, ml-connector tracks imported vouchers by Tipalti event ID to prevent duplicate imports on webhook retry. If a webhook is not configured or fails, ml-connector falls back to polling TallyPrime day books and Tipalti invoice/payment APIs on a regular schedule, comparing returned IDs against the last-seen state. TallyPrime's single-user nature means requests must be sequential; ml-connector queues concurrent events. Because TallyPrime returns errors as text in XML blocks rather than HTTP status codes, ml-connector parses the LINEERROR and IMPORTRESULT blocks to detect failures and retry or alert. All operations are logged in the audit trail with the original Tipalti event payload.

A real-world example

A mid-sized services company in India uses TallyPrime for accounting and GST filing, and Tipalti to manage invoices from dozens of contractors and vendors worldwide, with payment approvals routed through the finance team. Before integration, invoices arrived in Tipalti, were approved and paid, but then the finance team had to re-enter each invoice and payment into TallyPrime by hand, matching amounts to supplier codes and cost centers. With TallyPrime and Tipalti connected, each invoice that arrives in Tipalti automatically posts to the purchase ledger in TallyPrime, and each payment that completes in Tipalti posts as a payment voucher, allocated to the correct supplier group. The manual re-entry is gone, and the accounts payable aging report in TallyPrime now reflects Tipalti's source of truth.

What you can do

• •Post Tipalti invoices and GRNs to TallyPrime as purchase vouchers, allocated to the correct supplier ledgers and groups.
• •Sync Tipalti payments into TallyPrime as payment vouchers, mapped to the target payment method ledger.
• •Keep Tipalti payee master data aligned with TallyPrime supplier groups and master ledger entries.
• •Handle Tipalti HMAC-SHA256 webhook verification and the local TallyPrime HTTP port 9000 bridge with automatic fallback to polling.
• •Track Tipalti event IDs to prevent duplicate imports on webhook retry, with a full audit trail on every record.

Questions

Why does ml-connector need a local agent to connect to TallyPrime?

TallyPrime's HTTP server runs on port 9000 inside a local network and is only accessible from the same machine or LAN. ml-connector runs a local agent on that same network to forward requests from the cloud to the TallyPrime server, since cloud connectors cannot directly access LAN ports. The agent is lightweight and requires only the TallyPrime company name and optional credentials to authenticate.

How does ml-connector handle the lack of native idempotency in TallyPrime imports?

Because duplicate imports create duplicate vouchers in TallyPrime, ml-connector tracks the Tipalti event ID of every import and stores it locally. When a Tipalti webhook is retried or when polling detects the same invoice or payment, ml-connector looks up the event ID and skips the import if it has already been recorded. This prevents duplicate vouchers even if Tipalti retries the webhook or if ml-connector crashes and recovers.

What happens if Tipalti webhooks are not configured?

ml-connector automatically falls back to polling TallyPrime and Tipalti on a configurable schedule (minimum 5 to 15 minute intervals). It reads the TallyPrime day book and Tipalti invoice and payment APIs, compares the returned IDs against the last-seen state, and imports new or changed records. Polling is slower than webhooks but ensures the sync works regardless of network configuration.