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.

Do this
- Connectors → Account map. Pick the legal entity and the target (Tally, Zoho, QuickBooks); *Seed the missing rows*, then *Save the map*. The map has a version and every batch records the version it was built under.
- The map — each PMS account, the ledger name it takes on the target and the group it sits under, whether it is in use, and whether the target has reported knowing it.
Export batches

- Connectors → Export batches.
- The batches — each leaves once, with its totals and hash, and carries what the other side wrote back: accepted, altered, refused.