TallyPrime and Stedi integration

What moves between them

The main flow runs from TallyPrime to Stedi. ml-connector polls TallyPrime on a schedule (default every 10 minutes) for Vouchers with a Voucher Type of Purchase or Sales, and for Purchase Orders. Each detected purchase voucher maps to a Stedi 850 Purchase Order, and each sales voucher maps to a Stedi 810 Invoice, with line-item details captured from the Stock Items and Ledger accounts referenced. The translated EDI messages are posted to Stedi with an Idempotency-Key for deduplication, and Stedi routes them to the configured trading partner connections (SFTP, AS2, or webhook). Reference data such as Ledger and Group information is synced once at setup to establish the field mappings. Inbound responses from trading partners (855 PO Acknowledgments, 865 PO Change Acknowledgments) flow back through Stedi webhooks to ml-connector for logging and optional audit trail capture, but do not automatically post back to TallyPrime.

How ml-connector handles it

ml-connector runs a local agent that receives the TallyPrime host IP, company name, and optional username/password, then polls the Ledger, Group, and Voucher collections on your configured schedule using TallyPrime's Export Data envelope. On each poll, it filters for Vouchers modified since the last sync and compares their IDs to detect new or changed records. Each purchase voucher is translated into a JSON object matching Stedi's 850 Purchase Order format, with line items populated from Stock Items and amounts from Ledger accounts. Each sales voucher becomes a Stedi 810 Invoice. The translated payload is POST'd to Stedi with the API key in the Authorization header and a unique Idempotency-Key, so a retry does not create a duplicate. Stedi then applies its configured Transaction Settings and Connection routing to determine which partners receive the EDI message and over which protocol. Because TallyPrime's port 9000 is not remotely exposed and the company must be open in the application, ml-connector assumes a single-user environment and keeps requests sequential to avoid inconsistency. Idempotency is enforced on the Stedi side, and on the TallyPrime side by tracking Voucher IDs and sync timestamps. Failed transmissions to Stedi are logged and can be replayed. Inbound EDI from partners is parsed by Stedi, converted to JSON, and delivered via webhook to a configured endpoint for logging or archival, though automatic posting back to TallyPrime is not included.

A real-world example

A regional distributor runs TallyPrime for accounting and inventory, and ships goods to wholesale partners who require purchase orders and invoices in X12 EDI format. Before the integration, the finance team exported purchase vouchers from TallyPrime weekly, manually translated them into EDI files, and uploaded them to each partner's EDI portal or SFTP server, a process prone to data-entry errors and taking several hours each cycle. With TallyPrime and Stedi connected, each purchase voucher creates an EDI 850 automatically, and sales invoices become 810 EDI messages that route directly to the partner's portal or SFTP server via Stedi's connection rules. Partners receive orders and invoices on the same day they are recorded in TallyPrime, and exceptions are surfaced in the audit trail for quick investigation.

What you can do

• •Poll TallyPrime vouchers on a configurable schedule and translate Purchase and Sales vouchers into Stedi 850 and 810 EDI formats.
• •Map TallyPrime Ledger accounts and Stock Items to EDI line-item and amount fields so trading partners receive correctly structured data.
• •Post translated EDI messages to Stedi with API key authentication and Idempotency-Key deduplication, preventing duplicate transmissions on retry.
• •Route EDI documents to trading partners through Stedi's configured SFTP, FTPS, AS2, or webhook connections without manual file uploads.
• •Receive inbound EDI acknowledgments and change requests from trading partners via Stedi webhooks and log them for reconciliation and audit trail.

Questions

How does ml-connector access TallyPrime if it runs on a desktop machine?

ml-connector requires a local agent running on the same LAN as the TallyPrime machine. The agent connects to port 9000 on the TallyPrime host IP, which you configure once at setup. TallyPrime must be running and the target company must be open for API calls to succeed. You provide the company name and optional password, and the agent polls on your schedule.

What happens if a TallyPrime voucher changes after it has been sent to Stedi?

ml-connector tracks Voucher IDs and sync timestamps, so if you modify a voucher in TallyPrime, the next poll detects the change and sends an updated message to Stedi with the same Idempotency-Key. Stedi deduplicates within a 24-hour window, so the update replaces the prior version without creating a duplicate.

Can ml-connector automatically post inbound EDI acknowledgments from trading partners back into TallyPrime?

Stedi delivers inbound EDI (855 PO Acknowledgments, 865 PO Change Acknowledgments) to a webhook endpoint configured in ml-connector, and they are logged and available in the audit trail. However, automatic posting of acknowledgment data back to TallyPrime is not included; it is treated as a read-only reference for order reconciliation.