The week that breaks every group finance team
Walk into the head office of a typical Indian real estate developer, an auto-component group with three plants, or a pharma distributor with a CFA arm in five states. You will almost always find the same setup: each entity, each SPV, each state warehouse runs its own Tally company. Often 5 to 15 companies in total. Each one has its own ledgers, its own voucher numbering, its own GSTIN.
The first week of every month is the consolidation week. One accountant per entity exports the trial balance, the day book, and the outstanding statement to Excel. A senior person on the group finance team copies all of it into a master workbook, maps the chart of accounts by hand, eliminates the obvious intercompany lines, and tries to send the consolidated MIS to the promoter by Saturday. By Monday morning the file is already stale, because two SPVs booked weekend invoices and one entity reversed an entry.
This is where the AI question comes up. Can a system read every Tally company in place, maintain a stable chart-of-accounts map, and answer consolidated questions live without breaking the audit trail. The honest answer is yes, with a few caveats worth knowing before you commit.
Why Indian groups run separate Tally companies
Before talking about consolidation, it helps to remember why the data is split in the first place. Indian groups almost never run one Tally company across the group, and the reasons are structural, not lazy.
- Each legal entity needs its own books. Private limited, LLP, partnership, proprietorship, each one files its own ROC and income tax return. Mixing them in one Tally company is a statutory mess.
- Each GSTIN needs its own data. GSTR-1, GSTR-3B, and the new GSTR-2B reconciliation all run per GSTIN. State branches and SPVs each need clean, separable Tally data.
- RERA and project-level reporting. Real estate groups carve every project into an SPV for RERA compliance. Each project is a separate Tally company with its own escrow and customer ledger.
- Internal control. Splitting books across companies is also how Indian groups limit which accountant can see which entity. One Tally company means one set of permissions.
So the problem to solve is not "merge the Tally companies." That is neither legal nor wise. The problem is to read across them without staging the data into yet another system.
What manual consolidation actually involves
People who have not done it underestimate the work. A clean monthly consolidation for an 8-entity Indian group involves four distinct jobs, every one of them error-prone.
- Chart-of-accounts mapping. Entity A calls the head office rent line 'Office Rent', entity B calls it 'Rent - Admin', entity C has a sub-ledger under 'Indirect Expenses'. Someone has to maintain a master mapping that survives month after month.
- Currency and unit normalisation. Even within India, one entity may post in lakhs, another in crores, and a CFA branch may report kilograms while head office reports tonnes. Quiet bugs hide here.
- Intercompany eliminations. Entity A sells to entity B. Entity B records the purchase. The group P&L should show neither. Missing one elimination inflates revenue and cost in the same direction. The CFO notices when the net does not tie.
- Currency of period. Some entities close on the 28th, some on the last day. Some book GST liability on the date of invoice, others on the date of e-invoice acknowledgement. A consolidator who is not careful ends up double-counting at the join.
How AI reads multiple Tally companies in parallel
The connector model is straightforward in description and a fair amount of work in execution. A small read-only agent sits on each Tally machine (or one shared machine that sees every company on the LAN), exposes the standard Tally ODBC interface per company, and a central service maintains a unified schema on top.
| Layer | What it does | Where it runs |
|---|---|---|
| Tally agent | Reads each Tally company live, no extracts. | On the Tally LAN, inside your boundary. |
| Mapping layer | Holds the master chart-of-accounts map and entity metadata. | Single-tenant, customer-owned config. |
| Query engine | Translates a plain question into per-company queries, joins the results. | Single-tenant cloud or on-prem. |
| Audit log | Records every question, query, and source voucher ID returned. | Customer-owned, exportable to S3 / SFTP. |
The important property: data never leaves the Tally machines except as the answer to a specific question. KolossusAI for Tally users does not stage your full ledger anywhere. Each query reads live, the result is logged, and the underlying voucher IDs per company are kept for drill-down.
Intercompany transactions and eliminations
The other discipline. Intercompany sales, intercompany loans, intercompany rent, and intercompany allocations all need to be identified and eliminated at the consolidated layer. AI helps here because it can spot pairs (entity A's sale to entity B matched against entity B's purchase from entity A) faster than a human can scroll, but the rules still need a human to set up the first time.
A sane policy: tag every intercompany ledger across every Tally company with a consistent prefix (something like 'IC-Sales-A-to-B'). The AI then proposes eliminations, the group controller approves, and the consolidated P&L shows the eliminated lines on a separate worksheet for the auditor. The audit trail stays intact: the source vouchers in each Tally company are unchanged, and the elimination is a derived view on top.
A real example - 8 SPVs, one promoter
Take a concrete shape. A Pune-based real estate group running 8 active SPVs across two states, group revenue of about ₹85 crore for the year, group finance team of 6 people including the controller. Before AI: month-end consolidation was a 6-day job for two senior accountants and the controller, signed off on the 8th of every month. After: the same consolidated MIS is available on the 1st, intraday, with drill-down.
The promoter's biggest gain was not the time saved. It was that the group MIS was finally trustable on day 1 of the month, with every consolidated line one click away from the source voucher in the relevant SPV's Tally company.
Manual vs AI-assisted consolidation
| Manual / Excel | AI on top of Tally | |
|---|---|---|
| Time to consolidated MIS | 5 to 8 days | Live, day 1 of month |
| Senior staff time per month | 100 to 160 hours | 8 to 15 hours of review |
| Drill-down to source voucher | Manual, slow, sometimes impossible | One click from any consolidated line |
| Intercompany eliminations | Easy to miss, hard to audit | Proposed by system, approved by controller |
| Audit trail for the auditor | The Excel master, often un-versioned | Every query logged with source voucher IDs |
| When a new SPV is added | New tab, new mapping, new bugs | Add the company, update the map once |
What this costs in year one
The flat quote matters more for multi-company than for single entity, because per-query pricing penalises the exact thing you want to do: ask many small consolidated questions through the month. See our pricing for how the POC and the year-one quote are shaped.