Company

Because liability, tax and statutory reporting attach to a legal person, and software that cannot tell one legal person from another cannot produce filable accounts.

The company is the outermost container in the data model, and choosing how many you have is the first structural decision an implementation makes. Everything else nests inside it — registrations, warehouses, accounts, permissions — so getting it wrong is not a configuration error that gets tuned later, it is a foundation that everything above has to be rebuilt to change.

• Each company keeps its own complete set of books. A trial balance belongs to exactly one company.
• Transactions between two companies are real transactions, even under common ownership — they invoice each other and eliminate only on consolidation.
• A company holds one PAN. Its GST registrations are per state and hang beneath it, not beside it.

The count gets chosen for operational convenience rather than legal fact — usually more companies than there are entities, because separate books feel tidier than a shared one with dimensions. Then every internal movement becomes an inter-company transaction, month-end multiplies, and the tidiness costs more each period than the original decision saved once.

• Group structures where a holding company owns several trading entities and consolidation is a genuine requirement rather than a preference.
• The same trading name operating under two entities — customers see one brand, the books see two.
• Mid-year restructures, where transactions before and after belong to different entities and comparatives stop being comparable.
• Foreign subsidiaries, where functional and reporting currency differ and translation is a period-end process rather than a field.