The ledger balances, but no one knows what's in it

Earlier in my career, the only way I could obtain what the accountant regarded as a clean cost report was to have it printed. Several times a week, I would walk to the accounts department, collect another stack of paper and return to my desk to work out what had happened across my projects. The business had an accounting system full of transaction data, yet the most reliable way of passing it to the commercial team was to print it, carry it across the office and mark it up by hand.

The report itself appeared to have been designed for a dot matrix printer. Headings repeated across pages, descriptions ran over several lines, totals sat between groups of transactions and blank rows broke up anything that might otherwise have resembled a table. It was useful as a printed record, provided nobody wanted to filter, sort, compare or analyse it. When an Excel version eventually became available, it retained the same layout, so I wrote macros to flatten it into something that behaved vaguely like a dataset.

That should have been the end of the problem. It was only the start.

The standard report still did not show the full information entered by the accounts team. Descriptions, supplier details, project codes and transaction narratives sat across different parts of an old Sage database, while the default report selected only some of them. To obtain a proper view of each ledger item, I had to learn enough SQL to work through more than 3,000 tables and join the relevant fields together.

This is, apparently, part of quantity surveying now.

The system was not always missing the information. In many cases, it had simply stored it somewhere that the standard report did not display. An accountant could quite reasonably say that the description had been entered, while the commercial team could quite reasonably say that it was not there. Both were right. The information existed, but not in the report used to manage the project.

Some fields also had strict character limits, which meant that even a careful description could be cut short before reaching the useful part. “Supply of materials for…” was apparently enough. Where the materials were used, what they were for and which package they related to could be left to the reader’s imagination.

There is a comforting belief in construction that once a cost appears in Xero, SAP or another accounting system, it has become reliable data. The invoice has been received, the nominal code has been selected, the debit equals the credit and finance can close the month knowing that the ledger balances. The problem is that a balanced ledger may still tell the commercial team very little about what was bought, where it was used, when the cost arose or how it relates to the project budget.

That matters on any project, but it becomes acute under a cost-plus contract. The existence of an invoice does not, by itself, prove that a cost is reimbursable. The commercial team must understand what was supplied, which part of the works required it, whether it was reasonably incurred, whether it falls within the agreed cost categories and whether the contract allows payment. A description such as “materials as per invoice” answers none of those questions. It merely confirms that an invoice exists, which is fortunate, given that the entry came from the invoice.

The invoice has been processed. The problem has not.

Old software is only part of the issue. Poor accounting practice can remove useful information even where the system is capable of retaining it.

A supplier invoice may contain 20 separate items, including materials, delivery charges, consumables, equipment and work for several locations. Each line may need a different cost code, budget category, bill item or contractual treatment. When the accounts team is overloaded, however, the quickest approach is often to post the invoice as one line against one general heading.

The description becomes the supplier’s name, the invoice number or a phrase such as “site materials”. The total value is entered against one account and the separate lines disappear from the ledger. The invoice has been processed quickly, but the work required to understand it has merely been transferred to someone else.

Weeks or months later, the commercial team must retrieve the invoice, review each line, determine what every item relates to and manually divide the value across the correct cost headings. If the invoice lacks clear project references, someone must contact procurement, the site team or the person who raised the order. That person may not remember, may have left the project or may respond with the dependable construction answer of “check with site”.

The transaction has then passed through procurement, delivery, invoicing and payment without anyone creating a reliable commercial record of what it was for.

This is not a minor administrative weakness. It affects cost monitoring, cash flow, forecasting, audit and claims because the ledger is often treated as the official record of project cost, even where it records only the financial shell of the transaction.

Finance needs to know the supplier, invoice number, amount, tax treatment, nominal account and payment status. Commercial needs those details too, but it also needs the project, work order, package, activity, location, quantity, budget heading, reason for the cost, contractual status and period in which the resource was used. A transaction can therefore be financially correct while being commercially useless.

The ledger does not speak the language of the bill

The problem becomes worse when actual costs must be compared against a structured bill of quantities, method of measurement or work breakdown structure.

