Use case · Cost structure
Cost codes and work breakdown that hold up through the job
A cost structure that made sense at tender rarely survives contact with the job. Codes drift, Finance rows will not map, and cost that nobody can classify ends up in a balancing line that grows quietly all year.
Foras attributes cost as early as it reliably can, with an explicit place for cost whose attribution is not yet resolved.
Cost code 311 — Shoring
Position by WBS · Aug 2026 · Demo data
Parent cost code · Captured £1,426,700 · Finance £1,541,700 · orientation only, decisions are made on each leaf below.
| WBS element + Cost Item | Captured | Finance | Difference | Decision |
|---|---|---|---|---|
| 02.10 Retaining Walls | £812,400 | £927,400 | −£115,000 | Match Finance |
| 03.20 Bridge Abutments | £498,300 | £471,900 | £26,400 | Timing |
| Unassigned WBSFinance must be attributed to a WBS before Match Finance can be used. | £116,000 | £142,400 | −£26,400 | Timing |
Why this is hard in construction
The structure has to survive a job that keeps changing shape
Cost coding is treated as an administrative detail until the month the numbers stop reconciling. Then it turns out to be the thing everything else depended on.
The structure is set before the job is understood
Cost codes are agreed at tender, when the sequence, the subcontract packages and the site set-up are all still assumptions. Six months in, the work no longer maps neatly onto the codes it was priced against.
Finance and the project code differently
The ledger is structured for the business; the project structure is built for controlling the job. Where the two do not line up, comparison stops being possible at the level that matters.
Cost arrives before its classification is known
A plant charge, a delivery or an hour of labour is real long before anyone can say which element of the work it belongs to. If the system demands a code up front, people guess.
Every project ends up slightly bespoke
One project runs a deep work breakdown, the next runs cost codes only. That is often the right call locally, but it makes movement between projects hard to compare.
How it usually goes
A mapping tab, and a line called sundries
Many teams end up maintaining a translation between the project’s cost structure and the ledger’s. It starts as a small lookup and grows into a tab that only one person really understands, updated whenever a new code appears on a Finance export.
Alongside it sits the catch-all: sundries, general, or an unallocated line. Cost that could not be placed goes there because the alternative is holding up the report. It is rarely revisited, and by the end of the job it is large enough to matter to the margin.
The cost of this is not the admin time. It is that comparisons between months stop being trustworthy, because part of the movement is real and part of it is recoding.
£75,750 of recorded cost isn’t showing on a forecast line
- Plant · No Cost Item on the diary record£38,400
- Supply · No Cost Item on the diary record£12,750
- Subcontractor · No forecast line exists for this Cost Item yet£24,600
Actual Foras interface pattern. Entries are illustrative demo data from the Northgate Logistics Park demo project.
How Foras handles it
Attribute where it is known, keep the rest visible
Cost items are the backbone
Captured records — diary labour, plant, materials, subcontract, management cost — are attributed to a Cost Item where the classification is known. That is the level the position, the Finance comparison and the forecast all work at.
WBS and Work Items are optional
Where a project needs a finer breakdown, WBS elements and Work Items are configured for that project. They are optional and set up per project, not imposed on every job.
Unresolved attribution stays visible
Where the attribution is not yet known, the cost stays visible as Unassigned rather than being guessed at or pushed into a balancing line. It remains in cost to date and is surfaced for investigation, and it does not block capture.
The structure limits what a reconciliation can do
Reconciliation decisions depend on comparable attribution on both sides. Where Finance actuals carry no WBS attribution, the WBS-level difference cannot be matched directly and stays visible for review rather than being closed silently.
WBS elements and Work Items are configured per project and are not required. Where they are not in use, the cost item structure carries the position on its own.
What changes in practice
Through the life of the job
One structure, used everywhere
The codes used to capture on site are the codes used to compare with Finance and the codes the forecast lines sit on. There is no mapping layer to maintain.
Coding gaps are visible, not buried
Unassigned cost is a queue with a value attached, so the size of the coding problem is known rather than absorbed into a balancing line.
Depth where it earns its keep
Projects that need a work breakdown get one; projects that do not are not forced to carry the overhead of maintaining it.
Comparisons hold up over time
Because the structure stays stable through the job, period-to-period movement can be attributed to real change rather than to recoding.
Bring your cost code list and a Finance export
We’ll set up the same structure in Foras and show what maps cleanly, what does not, and how the gap is handled.
Who this matters to