Which direction does data move between TallyPrime and Basware?

The main flow is Basware into TallyPrime. Approved invoices that Basware marks ready for transfer are written into TallyPrime as Purchase vouchers, while vendor and account master data moves from TallyPrime into Basware to keep coding accurate. Payment confirmations also flow back into Basware through its paymentResponses endpoint when a payment voucher is recorded in TallyPrime.

Why does TallyPrime need a local agent?

TallyPrime is a desktop application whose HTTP server on port 9000 is only reachable on the local machine or LAN, with no cloud endpoint. ml-connector reaches it through a local agent on the customer's network that forwards XML or JSON envelopes to port 9000. The agent must be running and the target company open in TallyPrime for any write to succeed.

How does the integration avoid creating duplicate invoices in TallyPrime?

TallyPrime offers no idempotency key and will create a duplicate voucher if the same import is sent twice. ml-connector tracks the voucher numbers it has already imported and uses TallyPrime's Alter action to update an existing voucher rather than re-import it. Basware also silently skips records identical to the last version it received, so unchanged data is not reprocessed.

TallyPrimeBasware

TallyPrime and Basware integration

TallyPrime is a desktop accounting and ERP system. Basware automates accounts payable in the cloud, from invoice receipt through coding, matching, and approval. Connecting the two means the invoices Basware finishes processing post into TallyPrime as Purchase vouchers automatically, and the vendor and account data TallyPrime owns keeps Basware's coding accurate. ml-connector handles the very different access models on each side, reading from Basware over REST and writing into TallyPrime through a local agent that fronts its port 9000 HTTP server.

How TallyPrime works

TallyPrime exposes its data through a local HTTP server on port 9000 that accepts XML or JSON envelopes over POST, not a hosted REST API. Every operation shares that single endpoint, with the envelope's TALLYREQUEST field set to Import Data for writes or Export Data for reads. All accounts, including vendors, are Ledgers grouped under a parent such as Sundry Creditors, and bills are Purchase vouchers. The server enforces no transport-level auth and pushes no events, so change detection is done by polling the Day Book on a date range, and a connector reaches it only through a local agent on the customer's network.

How Basware works

Basware exposes its P2P data through regional REST APIs over HTTPS, secured with OAuth2 client credentials that return a one-hour bearer token from a region-specific token endpoint. It reads accounting documents, purchase orders, vendors, and matching order lines, and imports vendors, accounts, and dimensions through dedicated POST endpoints. Pagination uses a continuation token passed as a request header. Basware pushes events such as AccountingDocuments and ExportedPurchaseOrders by webhook, each signed with HMAC-SHA256 in the X-BWAPI-Signature-256 header, and payment confirmations flow back into Basware through paymentResponses rather than out to a bank.

What moves between them

The main flow runs from Basware into TallyPrime. When Basware signals an accounting document is coded, approved, and waiting for transfer, ml-connector reads the invoice and writes it into TallyPrime as a Purchase voucher against the matching supplier ledger, with bill allocations preserved. Vendor and GL account master data moves the other direction, from TallyPrime ledgers and groups into Basware vendors and accounts, so coding panels reference real accounts. When a payment voucher is recorded in TallyPrime, ml-connector confirms it back to Basware through paymentResponses. Webhooks drive the inbound work, while TallyPrime is read by polling because it pushes no events.

How ml-connector handles it

ml-connector stores both credential sets encrypted and requests a fresh Basware OAuth2 token when one expires, since the client credentials flow has no refresh token, and it sends every call to the regional base URL the customer selects. TallyPrime is never reached directly from the cloud; requests pass through the local agent that forwards XML or JSON envelopes to port 9000, so the agent must be running and the target company open. Inbound Basware webhooks are verified against the HMAC-SHA256 signature in the X-BWAPI-Signature-256 header before any voucher is written, and the body is read as UTF-8 so Unicode coding text does not break the hash. Basware vendor codes map to TallyPrime ledger names under Sundry Creditors, and accounts map to ledgers under the matching group, so these masters are aligned first. TallyPrime has no idempotency key, so ml-connector tracks imported voucher numbers and uses the Alter action to update rather than re-import, preventing duplicate Purchase vouchers. Dates are converted to TallyPrime's strict YYYYMMDD format, and failed writes are retried with backoff and can be replayed.

A real-world example

A mid-sized distributor running TallyPrime for accounting receives several hundred supplier invoices a month and routes them through Basware for coding, three-way matching against purchase orders, and approval. Before the integration, once an invoice was approved in Basware an AP clerk re-keyed it into TallyPrime by hand, retyping the supplier, amount, and bill reference, which was slow and produced mismatched vendor names between the two systems. With TallyPrime and Basware connected, each approved invoice posts into TallyPrime as a Purchase voucher against the right ledger automatically, vendor master data stays consistent because TallyPrime feeds it to Basware, and the clerk reviews exceptions instead of typing every bill.

What you can do

Write coded and approved Basware invoices into TallyPrime as Purchase vouchers against the correct supplier ledger.
Push vendor and GL account master data from TallyPrime into Basware so coding panels reference valid accounts.
Confirm payment vouchers recorded in TallyPrime back to Basware through paymentResponses.
Reach TallyPrime's port 9000 through a local agent and verify Basware webhooks by HMAC-SHA256 before writing.
Prevent duplicate vouchers by tracking voucher numbers and using the Alter action instead of re-importing.

Questions

Which direction does data move between TallyPrime and Basware?: The main flow is Basware into TallyPrime. Approved invoices that Basware marks ready for transfer are written into TallyPrime as Purchase vouchers, while vendor and account master data moves from TallyPrime into Basware to keep coding accurate. Payment confirmations also flow back into Basware through its paymentResponses endpoint when a payment voucher is recorded in TallyPrime.
Why does TallyPrime need a local agent?: TallyPrime is a desktop application whose HTTP server on port 9000 is only reachable on the local machine or LAN, with no cloud endpoint. ml-connector reaches it through a local agent on the customer's network that forwards XML or JSON envelopes to port 9000. The agent must be running and the target company open in TallyPrime for any write to succeed.
How does the integration avoid creating duplicate invoices in TallyPrime?: TallyPrime offers no idempotency key and will create a duplicate voucher if the same import is sent twice. ml-connector tracks the voucher numbers it has already imported and uses TallyPrime's Alter action to update an existing voucher rather than re-import it. Basware also silently skips records identical to the last version it received, so unchanged data is not reprocessed.

Connect TallyPrime and Basware

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

Get started