AI in estimating and tendering in construction: read faster, calculate sharper

In practice, AI in estimating and tendering in construction means four things: reading tender documents faster for risks and missing items, preparing quantities from drawings, finding your own past estimates and post-calculations when you set up a new one, and recording per bid what it delivered. The estimator keeps making the price. The system does the reading and searching, so more time is left for the questions where the money is: which risks you price in, what the market is doing, and whether you actually want this job. Start small, on a few bids alongside the estimator, and measure before you expand.

In our broader piece on AI in construction we named estimating as the first place where the money sits, alongside planning and quality control. This piece goes deeper into it. Estimating is the part of construction with the sharpest arithmetic: a missed item or an overly optimistic assumption only shows up in the post-calculation, and by then the money is gone. Here you read what AI concretely does in the tender phase, why your own post-calculation is worth more than any general model, where the estimator's judgement stays essential, and how to roll it out without doing anything you cannot undo. With a worked example you can redo with your own figures.

Who this piece is for

According to Statistics Netherlands (CBS, table 81589NED), the Dutch construction sector has 269,845 companies in the third quarter of 2026. The vast majority are small: 233,700 of them have one person working there. 950 companies have fifty or more people working there, of which 780 have 50 to 250 and 170 have 250 or more. Of those 950, about 320 are in general construction and project development, 140 in civil engineering and 495 in specialised construction, such as installation and finishing companies. Because of rounding in the CBS table, those subgroups add up to 955.

That is the group this piece is written for. Large enough for an estimating department with a few estimators and work planners, and for an archive of hundreds of completed projects. Too small for a data department of its own.

CBS also measures how companies use AI (table 86119NED, covering 2025). In construction, 41 percent of companies with 50 to 250 people use some form of AI. 32 percent use text mining, the automatic searching and analysis of text. 25 percent use AI for administrative processes or management tasks. 8 percent use machine learning. So most use sits in text. For estimating that is good news, because the first job in any tender is reading.

Reading: specifications, drawings and clarification notices

An average tender consists of a stack of documents: the specification (in Dutch the bestek) or descriptive document, the drawings, the bill of quantities if there is one, the tender guidelines with the award criteria, and one or more clarification notices (nota van inlichtingen) with questions and answers. An estimator must have read all of it before making a reliable price. In practice that happens under time pressure, often with several bids running at once.

A language model can do three things there.

Marking risks and special conditions. Penalty clauses, non-standard payment terms, requirements on construction time or working hours, prescribed materials, provisions on ground conditions or existing structures. The system puts them in a list with the page reference. The estimator decides what happens with them.

Finding contradictions. A drawing that gives a different dimension from the specification. An item that is in the specification but appears on no drawing at all. A clarification notice that changes a requirement while the old text is still in an appendix. This is the kind of error you want to find early. Dutch law gives a reason as well. Under article 7:754 of the Dutch Civil Code, the contractor must warn the client about errors or defects in plans, drawings, calculations, specifications or execution instructions provided by the client, to the extent that he knew of them or should reasonably have known of them. Whoever reads the documents more thoroughly spots those errors sooner.

Flagging missing items. This is where your own history helps. If the system knows your earlier estimates for comparable jobs, it can say: on the last five school buildings there was an item for site facilities of this order, and I do not see it in this estimate. The estimator judges whether that item belongs there.

Such a system also misreads. It can miss a provision or see a contradiction that is not there. That is why the rule is that every finding has a reference to the source, and that the estimator ticks off or rejects every finding. Without that reference it is an opinion, and an opinion is of no use in a tender.

Holding drawings side by side in a building under construction. A system can mark contradictions, the estimator judges which ones matter.

Quantities from drawings

Taking off quantities, such as metres of wall, square metres of floor and numbers of window frames, often takes up most of the estimating time in building construction. There are roughly two situations.

If a 3D model is available, for example in IFC format, many quantities are already in the model. The work then lies in checking whether the model is complete and whether the elements have the right properties. Software can read out quantities and group them per element. The estimator checks whether the output matches what he sees on the drawing.

If there are only 2D drawings in PDF, which is still the case in many smaller tenders, image recognition can help with measuring and counting: recognising rooms, calculating areas, counting symbols. That works reasonably on clean drawings and poorly on scanned or busy ones. Use it as a first draft that the estimator re-measures, especially for the items with the largest amounts.

