Construction accounting software: why generic books fail a builder, and what to do about it

Builders churn through accounting software more than almost any other trade, and it is not because the software is bad. Xero, QuickBooks, Sage and the rest are competent, mature products that do what they were built to do extremely well.

They were built to answer one question: how is the business doing?

A contractor needs the answer to a different question: how is job 214 doing, right now, and will it still be profitable when the last invoice goes out? Nothing in a general ledger is shaped to answer that, and every attempt to make it answer that is a workaround that somebody has to maintain by hand.

This page is what construction actually needs on top of ordinary bookkeeping, why the common workarounds break, and the four honest options — including the one that has only recently become realistic.

Start with the floor: what every accounting tool has

We maintain a hand-counted inventory of what accounting software ships, tallied across 37 real accounting tools. Ranked by how many of the 37 have each capability:

Capability	Tools	Share
Income and expense ledger	31	84%
Organisation setup and fiscal settings	30	81%
Financial reports — P&L, cash flow, aged debtors	30	81%
Invoice builder	29	78%
Customers and clients	28	76%
Payments received and allocation	28	76%
Document numbering and PDF templates	27	73%
Bank and cash accounts	26	70%
Dashboard that drills to source records	25	68%

Those 37 are general accounting tools, and that is the point of showing them here. This list is the floor, it is remarkably consistent across the market, and construction gets all of it from any mainstream product. Nothing below is a criticism of that core.

Everything a contractor needs beyond it sits outside that list — which is why it is missing, and why it is nobody's headline feature.

The six things construction needs that the core does not have

The requirements below are domain analysis rather than counted research — our inventory covers general accounting tools, not construction-specific ones. But they are the six that come up every time, and if you are evaluating anything, these are the questions.

1 · Job costing

The defining requirement. Every cost — labour hours, materials, plant hire, subcontractor invoices, and a share of overhead — coded to a job and to a cost category within that job. Without it you know the business made money this quarter and you have no idea which jobs made it and which quietly lost it.

The critical detail most workarounds miss: it has to work at the cost-category level, not just the job level. "Job 214 has spent £48,000" is barely useful. "Job 214 has spent 80% of its labour budget and 40% of its materials budget when it is 50% complete" tells you to go and look now, while you can still do something.

2 · Progress billing

You do not invoice a contract like a product. You invoice a percentage of a value, in stages, often against an application for payment that the client's surveyor then certifies at a different number from the one you submitted.

That gap — applied versus certified versus paid — is normal in this industry and generic invoicing has no concept of it. An invoice in a general ledger is raised, sent, and either paid or overdue. There is no state for "we asked for £40,000, they certified £34,500, and we are arguing about £5,500."

3 · Retentions

A slice of every certified payment — commonly a few percent — held back by the client, half released at practical completion and the rest at the end of the defects period, which can be a year later.

This is money you have earned, will probably receive, and cannot chase yet. In a general ledger it is either invoiced (so it shows as overdue debt that is not actually overdue, corrupting your aged debtor report) or not invoiced (so it is invisible, and small contractors routinely forget to claim it). Neither is right.

Unclaimed retention is one of the most common ways small builders quietly lose real money, and it happens because the system had nowhere to put it.

4 · Subcontractors and statutory deductions

Most jurisdictions have a scheme for deducting tax at source from subcontractor payments — CIS in the UK, 1099 reporting in the US, equivalents elsewhere. The rules differ, the returns differ, and the penalties for getting them wrong are real.

Generic accounting can record the payment. It usually cannot verify the subcontractor's status, apply the right deduction rate, produce the statements subcontractors are entitled to, or file the return. Local products exist precisely because this is jurisdictional, and it is one of the few areas where "buy something local" is the straightforwardly correct answer.

5 · Committed cost

You have raised a purchase order for £12,000 of materials. Nothing has been invoiced. Your accounts show the job has spent nothing on materials, and the job has, in every sense that matters, committed £12,000.

Committed cost — ordered but not yet invoiced — is the difference between a job report that tells you something is going wrong now and one that tells you six weeks later. Almost no general ledger carries it, because in ordinary trading it does not exist.

6 · Variations and change orders

The contract value is not fixed. Extras are agreed on site, sometimes verbally, and the total moves. A job costing system that cannot express "original contract £180,000, agreed variations £23,400, pending variations £8,000" cannot tell you your margin, because it does not know the denominator.

The pending column is the one that matters and the one that gets lost, because it is work already done that has not yet been agreed.

The seventh thing: cash flow, which is what actually kills builders

Everything above is about knowing whether a job is profitable. This one is about surviving a job that is.

Construction has a structural cash problem that almost no other trade has to this degree. You pay for materials on delivery or on 30-day supplier terms. You pay labour weekly. You pay subcontractors monthly. You get paid when an application is certified and the client's payment terms expire — commonly 30 to 60 days after the work was done, sometimes longer — and a few percent of that is withheld as retention for a year or more on top.

So a profitable job can still take you under, and a growing contractor is at more risk than a static one, because every new job funds itself out of the last one until the certificates start landing. This is why builders fail in good years.

The accounting consequence is that a profit-and-loss report is close to useless as an operational tool here. What a contractor needs is:

