Consolidate books across branches

A real estate broker running two project-specific entities under separate GSTINs in different states used to keep two entirely disconnected sets of books, checking each one individually just to get a sense of the business's overall cash position, because nothing tied the two views together anywhere. Getting a combined picture meant manually adding up two separate exports by hand every single time.

Multi-GSTIN branch consolidation lets each branch's GSTIN sit under one Khata account, with transactions recorded against the correct branch and a choice to view either a per-GSTIN ledger or a consolidated cross-branch view. Consolidation here is strictly a viewing convenience for the owner — each GSTIN's return-ready summary stays properly separated, so the CA can prepare, and the business can file, each registration's return independently and correctly, without confusion.

Consolidation exists purely for the owner's planning convenience, and it is scoped so that convenience never leaks into the compliance layer beneath it. A real estate broker running two entities under separate GSTINs benefits from a combined cash-position dashboard when deciding where to allocate resources — that's a legitimate operational view. But GST is filed per registration, not per business, and a combined dashboard view changes nothing about that, so each GSTIN's return-ready summary stays strictly separated regardless of which view is open.

The technical risk this capability is built to guard against is accidental cross-GSTIN data bleed — a poorly scoped query pulling a transaction into the wrong branch's summary would corrupt a return-ready figure for a registration it never belonged to. This is treated as serious because the failure mode is quiet: a summary that looks correct but contains a misattributed transaction wouldn't necessarily look wrong to the CA preparing it, until the mismatch surfaces later against supplier records.

Permission complexity adds a further layer worth planning for deliberately, particularly for a business where different CAs handle different branches. A real estate firm might reasonably engage one CA for a Mumbai project entity and another for a Bangalore one, and access needs to be scoped so each CA sees only the branch, or branches, they're actually engaged for — not the combined view the owner uses for planning, and not the other CA's branch. Getting this scoping right at setup avoids a CA seeing figures for a registration they have no actual engagement with.