Choosing a system
Moving from generic accounting software to a property ERP
General accounting software is good at what it is for: a ledger, invoices, payments, statements. A property business outgrows it not because the accounting is wrong but because everything that produces the accounting — units, agreements, contracts, tenancies, retention, owners — lives somewhere else. This is a category comparison, not a verdict on any product.
Last revised
Two categories, not two products
This guide compares kinds of software, not brands. A general accounting package — the category is large and its members are good at what they do — records financial events: an invoice, a bill, a payment, a journal, and the statements that summarise them. A property lifecycle ERP records those too, and also models the things that cause them: the project being built, the unit being sold, the agreement it was sold under, the contractor who built it, the tenancy that lets it and the owner it belongs to.
The difference is where the operational facts live. In the first category they live outside the software — in workbooks, in a booking system, in a property manager’s head — and the accounting entries are typed in afterwards. In the second, the operational document is the source of the accounting entry, and the entry cannot exist without it.
What changes when the operations move inside
| Event | General accounting software | Property lifecycle ERP |
|---|---|---|
| A contractor bill is certified | Someone enters a bill for the net amount; retention and advance recovery are worked out elsewhere. | The bill is certified against a contract; the gross cost, the retention hold and the advance recovery each post, attributed to the project. |
| A unit is sold on instalments | Invoices are keyed as they fall due, from a schedule kept in a workbook. | The executed agreement generates the schedule; invoices are issued from it; receipts allocate to them; the customer ledger and ageing follow. |
| Rent is collected for an owner | Rent income is recorded; the owner’s share is calculated at month end in a statement built by hand. | The receipt is recorded once; the owner’s account is derived from it and every other document, so the statement is a reading, not a composition. |
| “Did Project A make money?” | A workbook assembles the answer from several sources. | The project profit and loss is the company profit and loss filtered — same ledger, same periods. |
| An investor is paid a share of profit | A payment to a payee; the entitlement lives elsewhere. | A payout document against a position, from a certified project profit, posting equity against the bank. |
Read down the right-hand column and one thing repeats: nothing is typed twice. The operational document is the accounting source. That is the whole category difference, and everything else — the project dimension, the shared party record, the derived owner account — is a consequence of it. The platform page describes the three seams that make it hold together.
What does not change
- The accounting is still double-entry, still periodised, still closed. A property ERP with a real ledger at its core — as BuilderOne’s Accounting module is — does exactly what a good accounting package does, and its statements should be no less trustworthy.
- The accountant still decides policy. Capitalisation, revenue recognition and provisions are judgements; the ERP makes them easier to apply consistently and does not make them (see WIP and revenue recognition).
- Reconciliation still matters: bank to ledger, subledgers to control accounts, project statements to company statements. The difference is that a well-built ERP makes several of those reconcile by construction.
- Tax and statutory work is still the company’s and its advisers’. Country-specific rules may be modelled as configuration; compliance is not something software confers.
When the move is not worth it
The honest cases for staying with general accounting software are real, and it is better to name them than to pretend every property business needs an ERP:
- A single completed building let to a few tenants, with no construction, no instalment sales and no third-party owners — the operational model is small enough to live beside the ledger.
- A business whose operations are already run in a specialised tool it trusts, and whose only pain is re-keying. An integration may be cheaper than a migration, if the tool exposes its documents.
- An organisation not ready to give up spreadsheet flexibility. An ERP refuses things — a bill without a contract, a payout beyond a position, a posting into a closed period. That is the point, and it is also a change in how people work.
The signs it is time
- The month-end project report takes days and nobody trusts the result, including the person who built it.
- The same firm exists as a supplier in one place, a contractor in another and a payee in a third, and its real balance with you is in none of them.
- Retention, advances, deposits or owner balances are tracked outside the ledger and reconciled to it by hand — or not.
- Investors are paid from a spreadsheet, and the spreadsheet is the only record of what they are owed.
- A second project, a second company or a second country is coming, and the workbooks will not survive it.
If three of those describe you, the category has changed under you. Why BuilderOne sets out the argument in full; the migration order guide describes how the move is actually done; and the fastest way to judge it is to put a real project through the system — request access and we will set your company up.
See it on your own numbers
The fastest way to judge whether this is how your software should work is to put a real project through it. Tell us what you run and we will set your company up.