Cash flow forecast by job, from the payment schedule and the cost schedule — not from last month's bank statement.
Payment terms tracked per client, and actual payment behaviour tracked against them. Most contractors can name their slow payers but cannot show the average days-to-pay per client, and that number changes who you bid for.
Certified but unpaid as a distinct position from applied but uncertified. They have different probabilities and different chase actions, and lumping them into one debtor figure hides which one you have a problem with.
Retention release dates in the forecast, because they are real, dated, forecastable cash that most systems cannot see.

The practical test of any construction accounting setup: can it tell you what your bank balance will be in eight weeks, given the jobs you have? If it can only tell you what it was last month, it is doing bookkeeping rather than construction accounting — and the distinction is not academic, because the eight-week answer is the one that determines whether you take the next job.

Why the workarounds fail

Every contractor using generic software has arrived at one of these. They all work for a while.

Tracking jobs as projects, classes or tags. The standard advice, and genuinely the best of the workarounds. It gives you cost by job. It does not give you cost categories within a job in any usable form, it has no concept of committed cost, and it cannot represent a contract value that changes. You end up with accurate spend against an unknown budget.

Retention as a manual journal. Works, and depends entirely on somebody remembering to reverse it at practical completion and again after the defects period. That is a reminder living in one person's head across a two-year horizon.

A separate spreadsheet per job. Extremely common, and it fails the same way every parallel spreadsheet fails: the two never agree, and there is no way to tell which is wrong, because the connecting fact was never recorded in either. If you are here, the single highest-value change is to structure the spreadsheet so figures are derived from a transaction log rather than typed — we have written that up for stock in inventory management in Excel and the same rule applies to job costs.

A separate job-costing product alongside the accounts. The honest middle, and it works if the integration is real. Ask specifically whether costs flow automatically or whether somebody exports and imports monthly, because monthly is too slow to save a job.

The four routes

Generic accounting plus discipline. Correct for a small builder doing a handful of jobs a year with predictable margins. Use project tracking, keep the retention journal, and accept that job profitability is a monthly review rather than a live figure. Cheap, and enough for a lot of people.

Generic accounting plus a construction add-on. A dedicated job-costing layer that reads your accounts. Often the best value, and the integration is the thing to interrogate — direction, timing, and what happens when a cost is edited on one side.

Dedicated construction software. Right when you are large enough that job costing is the business process. It costs more, it takes real setup, and it is usually built by people who understand retentions. If your subcontractor deductions are complex, this is also where the jurisdictional handling is best.

Build it. Now a genuine option, with a specific catch.

If you build it

A coding agent will produce a working bookkeeping application in a couple of days. We have seven of them, built from a single accounting specification by three different models, and every one is a real double-entry system — chart of accounts, journal entries, trial balance, P&L, balance sheet, bank reconciliation.

That is the encouraging half. The instructive half is what the audits found, because none of it was a missing feature:

One would not finish building for production, and once hosted it sent people to the wrong addresses. Both problems appeared only when it left the machine it was written on.
One arrived completely empty — no transactions at all, so every ledger was blank on first open, which makes an accounting app impossible to evaluate.
One shipped with report tabs that were "coming soon" placeholders.
One was deliberately narrow and said so: no chart of accounts, no general ledger, no balance sheet, no reconciliation. Honest, and a long way from a complete set of books.

If you build for construction specifically, four things have to be in the specification before any code, because none of them will be inferred:

Job is a first-class dimension on every transaction, alongside the account. Not a tag, not a note. Retrofitting this means restating history.
Cost categories within a job, with budgets, because job-level totals are not actionable.
Retention is a state on a receivable, not a journal somebody remembers — with a due-date trigger for each release stage.
Committed cost is recorded when the order is raised, and released when the invoice arrives.

And the reporting that matters is not the P&L. It is one screen: per job, contract value including agreed and pending variations, cost to date by category, committed cost, percentage complete, and forecast final margin. If a build produces that screen and it reconciles to the ledger, everything else is ordinary bookkeeping.

The evaluation checklist

Take this into any demo, whether you are buying or reviewing a build:

Show me cost against budget for one job, broken down by category.
Now show me committed cost on that job. (Most demos stop here.)
Raise an application for £40,000 and certify it at £34,500. Where does the difference live?
Show me retention held across all jobs, and when each tranche becomes claimable.
Add a variation. Does the contract value and the forecast margin both move?
Show me a subcontractor payment with the statutory deduction applied, and the statement they receive.
Produce the aged debtor report. Confirm retention is not sitting in it as overdue.
Export everything. Ask what format, and whether it includes job coding.

Check seven is the one that catches most systems, and it is the one that matters to your cash flow, because a debtor report that is wrong is worse than no debtor report at all.

If your question is the bookkeeping rather than the job costing, accounting software in Excel covers the spreadsheet stage and where it ends. If you are a nonprofit rather than a contractor, the equivalent gap is fund accounting — nonprofit accounting software covers it.

And if you are building, the Accounting & Invoicing planner is the specification we hand our own agents — the counted core above written so an agent has to produce real double-entry books rather than an invoice screen with a total on it.