Which direction does data move between TallyPrime and Adobe Commerce?

The main flow is Adobe Commerce into TallyPrime. Orders, invoices, and credit memos move from the storefront into Tally as Sales vouchers and credit notes, while customers and products are kept aligned as Ledgers and Stock Items. TallyPrime is the accounting destination, so financial entries are not written back into Adobe Commerce.

How are duplicate orders avoided when neither system has idempotency keys?

TallyPrime has no idempotency key and a repeated Import Data call would create a duplicate voucher, and Adobe Commerce has no idempotency header either. ml-connector tracks each imported voucher number against the Commerce order's increment_id, and uses Tally's Alter action to update an existing voucher instead of creating a new one. BullMQ job dedup on the connector side guards against re-delivered webhooks.

TallyPrimeAdobe Commerce

TallyPrime and Adobe Commerce integration

TallyPrime handles accounting, inventory, and GST in a desktop application. Adobe Commerce runs the online storefront and its order pipeline. Connecting the two posts each paid order from Adobe Commerce into TallyPrime as a Sales voucher, so the sales ledger reflects storefront revenue without re-keying. Storefront customers become Ledgers and catalog SKUs become Stock Items, and refunds issued in Commerce flow through as credit notes. ml-connector handles the very different transports on each side and moves the data on the schedule you set.

How TallyPrime works

TallyPrime is desktop-first and exposes a local HTTP server on port 9000 that accepts XML or JSON envelopes, where the TALLYREQUEST field selects Import Data for writes or Export Data for reads. There are no per-resource REST URLs and no cloud endpoint, so a connector must reach it through a local agent on the same machine or LAN. All accounts, including customers and suppliers, are Ledgers grouped under a parent such as Sundry Debtors; transactions are vouchers of type Sales, Purchase, Payment, or Receipt; products are Stock Items. The interface has no transport authentication by default, no webhooks, and no native pagination, so change detection is done by polling the Day Book within an SVFROMDATE and SVTODATE range. All dates use the YYYYMMDD format.

How Adobe Commerce works

Adobe Commerce exposes orders, invoices, customers, companies, products, and credit memos through versioned REST endpoints under a V1 path, with GraphQL available for read-heavy queries. PaaS instances authenticate with OAuth 1.0a integration credentials or an admin bearer token; the cloud service uses IMS OAuth 2.0 client credentials with roughly 24-hour tokens. List endpoints page through searchCriteria parameters for pageSize and currentPage, and records carry both an internal entity_id and a human-readable increment_id. Adobe Commerce supports synchronous outbound webhooks signed with HMAC SHA256 in an x-adobe-commerce-webhook-signature header, and Adobe I/O Events for async delivery. It has no GL account resource, so general ledger mapping happens in the accounting system that consumes the data.

What moves between them

The main flow runs from Adobe Commerce into TallyPrime. As orders are placed and invoiced, ml-connector reads the order, invoice, and credit memo records and writes them into TallyPrime as Sales vouchers and credit notes, with line items allocated to the matching Stock Items. Storefront customers are created or updated as Ledgers under Sundry Debtors, and catalog products are kept in step as Stock Items so every voucher line references an item that exists in Tally. Adobe Commerce order and invoice webhooks trigger the work as soon as a sale settles, and a scheduled Commerce poll backfills anything a webhook missed. TallyPrime is the accounting destination, so financial entries are not written back into the storefront.

How ml-connector handles it

ml-connector stores both credential sets encrypted and authenticates Adobe Commerce with OAuth 1.0a on PaaS or an IMS OAuth 2.0 bearer token on the cloud service, refreshing the token before its roughly 24-hour expiry. Because TallyPrime is only reachable on its local port 9000, every Tally request is routed through an on-premise local agent that forwards XML or JSON envelopes to the desktop instance, which must be running with the target company open. The connector pins SVCURRENTCOMPANY to the exact, case-sensitive company name and formats all dates as YYYYMMDD, since other formats silently fail. Order, invoice, and credit memo webhooks from Adobe Commerce are verified against the HMAC SHA256 signature, and a scheduled Day Book poll covers missed events because TallyPrime cannot push. Commerce customers map to Ledgers under Sundry Debtors, order lines map to Stock Items inside a Sales voucher, and refunds map to credit notes. Since neither side offers idempotency keys, ml-connector tracks each imported voucher number and uses Tally's Alter action to update rather than create a duplicate, retrying failed envelopes with backoff and keeping a full audit trail for replay.

A real-world example

A mid-sized homewares retailer with around 80 staff sells through an Adobe Commerce storefront and keeps its books, inventory, and GST in TallyPrime on a server at head office. Before the integration, a clerk exported the day's orders from Commerce and hand-keyed each sale into Tally as a voucher, reconciling refunds separately, which left the sales ledger a day or two behind and prone to typos during busy periods. With TallyPrime and Adobe Commerce connected, each paid order posts into Tally as a Sales voucher within minutes through the local agent, customers and SKUs stay aligned, and credit memos arrive as credit notes. The ledger matches the storefront in near real time and the manual data entry is gone.

What you can do

Post each paid Adobe Commerce order into TallyPrime as a Sales voucher with line items mapped to Stock Items.
Create and update storefront customers as TallyPrime Ledgers under Sundry Debtors.
Flow Adobe Commerce credit memos into TallyPrime as credit notes so refunds stay reconciled.
Route every TallyPrime call through an on-premise local agent, since port 9000 is not reachable from the cloud.
Verify Adobe Commerce webhook signatures, poll the Day Book for missed events, and retry with a full audit trail.

Questions

Which direction does data move between TallyPrime and Adobe Commerce?: The main flow is Adobe Commerce into TallyPrime. Orders, invoices, and credit memos move from the storefront into Tally as Sales vouchers and credit notes, while customers and products are kept aligned as Ledgers and Stock Items. TallyPrime is the accounting destination, so financial entries are not written back into Adobe Commerce.
Why does the integration need a local agent for TallyPrime?: TallyPrime exposes only a local HTTP server on port 9000 and has no cloud endpoint, so a cloud connector cannot reach it directly. ml-connector talks to an on-premise local agent that forwards XML or JSON envelopes to the Tally instance on the same machine or LAN. The desktop application must be running with the target company open for any call to succeed.
How are duplicate orders avoided when neither system has idempotency keys?: TallyPrime has no idempotency key and a repeated Import Data call would create a duplicate voucher, and Adobe Commerce has no idempotency header either. ml-connector tracks each imported voucher number against the Commerce order's increment_id, and uses Tally's Alter action to update an existing voucher instead of creating a new one. BullMQ job dedup on the connector side guards against re-delivered webhooks.

Connect TallyPrime and Adobe Commerce

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

Get started