Any business software that touches money eventually meets the question of how data reaches the accounting system. In India that usually means Tally, and increasingly also cloud packages such as Zoho Books, or an ERP for larger organisations. The integration effort varies enormously between them.
Cloud packages are the straightforward case. They offer documented REST APIs, OAuth authentication and webhooks, and integration is ordinary API work. The main considerations are rate limits and how the package models entities you care about — a customer in your system may map to a contact, an account or both.
Desktop Tally is a different exercise. It exposes an XML interface over HTTP, which works well but requires the application to be running and reachable, which usually means a machine in the client's office rather than a cloud service. Many integrations end up as a small connector installed alongside Tally, pushing and pulling on a schedule.
Master data mapping causes more problems than the transport. Your product's customer list and the accounting system's ledger list were created independently and will not match. Names differ, duplicates exist, and some entities exist in one system only. Building an explicit mapping table with a human review step is slower to start and far more reliable than matching on name.
Decide what is authoritative for each entity and do not compromise. If the accounting system owns the customer master, your product should not create customers directly. Bidirectional synchronisation without a clear owner produces conflicts that are extremely difficult to reason about after the fact.
Never post to accounts silently. Finance teams need a review step, and an integration that writes entries automatically will be switched off the first time it posts something wrong. A queue of proposed entries with a person approving them is both safer and far more likely to survive.