In civil engineering things are different. There you often work with a specification in which the client has already set out the quantities in a schedule. Then the work is checking: do those quantities match the drawings, and where is an item that may have been underestimated? A deviation there is a question for the clarification round, or a risk you price in.

How much time this saves depends heavily on the type of work and the quality of the drawings. So measure it yourself, per project type. A general percentage from a vendor says little about your drawings.

Your own post-calculation is the real data

Every construction company of this size has an archive of estimates. Often also of post-calculations: what the job eventually cost in hours, materials and subcontractors. That archive is more valuable than any general model, because it shows how your crews work, with your subcontractors, in your region.

The data is usually there. What is missing is the connection between estimate and post-calculation. The estimate is set up per element or per specification item, the hours are booked per week or per project, and materials are purchased on a purchase number that refers to no item at all. Then you can see afterwards that the project came out 4 percent worse, but not where.

That is the first piece of work, and most of it is not AI work. Agree that hours and purchases are booked on the same coding as the estimate, for example per element using NL-SfB or your own estimate structure. Record which source wins when two sources contradict each other. How to approach that without a large migration project is described in getting your data in order for AI.

Once that link exists, a system can do three things that almost nobody keeps up by hand today.

Adjusting norms. Showing that for brickwork your estimate structurally counts fewer hours than the crew needs, or more.

Finding comparable projects. For a new tender, finding the five projects in your archive that most resemble it, with the estimate and the actual costs side by side.

Seeing patterns in deviations. For example, that renovation projects of buildings from before 1970 more often overrun on demolition work, or that a particular client more often leads to discussions about extra work.

Be honest about the scale. A company that completes 20 to 40 projects a year has a few hundred projects after five years. That is enough to make deviations per element visible, and too few for a model that predicts prices on its own. So treat the outcomes as a signal for the estimator.

A calculator and a mechanical pencil on a sheet of calculations. The post-calculation of your own projects is the data that makes a new estimate better.

Hit rate and the choice to bid

A bid costs money, even when you lose it. A company that submits many bids and wins few pays for the estimating hours of the lost bids out of the margin of the won projects.

That is why it pays to record per bid: the type of work, the client, the award criteria, the number of bidders, your own price, the winning price if known, and the outcome. After a few years you see where you win and where you do not. A system can keep that table up to date and, for a new tender, show how comparable bids turned out. The decision whether or not to bid stays with management and the estimating team.

There is also a warning here. PIANOo, the Dutch government's public procurement expertise centre, describes that in a tender awarded on price, the bidder who estimates the risks as smallest has the best chance of winning. It names unclear points in the specification as one of the reasons for a strategically low bid. So a higher hit rate is only a gain if the margin comes along with it. A company that wins more often thanks to faster estimating, because risks stayed out of view, gains nothing. That is why you always measure hit rate and the deviation between estimate and post-calculation together.

For public contracts for works below the European thresholds, the Dutch Works Tendering Regulations 2016 (ARW 2016) apply, on a comply or explain basis. That makes the structure of those tenders fairly predictable. For a system that has to learn which documents exist and where things are, that is an advantage.

Where the estimator's judgement stays

An estimate consists of quantities times prices, plus mark-ups for overheads, profit and risk. The first part is largely arithmetic, and a system can help with it. The second part is judgement.

Two things make the difference. First: every change the estimator makes to a proposal from the system stays visible, with a short reason. Those reasons show what the system does not know. They also make readable the knowledge that now sits only in the head of an experienced estimator. How to hold on to that knowledge is described in embedding AI knowledge in your organisation.

Second: the time freed up goes to the work where the estimator makes the difference. More time for the risk section, the conversation with subcontractors and the questions for the clarification round. If that time is immediately spent on more bids per estimator, it only gets busier. The intention is that the estimator gets better at the job. Nobody is replaced.

A worked example to fill in with your own numbers

This example is made up and is meant as a method of calculation. Replace every number with your own company's.

Suppose a contractor with 90 employees in building construction. The estimating department submits 60 bids a year and wins 10 of them. That is a hit rate of 1 in 6, about 17 percent. An average estimate takes 40 hours, so 60 times 40 is 2,400 hours a year. The won projects average 1.5 million euros, together 15 million euros of revenue.

Hours per estimate. Suppose reading, quantities and searching the history together save 10 hours per estimate. Then 60 times 10 is 600 hours a year are freed up. At an internal cost of 75 euros an hour, that is 45,000 euros of time. Those hours do not come off the payroll. They go to risks, questions for the clarification round and a sharper choice of which tenders to pursue.

