TallyPrime and Airbase integration

What moves between them

The main flow runs from Airbase into TallyPrime. As bills clear their approval workflow in Airbase, ml-connector reads them and writes the matching Purchase vouchers into TallyPrime against the correct Sundry Creditors ledger, then records a Payment voucher once Airbase marks the bill paid. Vendor records move the same direction so each Airbase bill maps to an existing TallyPrime ledger, with vendors created or updated by ledger name. The chart of accounts and GL stay in TallyPrime, since Airbase GL accounts are read-only, so ml-connector does not write ledger definitions back into Airbase. Polling cadence is typically every five to fifteen minutes, paced to suit accounting work.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the Airbase bearer token in the Authorization header against the tenant base URL, and reaches TallyPrime only through the customer's local agent, which forwards XML or JSON envelopes to localhost:9000 because port 9000 is never exposed to the internet. Because a POST in Airbase does not mean a bill is approved or paid, it tracks the approval and payment_status fields and only writes a TallyPrime Purchase voucher once the bill clears approval, then posts a Payment voucher when the status moves to paid. Vendors are mapped first so every bill lands on a valid Sundry Creditors ledger, and master imports update by ledger name rather than duplicating. TallyPrime has no idempotency key and re-importing creates duplicate vouchers, so ml-connector dedupes on the Airbase bill id and a BullMQ jobId, and uses the Alter action by voucher tag when a change must update an existing voucher. All dates are converted to the strict YYYYMMDD format and the exact case-sensitive company name is set in SVCURRENTCOMPANY. Since TallyPrime sends no events, Airbase bills, payments, and vendors are read on a schedule rather than waiting for a push, while a registered webhook such as purchase_request_approved can act as an early trigger. Airbase publishes no rate limits, so ml-connector reads the Retry-After header on a 429 and applies conservative exponential backoff, and it tracks the manually rotated Airbase token so an expiry does not turn into a silent outage. A health check confirms the local agent is up and the target company is open before each run, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distribution business in India with roughly 150 employees keeps its books in TallyPrime and adopts Airbase to give department managers a self-service way to raise purchase requests and submit vendor bills. Before the integration, the accounts team rekeyed every approved Airbase bill into TallyPrime as a Purchase voucher and then entered each payment by hand after it cleared the bank, which slowed the monthly close and let vendor ledgers drift apart between the two systems. With TallyPrime and Airbase connected, each approved bill flows into TallyPrime as a Purchase voucher on the right Sundry Creditors ledger, the payment is recorded once Airbase marks it paid, and vendor ledgers stay aligned. The accounts team stops rekeying, and the supplier balances reconcile against both systems.

What you can do

• •Post approved Airbase bills into TallyPrime as Purchase vouchers against the right Sundry Creditors ledger.
• •Record a TallyPrime Payment voucher once Airbase marks a bill paid.
• •Keep vendor ledgers aligned so every Airbase bill maps to an existing TallyPrime ledger.
• •Bridge the Airbase portal bearer token to TallyPrime's local agent on port 9000.
• •Poll Airbase on a schedule with id and jobId dedup, Retry-After backoff, and a full audit trail on every record.

Questions

Which direction does data move between TallyPrime and Airbase?

The main flow is Airbase into TallyPrime. Approved bills, payments, and vendor records move from Airbase into TallyPrime as Purchase vouchers, Payment vouchers, and Sundry Creditors ledgers. GL accounts are read-only in Airbase because the accounting system is the source of truth, so ml-connector keeps the TallyPrime chart of accounts authoritative and does not write ledger definitions back into Airbase.

Why does TallyPrime need a local agent instead of a direct cloud connection?

TallyPrime is a desktop application whose HTTP server on port 9000 is only reachable on the local machine or LAN, and that port should never face the public internet. ml-connector therefore talks to a small local agent the customer runs next to TallyPrime, and the agent forwards XML or JSON envelopes to localhost:9000 and relays the responses. The agent also lets the health check confirm TallyPrime is running and the correct company is open before any voucher is written.

How does the integration avoid duplicate vouchers when TallyPrime has no idempotency key?

TallyPrime does not expose idempotency keys, and a repeated Import Data call would create a duplicate voucher. ml-connector dedupes on the Airbase bill id together with a BullMQ jobId so a re-read bill is not posted twice, and when an existing voucher must change it uses the Alter action by voucher tag rather than importing again. Vendor master imports are matched by ledger name, so a known vendor is updated rather than duplicated.