One builder, many companies, one set of records

A developer of any age is not one company.

There is usually a company per project. There is a contracting arm that builds for the project companies. There is an entity holding land, often older than the rest. There is a partnership left over from a joint development done years ago with a family who still hold a share. Occasionally there is a company that exists because a lender asked for it.

This is the ordinary shape of the business, and each entity is there for a reason.

• Ring-fencing a project. A scheme's liabilities stay with the scheme. If one goes wrong the others are not dragged into it.
• Land arrangements. The landowner contributes land and takes a share. He will not put his land into a company that also carries somebody else's construction risk.
• Different partners per project. The investor in one tower is not the investor in the next. Separate entities let the economics stay separate.
• Lender requirements. A lender funding one project wants a borrower whose cash flows he can see, not commingled with four other schemes.

Each of these is sound. Together they produce an operating problem nobody signs up for deliberately: the business is one organisation and the records are several, and the seams show everywhere.

Where the seams leak#

Staff who work across entities. The site engineer covers two projects. The accountant covers all of them. The purchase manager buys for whoever is building. Salary sits on whichever entity was convenient at the time of joining, and time is booked nowhere at all. At year end somebody allocates by feel and calls it a policy.

Material bought on one and consumed on another. A lorry of steel ordered by the entity with the credit line, unloaded at the site that needed it. The GRN is written at the receiving site, the invoice reaches the buying entity, and the two records sit in different books with no line joining them.

One purchase order covering two projects. Cheaper per tonne, obviously. It is also a document that cannot be matched cleanly against either set of books, and three-way matching breaks on it in the ordinary way — one order, several receivers, several ledgers.

Inter-company balances nobody reconciles. Entity A has paid things for entity B for three years. A's books show a receivable, B's show a payable, and the two figures have never agreed. Nobody reconciles them because there is no counterparty pushing. Both sides are you, and neither side chases itself.

One account paying another entity's vendor. The money was in the wrong place on the day, so the payment went from wherever it could. It records as an expense in the paying entity, and the correction, if it comes at all, comes months later as a journal nobody can trace back to the bank line. It makes matching a bank line impossible in exactly the case where matching would have told you something.

One WhatsApp group for three legal persons. Approvals, rates and instructions spanning separate legal entities in a single thread, with no marker of which company any given message binds. When somebody later asks who agreed what on behalf of whom, the thread cannot answer, and the hisaab that follows is settled by whoever remembers it more confidently.

The discipline that holds#

Three habits. All cheap if adopted early and expensive if adopted late.

The entity is a field on the transaction, not a folder it lives in. Every voucher, order, receipt, bill and payment carries the entity it belongs to as data, chosen at entry by the person who knows, and it cannot be left blank. If the entity is decided later by whoever is doing the books, then it was decided by convenience, and every report by entity is a report of somebody's convenience.

Once it is a field it composes with everything else. Entity plus project plus cost head answers the questions you actually get asked, which is part of why cost heads that survive a project matter more than the chart of accounts does.

A transfer between entities is documented as a transfer. Not as an expense in one and silence in the other. Two entries, one document, one reference, each side naming the other. If it is a loan, it says loan. If it is a supply, there is a supply document. If it is a reimbursement, the underlying cost is identified.

The test is plain: can somebody who was not present tell, from the record alone, why money moved between two companies you own? If the answer is "they would have to ask", it is not documented.

Shared costs have a stated basis, decided in advance. Head office salary, a shared consultant, insurance covering several sites, a vehicle. Write down how it is split and why — area, value, headcount, whatever suits — and write it down before the period it describes, not during the review that questions it.

An allocation basis decided in advance and applied consistently is a policy. The same basis decided at year end is a result, and it reads like one to everybody who comes later.

Why the history matters more here#

With one company, an amended entry is an amended entry. With several, an amended entry may have moved a cost between two legal persons, and the question when did this become entity B's cost, and who decided that? has a real answer somebody may need.

Records that are added to rather than overwritten — append-only records — carry that answer at no extra cost. So does the habit behind what an audit trail is for: holding not only the current state but the sequence that produced it, and the person who produced it.

How the structure should be set up, and the rules that govern dealings between related entities, are matters for your own advisors, and they change. Verify the version in force with them rather than settling it from general reading. What does not change is the operating point below the legal one: the structure is a fact of the business, and the records have to be kept in a way that survives it.

The short version#

Several entities is the normal shape of an Indian developer, and each one exists for a reason. The cost is operational, and it lands on staff time, shared material, common orders and money moving between accounts.

Make the entity a required field at the point of entry. Document transfers as transfers, with both sides referring to each other. Fix the basis for shared costs before the period rather than after it.