Tally and custom software: how they work together

Tally is very good at what it was designed for: ledgers, GST, statutory reports and the balance sheet. Your accountant knows it, your CA expects it, and years of history sit in it. Replacing it with accounting inside a new ERP means retraining the people you trust most with your money, and it rarely makes the business run better.

Where Tally does not help is operations. It does not know which dealer is over their credit limit while the order is being taken, which batch is in which godown, which machine produced what, or which customer was promised a call back on Thursday. That is the job of an operations system: a CRM or ERP built around how your business actually works.

The operations system is used by the people doing the work, at the moment the work happens. Depending on your business, it records:

• Enquiries, quotations and orders, with the right price list and scheme for each customer or dealer.
• Stock by item, godown, batch and location, including transfers and physical counts.
• Purchase orders, goods received and quality checks against them.
• Production: material issued, output recorded, wastage and job work sent out and received back.
• Dispatch: challans, vehicle details and what was loaded against which order.
• Follow-ups, approvals and the owner's dashboard on a phone.

None of this needs to be in Tally line by line. What Tally needs is the financial result of it. If your dealers or customers order through a portal, those orders land in the same operations system and follow the same path to Tally.

When an operational event has a financial effect, the system turns it into a voucher and posts it to Tally. The exact list depends on your business, but it usually looks like this.

Masters, such as ledgers, stock items, units, godowns and tax rates, are agreed once at the start and kept in step. Many businesses let the system read masters from Tally, so a new ledger created by the accountant is available to sales staff without retyping.

Posting can be automatic, or held in a review queue the accountant approves each day. If Tally rejects a voucher, for example because a ledger is missing, the error comes back to the system with the reason, and nothing is silently lost.

Your accountant still opens Tally every morning, sees the same ledgers and files GST returns from it. The difference is that sales, purchase and receipt vouchers arrive already entered, so the job changes from typing to checking. Every posted voucher carries a reference back to the order or dispatch it came from, so a question from the CA can be traced to its source in seconds.

Entries that are purely accounting, such as expenses, bank reconciliation, payroll, depreciation and year-end adjustments, stay in Tally where they belong. This split is what lets a business go semi-digital first, moving one process at a time, without ever disturbing the books.

• Double entry. The system posts sales, but someone keeps entering them in Tally by hand out of habit. Decide one source for each voucher type, write it down, and stick to it.
• Mismatched masters. "Sharma Traders" in one place and "Sharma Traders Pvt Ltd" in the other, kilograms on one side and quintals on the other, an old GST rate on a stock item. Clean the masters before go-live, not after.
• Correcting in the wrong place. An invoice is edited in Tally but not in the system, and the two drift apart. Corrections should happen at the source and flow through.
• No opening position. Going live mid-year without agreeing opening stock and balances on both sides.
• No reconciliation report. Without a simple daily or weekly check that both sides agree, small differences grow into a year-end problem.

Whoever builds your system, ask these questions and expect written answers.

• Which voucher types will be posted, and which will stay manual in Tally?
• How are ledgers, stock items, units and godowns mapped, and who keeps them in step?
• Is posting automatic, or can our accountant review before it goes in?
• What happens when a voucher fails, and how will we know?
• Is there a report showing that the system and Tally agree?
• What happens to the integration when Tally is updated or moved to another computer?
• Who owns the code and the data, and can we export everything?
• Who looks after the connection after launch, and how quickly do they respond?

At Karyo, the Tally link is part of every CRM and ERP we build for businesses that use Tally, and it is looked after under our AMC once live. You can see how it fits a manufacturing plant or a distribution business on those pages.