Connectors — a batch leaves the books once, and says where it went
Map the chart to the other system's ledgers, build a batch of journals for a period with control totals and a hash, send it (Tally bridge, Zoho, QuickBooks, a file), read back what the other side said; issue keys for systems that post into the books, and read the rejection queue.
Menu → Ledger → Connectors. The mapping is our account against their ledger, one table per target, seeded from the chart's Tally names; the bridge and the connectors pull the other side's list so a name that matches takes its id, and what does not match is yours to pick. A batch is the journals of a period for one target: how many, the debits and credits (equal, always), a hash of the content, the mapping version it used. Build it, send it, and the other side writes back — *accepted* with the ids it gave every journal, or *rejected* with its words. A journal on a live batch is not put in another for the same target; re-send supersedes the batch and sends the same journals with the same ids, so the other side alters rather than duplicates. Inbound: a spa, club or third-party POS posts events through an integration key (shown once). Each event is kept whole, must balance and name accounts the chart has, and is applied as one journal with the source's reference on it; what does not pass sits in the rejection queue with the reason, to retry once the source has fixed it.