Construction accounting policy
Construction WIP and revenue recognition: what BuilderOne does, and what it does not
Work in progress is where construction accounting and accounting policy meet, and where software vendors most often overclaim. This guide draws the line plainly: here is what the system records and posts, here is what it can report, and here is what your accountant still has to decide — because no ERP can decide it for them.
Last revised
Two questions that are often confused
“How does the system handle WIP?” is really two questions. The first is mechanical: what does the software record when a contractor is certified, when a unit is invoiced, when a period closes — and can it tell you, by project, what has been spent and what has been billed? The second is a matter of policy: should the cost of building units that have not yet been sold sit in the profit and loss or on the balance sheet, and when is revenue on a unit sold on instalments earned?
Software vendors tend to answer the second question by implying the first settles it. It does not. An ERP can make the policy easy to apply and impossible to apply inconsistently; it cannot choose the policy, because the choice depends on the company’s reporting framework, its auditors and the nature of each project. This guide keeps the two apart.
What BuilderOne records and posts
These are product facts, each of them a governed posting adapter into the general ledger:
| Event | Posting | Project on the line? |
|---|---|---|
| Contractor bill confirmed | Dr cost / expense account (default 5100 Cost of Sales) · Cr Accounts Payable, at the bill total | Yes |
| Retention held on that bill | Dr Accounts Payable · Cr Retention Payable | Yes |
| Contractor paid | Dr Accounts Payable · Cr Bank | Yes — settlement, not cost |
| Vendor bill accrued (Procurement) | Dr cost / expense · Cr Accounts Payable | Yes |
| Payroll run posted | Dr salary and contribution expense · Cr payables | Yes, by allocation |
| Instalment invoice issued (Project Selling) | Dr Accounts Receivable · Cr Sales Revenue (default 4100) | Yes |
| Instalment receipt | Dr Bank · Cr Accounts Receivable | Yes — cash, not revenue |
Two consequences follow directly. Construction cost reaches the ledger as an expense, in the period the bill is confirmed, attributed to the project. Sales revenue reaches the ledger when an instalment is invoiced, attributed to the project. Neither posting is deferred, capitalised or spread by the product.
What the product can therefore report
- A project profit and loss and a project balance sheet from the same ledger as the company statements, for any period — because every posting above carries the project.
- A project cost position by category: budget, contract commitment, cost incurred, cash paid and open commitment (see committed vs actual cost).
- Which project cost is backed by a posted ledger accrual and which is not yet, stated separately.
- Receivables and their ageing per project and per customer, and revenue invoiced per project.
- A certified project profit for a date range — the project’s ledger result, with a completeness status that says whether any lines are still unclassified.
All of this is “what happened, by project” — the raw material a WIP or revenue policy needs. None of it is the policy.
What BuilderOne does not do — stated plainly
| Mechanism | Status in BuilderOne | What that means in practice |
|---|---|---|
| Capitalising construction cost as a WIP asset | Not implemented. The contractor bill accrual requires an expense-class debit account; posting the accrual to an asset is deferred. | If your policy carries unsold units’ cost as inventory or WIP, the reclassification is a manual, project-attributed journal made by your accountant. |
| Percentage-of-completion or over-time revenue recognition | Not implemented. Revenue posts when an instalment is invoiced. | Any adjustment between invoiced and recognised revenue is a policy journal, not a system posting. |
| Deferring instalment revenue until handover or completion | Not implemented. | Same: a policy journal, if your framework requires it. |
| Cost-to-complete or estimate-at-completion | Not implemented. The product forecasts nothing. | The commitment figure is a fact from awarded contracts, not a projection. |
| Statement of compliance with IFRS / IAS or any national framework | Not claimed. | BuilderOne provides the project-dimensioned ledger the framework’s judgements are applied to; it does not certify that they have been applied correctly. |
Manual journals in BuilderOne carry the project on each line, and a line that names no project is recorded as unclassified — which then appears in the certified profit’s completeness status until someone decides where it belongs. So a policy journal is a first-class, attributed, auditable posting; it is simply one a person decides to make.
How an accountant applies policy on top of the mechanics
The pattern that works in practice has three parts, and each maps to something the product already does:
- Let the documents post as they are. Contractor bills to cost, invoices to revenue, all by project. Do not fight the operational postings — they are the audit trail of what actually happened, and the period close makes them stable.
- Take the project view at period end. The project profit and loss gives cost incurred and revenue invoiced; the cost position gives commitment; Project Selling gives units sold, unsold, and instalments invoiced against price. This is the information a WIP calculation or a revenue-recognition schedule needs.
- Post the policy as its own journal, attributed to the project, in the period it belongs to. A reclassification to WIP, a deferral of revenue, a provision for a loss-making project — each is a manual journal with the project on every line, reversible, and visible in the same statements as the operational postings it adjusts. When the period closes, it locks with them.
The result is a set of books where anyone can see two layers: what the operations did, and what accounting policy decided about it. Systems that fold the second into the first — by silently capitalising or spreading — make that separation impossible to audit later.
Where this lives in BuilderOne
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.