Missed items. Suppose that per won project, on average 0.5 percent of the contract sum consists of missing items you cannot charge as extra work. On 15 million that is 75,000 euros of margin a year. If you catch half of that earlier, that is 37,500 euros.

Deviation between estimate and post-calculation. In our piece on AI in construction we calculated with a structural deviation of 2 percent. On 15 million that is 300,000 euros. If that deviation goes to 1.5 percent, because you adjust your norms using your own post-calculation, that saves 0.5 percent of 15 million, so 75,000 euros a year. This partly overlaps with the missed items. So do not simply add the two together.

Hit rate. Suppose the time freed up goes to better choices. You still submit 60 bids, but you pass on 6 tenders where you kept turning out to have no chance, and choose 6 that suit you better. If you then win 11 jobs instead of 10, that is 1.5 million euros of extra revenue. At a project margin of 6 percent that is 90,000 euros. This is the most uncertain part of the sum. It only counts if the deviation between estimate and post-calculation does not rise at the same time.

All of these percentages are assumptions. What it means for your company you only know after the trial period below. How to set up a calculation like this for your board is described in calculating AI ROI with your own numbers.

A rollout you can reverse

Start with a few bids. Every step below is reversible: if it does not work, you simply estimate the way you estimate now.

Step one: running alongside the estimator. Choose four to six tenders of a type you do often. The estimator works as always. Alongside, you let the system read the same documents, make a quantity take-off and find comparable projects. Afterwards you put the two side by side. Which risks did the system find that the estimator also found, which did it miss, and which did it find that the estimator overlooked? How many hours did the checking take?

Step two: the system as a starting point. On the next bids, the estimator starts from the system's draft and adjusts what is wrong. Every adjustment gets a short reason. You measure hours per estimate and the number of adjustments.

Step three: feeding back the post-calculation. Only when the first won projects have been completed do you see whether the estimates were better. That takes months, sometimes more than a year. Record those outcomes per element and feed them back into the norms.

Step four: expanding. Add other types of work once the first group has run well for a while. The estimator stays ultimately responsible for every price that goes out the door. The system proposes, the person decides and keeps watch where it matters. That is the principle of human on the loop.

Agree in advance when you stop. For example: if in step one the system does not deliver at least a few findings per tender that the estimator finds useful, or if checking takes more time than it saves, you do not move on. You first find out why. Often the cause is the quality of the documents or the coding of your own history.

How to measure whether it pays off

Start measuring before you change anything. Record what you can find for the last twenty to thirty bids. Then measure the same points in the same way.

Look at these points together. Fewer hours per estimate with a larger deviation in the post-calculation means you are making mistakes faster. A higher hit rate with lower margins means you have left risks on the table. The goal is a better estimate in less time, with a margin that holds.

Where it goes wrong in practice

Findings without a source. A system that reports a risk in the specification, without a page or article, costs more time than it saves. Require a reference with every finding.

Post-calculation that does not connect. If hours and purchases are not on the same coding as the estimate, the system learns nothing from the past. This is the first piece of work, before any model is involved.

Trusting quantities too soon. A take-off from a poorly scanned drawing can look neat and still be well off. Always re-measure the large items.

Nobody inside the company understands it. An outside party can set this up. If that party leaves and nobody can explain why the system flags an item, you come to a standstill at the moment it matters. Make sure one of your own estimators or work planners knows how it works.

Confidential documents in the wrong place. Tender documents and your own prices are confidential. Make sure you know where the documents are processed and who has access, before you put them into a system.

Where to start

Which package or approach you choose comes later. First you want to know where your organisation stands now: whether your estimating and post-calculation data connect, whether there are people who can carry this, and whether estimating really is the first step. The AI Photo is a free self-scan. Ten minutes, twelve questions, and you see exactly where your organisation stands.

About this page

The number of construction companies and the breakdown by size class come from CBS table 81589NED (companies by sector and size class, construction SBI F and subgroups 41, 42 and 43, third quarter of 2026). The figures on AI use come from CBS table 86119NED (ICT use by companies, 2025, construction, companies with 50 to 250 people). The duty to warn comes from article 7:754 of the Dutch Civil Code. The description of strategically low bids and the explanation of the ARW 2016 come from PIANOo. We deliberately do not name software packages. The worked example is made up and intended as a method of calculation, not a promise. This is the situation as of 5 October 2026.