TallyPrime and BILL integration

What moves between them

The main flow runs from TallyPrime into BILL. ml-connector reads supplier ledgers and Purchase vouchers from TallyPrime and creates matching vendors and bills in BILL so each invoice can be approved and paid through the BILL workflow. Once BILL settles a payment, the payment record flows back into TallyPrime as a Payment voucher, allocated against the original bill so the supplier balance clears. Vendor master records are kept aligned so each bill in BILL references a vendor that already exists. Purchase orders stay in TallyPrime, since BILL has no purchase order object, so only bills and payments move between the two systems.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It forwards XML or JSON envelopes to the TallyPrime local agent, which relays them to the port 9000 server on the customer LAN, and on the BILL side it performs the session login, caches the sessionId, and re-authenticates and retries when a call returns a 401 because the session has gone silent. TallyPrime supplier ledgers map to BILL vendors and Purchase vouchers map to BILL bills, with vendors synced first so every bill resolves to a vendor that exists. Because TallyPrime cannot push events, ml-connector polls the Day Book over a date range on a schedule rather than waiting for a callback, and it can take a BILL bill.created or payment.updated webhook, verified by HMAC-SHA256 against the x-bill-sha-signature header, as a trigger to pull the latest state. Neither system offers an idempotency key, so ml-connector dedupes on the TallyPrime voucher number and the BILL entity ID before writing, which is the only safe guard against duplicate bills since a repeated Import Data call in TallyPrime creates a duplicate voucher. It keeps BILL requests within the three-concurrent limit and backs off on the BDC_1144 hourly rate-limit error.

A real-world example

A mid-sized distributor in India with roughly eighty staff runs TallyPrime for accounting, inventory, and GST, but pays its overseas and domestic suppliers through BILL to get approval routing and ACH payments. Before the integration, the AP clerk entered each purchase bill in TallyPrime and then typed it again into BILL to schedule payment, and once BILL paid, a second person recorded the payment back in TallyPrime by hand. Bills were paid late when the second entry slipped, and the supplier ledger in TallyPrime often disagreed with what BILL had actually paid. With TallyPrime and BILL connected, each purchase bill flows into BILL for approval automatically, settled payments post back as payment vouchers against the right bill, and the supplier balances in TallyPrime match BILL without a reconciliation pass.

What you can do

• •Push TallyPrime supplier ledgers and Purchase vouchers into BILL as vendors and bills for approval and payment.
• •Pull settled BILL payments back into TallyPrime as Payment vouchers allocated against the original bill.
• •Keep the BILL vendor list aligned with TallyPrime supplier ledgers so every bill resolves to a known vendor.
• •Bridge the TallyPrime local agent on port 9000 with BILL session-token login, refreshing the session on expiry.
• •Dedupe on voucher number and BILL entity IDs, with retries and a full audit trail on every record.

Questions

Which direction does data move between TallyPrime and BILL?

Supplier ledgers and Purchase vouchers move from TallyPrime into BILL as vendors and bills for payment, and settled payments flow back from BILL into TallyPrime as Payment vouchers against the original bill. Purchase orders stay in TallyPrime because BILL has no purchase order object. Only bills and payments cross between the two systems.

How does ml-connector reach TallyPrime if it is a desktop application?

TallyPrime's HTTP server on port 9000 is only reachable on the customer LAN, so ml-connector talks to it through a local agent installed on the customer network. The agent relays XML or JSON envelopes to port 9000 and returns the responses. There is no public cloud endpoint, so this local agent is required.

How are duplicate bills and payments prevented?

Neither TallyPrime nor BILL offers a native idempotency key, and a repeated Import Data call in TallyPrime creates a duplicate voucher. To prevent this, ml-connector tracks the TallyPrime voucher number and the BILL entity ID and checks them before writing, so a record that is read more than once is never booked twice.