A bill of quantities may be arranged by section, trade, location, measured item and description. A work breakdown structure may divide the project by zone, asset, package, activity and control account. The estimate may separate labour, plant, materials and subcontract costs beneath each item.

The ledger may contain none of that structure. It may classify the same expenditure by supplier, nominal account and invoice number. Concrete may be posted as “materials”. Reinforcement may sit under the supplier’s name. A subcontract payment may appear as one lump sum even though it covers several bill items and locations. Labour may be posted by payroll cost centre rather than by activity or work package.

The commercial team is then expected to align one system of classification with another, usually after the event and often by hand.

This is not a simple coding task because the relationship between the ledger and the bill is rarely one-to-one. A single invoice may relate to several bill items, while one bill item may contain costs from many suppliers, labour records, plant invoices and subcontract valuations. In practical terms, this means mapping tables, manual allocations, repeated judgement and at least one spreadsheet formula that nobody is allowed to touch.

The same difficulty arises where work is measured under NRM2, CESMM4 or another standard. The ledger may show that money was spent on pipes, concrete or labour, but not whether the cost relates to excavation, bedding, jointing, testing, reinstatement or another measured obligation. Unless the cost coding structure was designed with the bill and work breakdown structure in mind, the commercial team must create a separate layer to connect ledger entries to cost codes, work packages and bill items.

That additional work is repeated every reporting cycle. The time spent cleaning, classifying and reallocating costs is rarely measured because it is treated as a normal part of commercial reporting. It is not. It is the repair of information that should have been structured properly when the cost entered the business.

The damage is not limited to the current project. Poorly classified historic data cannot be used properly for benchmarking, estimating or future cost planning. A business may hold years of financial records and still have little reliable evidence of what particular forms of work actually cost because the expenditure was never linked to the bill, the activity or the output.

The ledger is often two or three months behind the work

Even where the description and coding are correct, the date shown in the general ledger may bear little relation to the period in which the work was carried out.

Construction accounts teams are often two or three months behind in entering costs, although the delay does not always begin with finance. A supplier or subcontractor must first perform the work, then prepare and submit an invoice. The contractor must review the records, measure the work, resolve any differences and certify the amount before the invoice passes through internal approvals, posting, processing and payment.

By the time the cost appears in the ledger, the work may have been completed several months earlier. The date shown may reflect invoice receipt, certification, posting or payment, but not the period in which the labour, plant, staff or materials were actually used.

The system can tell you when the transaction entered the accounts. It may not tell you when the cost was incurred.

This distorts ordinary cost reporting. One month may appear unusually low because invoices have not yet arrived, while the next appears badly over budget because several months of expenditure have been posted together. The report then measures the speed of invoice processing rather than the performance of the project.

It also weakens any attempt to compare actual cost against measured progress. A work package may appear profitable when the quantity is completed, then deteriorate several months later when its supplier and subcontractor costs finally enter the ledger. Commercial teams often try to correct this through commitments, accruals and manual adjustments, but this means the useful project cost report is no longer the ledger. It is a separate commercial model built to repair timing and classification problems in the accounting data.

The same issue is often missed when preparing prolongation claims.

A delay analyst may identify a critical delay period from one date to another, after which the claims consultant is given the general ledger and asked to calculate the time-related indirect costs incurred during those months. In theory, the exercise is straightforward. The monthly indirect costs are identified, adjusted where required and apportioned to the period of delay.

In practice, the ledger may be reporting costs from a different period entirely.

An invoice posted in June may relate to work carried out in March. A staff cost paid in April may relate to the March payroll period. A plant invoice entered in August may cover equipment used in May and June. A subcontract payment may appear only after measurement, agreement, certification and payment, long after the work itself was performed.

If the claims consultant simply selects transactions by general ledger date, the amount claimed for the delay period may not represent the resources present during that period at all. It may represent costs from three months earlier.

This can create overstatement, but underclaiming is often the greater risk. Where a project was growing and staff, plant and site overhead costs were increasing during the critical delay, a ledger still reflecting earlier and lower expenditure may produce a prolongation claim based on the wrong cost level. The claim can be carefully prepared, properly presented and mathematically correct while still understating the actual costs incurred.

