Custom construction data analytics
On a construction project, reality runs ahead of the paperwork. The work is further along than the system shows, subcontractor invoices arrive after the fact, and variations are agreed on site before they are recorded anywhere. Anyone looking at their dashboard is looking at the past. Appfront builds analytics systems that bring planning, the works budget, hours, purchase commitments and invoicing onto a common basis, so that a deviation becomes visible while something can still be done about it.
What it is, and what this page covers
Construction data analytics brings together the data that a project generates in separate systems: estimating and the works budget, planning, time recording, purchase orders and call-offs, subcontractor invoices, and the progress statement to the client. Each system is correct within its own boundaries. A usable picture only emerges once they are set against a shared basis and the same reporting date.
If you mainly need data to flow between two systems, for example from project administration into accounting, a Bouw7 integration is the quicker route. If you want to forecast which work is at risk of running over, that belongs to a predictive analytics dashboard. Construction data analytics comes before both: first you need a clear view of what is happening now, otherwise a forecast has nothing to rest on.
Designed for directors, project managers and controllers at main contractors, installers, infrastructure firms and developers who run several projects at once.
Where does this project stand today?
Realised costs are only known up to the last processed invoice, and progress only up to the last weekly report. Those reporting dates can be weeks apart, and the margin you are discussing sits in between.
Why did this project turn out better?
After handover, project A proves more profitable than B. As long as both record their costs differently, the answer is a reconstruction from the memories of those involved.
Do our estimating norms still hold?
An estimate leans on norms from earlier work. Without reliable post-calculation per construction element, those norms are carried forward for years without being checked against what the work actually cost.
The administration lags behind the site
A construction project does not produce today's administration today. Progress is recorded at the end of the week, timesheets are processed afterwards, and the subcontractor's purchase invoice follows their notice of completion. Anyone reading the realised column is reading events from weeks or months ago.
For financial reporting that is no problem, since the figures only need to be right at the balance sheet date. For project management it is fatal: someone reading in week 20 how the project stood in week 14 can do nothing with that.
Execution runs ahead
The brickwork is finished and the installer has started, but the associated costs are not recorded anywhere yet. The reverse happens just as often: materials have been delivered, so the costs exist, but nothing has been built with them yet. As long as progress and costs are not measured in the same unit, every comparison is misleading. Progress should have its own record, in quantities or percentage complete per construction element.
The invoice tail of subcontracting
Subcontractors invoice after completing their part, sometimes per instalment, sometimes only after approval of a completion notice, sometimes months later. Until that point nothing appears in the cost column, even though the commitment was made long ago. The answer is a commitments ledger: purchase orders, call-offs and subcontract sums appear in the project view at the point of order placement, not only when the invoice arrives.
Variation work starts verbally
This is where projects lose track. The client asks for a change on site, the site manager agrees, and the record follows days later or never. Under article 7:755 of the Dutch Civil Code, a contractor can only claim a price increase if it gave timely notice of the need for it, unless that need should have been obvious. Variation work therefore needs its own stream with its own statuses: work carried out but not approved is a risk, and approved but unbilled variation work is working capital.
Two versions of the same work
The schedule holds phases, activities and dependencies. The financial ledger holds cost types, cost objects and general ledger accounts. The same week's work appears in one system as ground-floor structural work in working days, and in the other as postings for labour, materials, plant and subcontracting. A key that links both structures rarely exists and so has to be designed. That is where the value lies, and where the friction is.
What such a system must be able to do
This leads to a list of requirements that matters more than any visualisation. The most important: the system distinguishes what has been invoiced, what is committed and what has been performed. Three figures that often diverge.
The method that sits behind this, known outside construction as earned value management, was formalised in 1998 as ANSI/EIA-748. Its core is usable without the full apparatus: compare the actual costs not with the budget to date, but with the budgeted value of the work that has been completed. A project that is behind schedule and therefore under budget looks healthy in an ordinary budget-versus-actual chart.
The second requirement is looking ahead. The estimate at completion, the expected cost to finish added to what has been spent, is the only figure you can still steer by. That estimate is partly calculation and partly judgement; keep both, so that it becomes visible how earlier estimates from the same project manager compared with the outcome. This is sensitive, and it is also the most valuable report such a system produces.
The data comes from a construction or ERP package such as Exact Bouw7, 4PS Construct or AFAS, from a scheduling package such as Asta Powerproject, Primavera P6 or KYP Project, and from a procurement flow that increasingly runs through the DICO Standaard and Peppol. With BIM, quantities from the IFC model can serve as a measure of progress, provided the bill of quantities is included in the export.
- Invoiced, committed and performed shown separately
- Commitments recorded at order, not at invoice
- Variation work as its own stream with its own status progression
- Estimate at completion alongside actual costs
- An explicit key between schedule and cost structure
- Every figure traceable to its source record
Comparability is an organisational question
Benchmarking between projects is the question boards ask most often and find hardest to answer. Not because the technology falls short, but because project A records its costs differently from project B. If one estimating tool books the crane under plant and another under general site costs, even the best dashboard is comparing unlike quantities.
There are standards for this. NEN 2699:2017 sets out the classification of investment and operating costs for immovable property and replaced the older NEN 2631, NEN 2632 and NEN 2634. For classification by building component, NL/SfB is the prevailing element classification, maintained by Ketenstandaard Bouw en Techniek. In addition, non-residential construction uses the STABU system, and civil engineering, roads and hydraulic engineering use the RAW system from CROW, which describes specification items in a cost-homogeneous and measurable way and gives measurable quantities their own remeasurement regime.
Choosing a standard is the easy part. The real work lies in agreeing that everyone who uses the coding actually sticks to it, in estimating, procurement and timesheets, and in accepting that estimators and planners have to apply that discipline when they get little back for it themselves. We can support this with mandatory fields and validations, but part of this process consists of consultation rather than building software. Skip that, and you end up with a dashboard that places figures side by side that do not belong together.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →When standard reporting is enough
Many construction firms get a long way with what is already available. Exact Bouw7, 4PS Construct and AFAS offer project monitoring with a working budget, and putting a standard BI tool on top of that produces useful reporting with far less effort. If your project administration runs mainly in a package, and your questions are essentially budget versus actual by cost type, then custom development is the more expensive route to the same answer. For some readers of this page, that is the honest conclusion.
Custom development starts to pay off when data has to come from systems that do not know about each other. A schedule in Powerproject, an estimate in a separate package, hours logged through an app on site, procurement in the ERP and a client who insists on its own reporting format: bringing those together requires a layer that none of those vendors supply. The same applies when your way of steering projects is itself distinctive, for example because you work with alliance teams or two-stage contracts, and standard reporting does not recognise that contract form.
The third reason comes up most often: you're stuck on a vendor's roadmap. The report you need has been on the wish list for two releases already. Keep in mind that custom software shifts the maintenance burden: documentation, keeping integrations up to date when a vendor changes its API, and revalidating figures after every release fall to you or to the party you contract with. That belongs in the decision.
- Project data sits in systems that do not know about each other
- Planning and financial administration need to line up
- You work with alliance teams, two-stage contracts or UAV-GC
- Clients require their own reporting format
- Estimating norms need to come from your own post-calculation
Frequently asked questions about construction data analytics
The questions clients ask just before they decide.
For many firms that is the right choice. If your project administration runs mainly in a package such as Exact Bouw7, 4PS Construct or AFAS, and your questions are essentially budget versus actual by cost type, then a standard BI tool on top is sufficient. Custom development only becomes worthwhile when data has to come together from systems that do not know about each other.
This is a contractual question and should be answered before the build begins. Record who owns the source code, the data models and the transformation logic, and where the repository is held. For each integration, ask for a description of which field comes from which source system. A system where nobody can explain how a figure is produced is worth little once the builder has left.
Decide in advance which figure is meant for what. The accounting of ongoing projects follows RJ 221 and typically uses the percentage-of-completion method, with its own rhythm and its own valuation principles. A management dashboard is more interested in a usable indication than a verified figure. The two may differ, provided the difference can be explained.
Yes, but benchmarking should not be the first goal. Start with the projects that are comparable, or with analyses that don't need uniform coding, such as the lead time of additional work. In parallel, record a coding agreement based on NEN 2699 or NL/SfB. Recoding older projects is possible, provided the registration was detailed enough.
Usually yes, because these packages offer APIs or exports that are sufficient for this purpose. The limitations lie elsewhere: which fields are available, how often you may query, and what happens when the vendor releases an update. We build the integration so that a change on the source side becomes visible, rather than quietly producing wrong figures. See also our page on the Bouw7 integration.
More than companies estimate in advance, and that is the most important risk factor. Recording progress in quantities or percentage complete, reporting additional work immediately and registering commitments when they are ordered all happen on site. If that can't be done in a few taps on a phone, it won't get done, and the dashboard will be empty or wrong. That is why we design the input side first.
Related services
Building a Bouw7 integration
If your main concern is data that needs to flow between two systems, for example project administration into accounting, an integration is the shorter route.
Predictive analytics dashboard
If you want to predict which work is at risk of getting out of hand, that is the next step. The prerequisite is a historical record that is consistent enough to train on, and that is what construction data analytics sorts out first.
Shall we first see whether you need this?
Tell us which systems hold your project data, how you currently determine the status of an ongoing project, and which moment you consider too late. Based on that, we'll tell you whether reporting on top of your existing package will get you there, or whether custom development is justified.