A chart of accounts for a property developer

What is different about a property developer’s books

A trading company’s chart of accounts is mostly about stock, sales and overhead. A property developer’s has to hold balances a trading company never sees: money paid to contractors before they have done the work, money withheld from contractors after they have, deposits that belong to tenants, rent collected that belongs to property owners, and capital that belongs to the investors in a particular project. Each of those is somebody else’s money passing through the business, and each needs an account that says so.

The other difference is dimension. A developer wants every one of those balances by project, and often by property or unit. That is not a reason to create a set of accounts per project — see why a project dimension beats accounts-per-project — but it does shape what the accounts themselves need to be.

The seeded chart, as an example

When a company is set up in BuilderOne’s Accounting module it receives a default chart: headers to group, posting accounts to post to, and control accounts that only governed postings may touch. Codes are four digits by convention; the structure is what matters.

Modules add their own accounts when first used — HR & Payroll seeds its payroll payable, Project Management its fee accounts — and every module’s posting adapter can be mapped to a different account than the default. The seeded codes are a shared contract: a code the template uses is one a module can rely on, which is also why a new account is added at a free code rather than a convenient one.

The balances that are not the business’s money

Four accounts in that chart exist because the business holds money for someone else, and the discipline of a developer’s books is keeping each of them clean:

The contractor billing guide walks the first two through a worked example; the owner statements guide covers how an owner’s balance is derived from six sources rather than stored.

Project cost: expense account plus project dimension

The seeded chart has no work-in-progress asset account, and that is a deliberate starting position rather than an oversight. A certified contractor bill posts its debit to a cost-of-sales or expense account — 5100 by default — carrying the project on every line. The project’s accumulated cost is therefore a question the ledger answers by dimension (cost of sales, filtered to Project A) rather than by account (a “WIP — Project A” balance).

Whether that cost should instead be carried as an asset until units are sold is an accounting-policy decision, and one the chart can accommodate: add a WIP account under current assets and post to it through a manual journal. What the product will not do is make that decision for you — see what BuilderOne does and does not do about WIP.

Designing your own: five rules

1. Separate control accounts from posting accounts. Receivables, payables and investor equity should only ever be moved by the documents that own them; a manual journal to a control account is a reconciliation break waiting to happen. BuilderOne restricts ungoverned manual posting to control accounts for exactly this reason.
2. One account per kind of obligation, not per counterparty. “Retention Payable — ABC Contractors” multiplies with every contract; one Retention Payable account with the contractor on the document does not.
3. Put projects, properties and departments on the line, not in the code. Dimensions filter; accounts classify. Mixing them is how a chart reaches four hundred accounts nobody can map to a statement.
4. Give migration its own equity account. Opening balances loaded at cutover need a balancing side that is obviously transitional — Opening Balance Equity — so it can be cleared, not hidden in retained earnings.
5. Keep the seeded codes stable. Module defaults, report mappings and other companies in the same system depend on them; add new accounts at free codes and remap a module rather than renumbering.