The arithmetic is not the problem. The dates are.

This is an underreported weakness in prolongation claims. Considerable attention is usually given to critical path analysis, legal entitlement and the period of delay, yet less attention is given to whether the accounting dates match the period in which the costs arose. A ledger date is not automatically a cost date.

The claims team should first establish what each date field means and whether the cost should instead be aligned by payroll period, timesheet, plant record, delivery date, subcontract valuation period, invoice service period or accrual. Where an invoice covers several months, it may need to be apportioned. Where staff or plant costs have been posted late, they may need to be moved back to the period in which the resource was present.

Without that work, the prolongation calculation risks becoming a tidy answer to the wrong question.

Commercial does need to understand accounts

None of this means that commercial staff should become accountants or database developers. It does mean that they need enough knowledge of accounting systems to understand what the ledger is showing, what it is not showing and what the dates and codes actually mean.

RICS includes accounting principles and procedures within quantity surveying training for good reason. A commercial manager should understand how costs are recognised, coded, accrued, posted and reported. They should be able to distinguish between a posting date and a cost period, identify where accruals are required and challenge a report that cannot be linked to the bill, budget or work carried out.

That is very different from having to search thousands of database tables merely to discover what the accounts team has already entered.

Finance also needs enough understanding of construction to recognise that a nominal code and invoice date are not enough for project control. Procurement needs to preserve the descriptions, quantities and classifications created when an order is placed. Estimating and planning teams need to establish structures that can continue beyond tender stage rather than disappear as soon as the project begins. Senior management and system providers need to understand that these are not local spreadsheet frustrations. They affect cash flow, cost reporting, claims, audit and the value of historic project data.

The answer is not for every department to learn every other department’s job. It is for each to understand what information the others require and to stop treating accounting, procurement and commercial records as separate worlds.

What the future should look like

The accounting sector is already moving towards automated invoice capture. Systems can read invoices, extract supplier details, dates and values, and create draft transactions. More useful tools can retain each invoice line rather than posting the document as one total.

For construction, the real value will come when those tools can do more than copy text from an invoice. An AI system could read each line, review the purchase order, identify the project and location, suggest the relevant cost code, compare the item with the budget and flag unsupported or unusual charges. It could also identify the service period and distinguish it from the invoice, posting and payment dates.

A plant invoice submitted in August could be recognised as relating to equipment used in May and June. A recurring staff or accommodation cost could be assigned to the correct period. An invoice covering several projects could be divided accordingly, while vague descriptions could be rejected before posting rather than accepted and passed down the line.

The more useful step would be to connect those costs to the project’s commercial structure. The system could suggest the bill section, method-of-measurement heading, work package, activity and cost code, while retaining a clear link to the invoice, order, delivery record and approval. Commercial staff could then review the proposed treatment rather than reconstruct it from scratch several months later.

That future is close enough to be taken seriously, but AI will not repair a business that has never decided how its costs should be classified. If project codes are inconsistent, budgets do not match procurement categories and nobody records where materials were used, the system will face the same confusion as the commercial team. It may simply process poor information faster.

The immediate answer is less dramatic than buying another software platform. Contractors should review what data is entered, what disappears from standard reports, whether invoice lines are retained, how ledger costs map to the bill and work breakdown structure, and which date is used for monthly reporting. Finance and commercial teams should agree the required fields before the project starts and test whether the reports actually contain them.

A well-run project should be able to trace a cost from the estimate and bill of quantities through the purchase order, delivery record, invoice, ledger, valuation and final cost report. It should be possible to see what was bought, where it was used, when the cost arose, which budget or bill item it relates to and why the contract permits payment.

Commercial staff should understand enough accounting to ask those questions. They should not need to learn SQL to obtain the answers.

A balanced ledger is necessary, but it is only the beginning. The useful record is the one that can be linked to the work, the budget and the period in which the cost arose. Construction can begin fixing that now by setting better coding rules, retaining invoice detail, aligning finance and commercial structures and making sure the accounting system reports the information already being entered.

AI may soon make much of this faster and less labour-intensive. It will not excuse a system that can provide a clean cost report only after somebody has printed it.