TallyPrime and Brex integration

What moves between them

Records move one way, from Brex into TallyPrime. Coded accounting records and settled card transactions become Payment or Journal vouchers in Tally against the ledger that matches the Brex GL account. Brex vendors are written into TallyPrime as Ledgers under the Sundry Creditors group. TallyPrime itself only exports on demand and pushes nothing, so the connector polls Brex for newly coded records on a short interval, or listens for the ACCOUNTING_RECORD_READY_FOR_EXPORT webhook where enabled, and applies writes to Tally as they arrive. Typical cadence is every few minutes for spend records and an hourly or daily pass for vendor reconciliation.

How ml-connector handles it

Authentication is bridged across two very different models. ml-connector holds the Brex bearer token or OAuth credentials and calls the Brex REST API directly, then hands the resulting writes to a local agent that the customer runs on the same machine or LAN as TallyPrime; that agent forwards XML or JSON envelopes to http://localhost:9000 and relays the response. The connector follows the Brex ERP pattern: it pulls each record from GET /v1/accounting/records, maps gl_account_id and accounting_fields to a Tally ledger name and accounting dimensions, imports the voucher, and then calls PUT to set export_status to EXPORTED so the same record is never posted twice. Because TallyPrime has no idempotency keys and a duplicate Import Data call creates a duplicate voucher, the connector tracks posted Brex record IDs and uses Tally's Alter action by TAGNAME and TAGVALUE for corrections rather than re-importing. Real gotchas: Brex merchant names rarely match Tally vendor ledger names, so a fuzzy match or mapping table is needed; the Tally company must be open or port 9000 returns errors; all Tally dates must be the strict YYYYMMDD format; Tally returns errors as text inside a LINEERROR block rather than HTTP codes, so the agent parses the body; and the Brex Expenses API limit was capped at 100 per page in Feb 2026, so paging must respect that. Brex rate limits return 429 and are retried with exponential backoff and jitter.

A real-world example

A 90-person engineering consultancy in India runs its books in TallyPrime and issues Brex corporate cards to its team for software, travel, and client expenses. Every month the finance team exports Brex statements and hand-keys dozens of card charges into Tally as payment vouchers, picking the right expense ledger each time and chasing receipts, which delays the month-end close. With this connection, each Brex transaction is coded once in Brex, then posted automatically into TallyPrime against the mapped ledger, and the matching vendor is created under Sundry Creditors. The finance team reconciles instead of typing, and the general ledger reflects card spend within minutes of Brex coding it.

What you can do

• •Post coded Brex card transactions into TallyPrime as Payment or Journal vouchers against the mapped ledger.
• •Map Brex GL accounts and accounting_fields dimensions to TallyPrime ledger and group names.
• •Mirror Brex vendors into TallyPrime as Sundry Creditors ledgers for aligned payables.
• •Mark each Brex accounting record EXPORTED after Tally accepts it to prevent duplicate vouchers.
• •Bridge the Brex bearer token to the on-premise local agent that reaches TallyPrime on port 9000.

Questions

Why does this integration need a local agent for TallyPrime?

TallyPrime is a desktop application whose HTTP server listens only on port 9000 of the local machine or LAN, and it is never meant to be exposed to the public internet. A cloud connector cannot reach that port directly, so a small agent runs on the customer side and forwards XML or JSON envelopes to http://localhost:9000. ml-connector calls Brex over its public REST API and routes the Tally writes through that agent.

How are duplicate vouchers prevented when Brex retries or re-sends data?

TallyPrime has no native idempotency key, so a repeated Import Data call would create a duplicate voucher. ml-connector tracks the Brex accounting record IDs it has already posted and marks each one EXPORTED in Brex once Tally accepts it. For corrections it uses Tally's Alter action by TAGNAME and TAGVALUE rather than importing the voucher again.

Does data flow both ways between TallyPrime and Brex?

No, the sync runs one way, from Brex into TallyPrime. TallyPrime exposes its card transactions and vendors as read and write, but TallyPrime is the system of record for the ledger and only the spend feed needs to move. Brex transactions are read-only at the source, so the connector reads coded records and writes the resulting vouchers and vendor ledgers into Tally.