Construction: cost, progress, and margin by project
The standard for monitoring each project closely: cost, physical progress against finance and margin, combining project ERP, budget and shopping.
- See typical construction company sources
- Model cost and progress per project
- Have an end-to-end implementation checklist
In a construction company, each project is practically a company within the company. company: it has its budget, its costs, its schedule and its margin. And the data that decides whether the project makes a profit or a loss is born scattered: the cost realized is in the project ERP, the budget in a spreadsheet or separate system, the purchases of material in supplies, and the advancement physical in the project log and in field measurements. Every system counts a piece of the same project, and none alone answers the question that the director does every week: Is this project in the blue or is it bursting? This playbook shows the pattern that Nekt uses to put together cost, advance and margin per project in a single model and consumable.
1. Context: what a construction company needs to measure per project
A handful of metrics guide practically every decision on a project. They answer different questions, but rely on the same cost base and well-modeled progress, always with the project as the unit of analysis.
- Cost realized against budget: how much has already been spent of truth in each project, compared to what was foreseen in the budget. It's the number the director looks at first, and the basis of almost everyone else.
- Physical advancement: how much of the project was actually carried out (foundation ready, structure on the fifth floor, 30% finishing). Come measurements and project diary, not the money spent.
- Financial advancement: how much of the budget has already been consumed. It's the money, not the physical project. The comparison between the Two Advances is the heart of this playbook.
- Budget deviation: the difference between the cost carried out and budgeted for the same point in the project. It's the leak bucket, and it needs to appear early, before becoming a complete loss.
- Margin per project: how much is left between the value contracted for the project and the total projected cost. This is what it says if the project, In the end, it will make a profit.
- Cash flow per project: the mismatch between what comes in (measurements, receivables) and what goes out (purchases, payroll, services) over time, project by project.
Each points to a different lever: realized cost measures the spent, physical progress measures execution, deviation measures risk, margin connects everything to profit. The central point of the sector is that the data is born spread across project and system, and the consolidated vision per project, one that combines cost, advancement and margin in a single line, that's exactly what's missing. It is this project that modeling at Nekt solves it.
2. Typical sources for a construction company
Most construction companies have data divided between the construction ERP, the budget, purchases and field records. Each source delivers a piece, and the value appears when they come together in a modeled layer per project. They all enter raw Bronze.
- Construction management ERP (e.g. Sienge, UAU). The source the truth about the cost realized: appropriation of costs per project, cost center, invoices, contracts and financial measurements. It is the heart of the cost model.
- Budget (spreadsheet or budgeting system). O predicted: how much each step and input should cost. It's half of deviation account, without it there is no "realized against budget".
- Shopping and supplies. Material input: orders, quotations, material notes, steel, concrete, finishing. It details the cost of materials that the ERP sometimes only shows consolidated.
- Measurements and project diary. The physical advancement of truth: what was carried out on the field, step by step. It's the source that separates physical advancement from financial advancement.
- Labor sheet and notes. The cost of personnel allocated per project: hours, teams, contractors. One part large part of the cost that needs to be apportioned or allocated per project.
- Contracts with suppliers. Outsourced services and projects: contracted value, service measurements, outstanding balance execute. Closes the cost of services for the project.
ERP for construction, purchasing and payroll usually have overlapping information about cost. Define from the beginning what the source of truth for each field: normally the ERP mandates appropriate cost and financial measurements, purchases dictate the material details, and the sheet dictates the labor cost project. Documenting this avoids counting the same cost twice at the time to consolidate.
3. Modeling recommended at Gold
The objective is to create a table by project and period (month) in the layer Gold: one line per job and month, already budgeted, carried out, physical advancement, financial advancement, deviation and margin together. To arrive In it, you consolidate costs of materials, labor and services in a single basis per project. The raw sources of ERP, budget and purchases go into Bronze, the cleaning of costs and measurements takes place in Silver, and the panel per project and period (the table we describe below) lives in the Gold.
- Appropriation of construction ERP costs
- Budget, purchases, sheet, measurements
- As it came, unedited
- Values and dates still as text
- Typed values, truth dates
- Cost per project, stage and accrual period
- Standardized field measurements
- Source of truth defined by field
- One line per job and month
- Budgeted, carried out, progress and deviation
- Projected margin per project
- This is where dashboard and MCP read from
Why a table per project and period
The temptation is to leave everything out in the open: the cost in an ERP report, the
budget in a spreadsheet, progress in a field diary, and ask
who consumes cross in hand every week. This is exactly what stops the
sector. A table with one line per job and month, with the
budgeted, what was accomplished, the two advances, the deviation and the margin already
resolved in-house, leaves most questions to a
GROUP BY away. The dashboard adds and compares directly,
without manual crossing. And the AI agent, which makes the mistake of chaining together several
sources, you get it right when reading a flat, well-described table. A modeling,
two easy consumptions.
One line per project and month, with what was planned, what was accomplished, both advances, deviation and margin already resolved:
| project | period | orcado | carried out | avanco_fisico | advance_finance | deviation | margin |
|---|---|---|---|---|---|---|---|
| Aurora Residential | 2026-01 | R$ 1,200,000 | R$ 1,150,000 | 32% | 30% | -R$50,000 | 18% |
| Aurora Residential | 2026-02 | R$900,000 | R$ 1,020,000 | 42% | 52% | +R$ 120,000 | 14% |
| North Industrial Warehouse | 2026-01 | R$640,000 | R$610,000 | 55% | 50% | -R$30,000 | 22% |
| North Industrial Warehouse | 2026-02 | R$500,000 | R$495,000 | 78% | 76% | -R$5,000 | 21% |
Comparing avanco_fisico with
avanco_financeiro in the same line, you see it right away
when the project is spending faster than it is executed (in the
For example, Aurora in February: 42% of project done for 52% of
money spent, with positive deviation, overflow signal). Adding the
desvio per project, you have the risk chart of the
entire portfolio. Illustrative values, not real data.
You don't need to write each transformation by hand. Nekt's MCP creates the queries and notebooks of the transformations to from natural language. Order "consolidate material cost, labor and services on a single per-job basis" or "set up a Gold per project and month with budget, carried out, progress and deviation" and it generates the transformation. This speeds up a LOT to assemble Bronze, Silver and Gold in one construction company, where the cost comes from many sources: you describe what want, review, and adjust, rather than writing each join from scratch.
4. Traps
Three pitfalls appear in almost every data project. construction company. They don't break the pipeline, what's worse: they deliver plausible numbers, but wrong, and hide bursts until it's too late. It's worth knowing all three before modeling.
This is the most expensive mistake in the industry. Spend 50% of the budget doesn't mean that 50% of the project is ready. A project may have consumed half the money having executed only 35% of the structure, and that difference is exactly where the overflow hides. If the modeling mixes the two advances, or reports only the financial (which is the easiest to calculate, because it comes directly from the cost), the project it seems to be going well while in reality it is late and expensive. Model the two advances in separate columns: the physical coming from measurements and from the project diary, the financial one coming from the cost against budget. It's the comparison between them that gives early warning.
The same cost appears at two different times: when the service is executed or the note is issued (accrual basis) and when the money effectively leaves (cash). A material note released in January It can only be paid in March. If modeling mixes the two regimes, the cost of the project in a month is wrong, the deviation gives a false positive and the cash flow doesn't add up. Decide explicitly which regime each analysis uses: the cost realized against budget is usually accrual period, the cash flow per project is per cash. Make it clear in modeling and documented in the Semantic Layer.
Indirect costs (central administration, engineer who runs three projects, shared equipment, common site) do not belong to a single project. If you throw them all into a project, it looks blown out and the others seem too profitable. If you ignore them, the margin of every project becomes inflated. Define a explicit apportionment rule (e.g. proportional to the direct cost of each project, or to the built area) and apply consistently. There is no perfect apportionment, there is apportionment that the company combines and uses the same in all projects, so that the margin between them is comparable.
5. Use case: per-project dashboard + AI agent
With the table by project and period in Gold, two consumptions appear almost for free on the same model.
One dashboard per project read straight from the table: the S curve of advancement (the physical and financial plotted together over the months, which instantly shows when the money line takes off from the money line project), the accumulated budget deviation, the projected margin, and the flow cash per job. The director opens the entire portfolio and sees at a glance which projects are green and which need attention this week.
An AI agent, via MCP, answers questions in natural language on the same table: "which projects are popping the budget", "what is the projected margin of the Residencial Aurora project", "which project has the greatest disconnect between physical and financial progress". Instead of waiting for the controller to assemble the spreadsheet, whoever needs the answer the question and receive the number instantly.
What makes the agent trustworthy is the Semantic Layer describing the table: what is each column, that physical advancement comes from measurement and financial comes from cost, which regime (accrual or cash) each value uses, what is the apportionment of indirect costs. Without this description, the AI guesses and gets it wrong. With it, the AI responds with the same rules that the dashboard uses, and both they beat. One model, two consumptions that never contradict each other.
A construction company carried out seven projects at the same time, with the cost site ERP, the budget in spreadsheets per site and purchases in supplies. Monitoring was a report that the controller rode in the hand every Friday, always late, and only showed the financial advancement. A project went over budget without no one noticed, because the money spent seemed to follow the schedule. By consolidating the cost of material, labor and services on a single per-job basis in the Silver, and set up a Gold per project and month separating physical advancement of finance with an indirect apportionment rule defined, the detachment started to stand out. On top of same layer, they plugged in a dashboard with the S curve per project and a agent who responds to which projects are going over budget in the day to day.
6. Implementation checklist
The end-to-end path, in the order that usually makes sense. Each step is based on the previous one, so it's worth following it from top to bottom.