AI Quantity Takeoff: Where It Works and Where It Breaks

It is the last week of the month and the lights in the technical office are still on. Sixty photos sent from site over messaging apps, a handful of voice notes, a photocopy of the timesheet, and one message reading "we forgot the takeoff on that wall." One person is filling in the measurement book, cross-checking cost codes and trying to remember which work items made it into last month's application for payment.

This scene repeats every month in contracting and subcontracting firms everywhere. The frustrating part is that the effort goes into recording the work rather than doing it. The wall is already built. What the desk is consuming is the labour of proving how much of it was built.

This guide looks at what a firm shopping for progress billing software actually needs: where AI quantity takeoff genuinely helps and where it falls apart, why generic tools leave you stranded halfway, and how scattered site data turns into a report. If you want the wider view of which AI applications fit which sector, our AI by industry map lays out the landscape.

Is progress billing software the same as accounting software?

No, and confusing the two is how firms end up buying the wrong system. Accounting software produces invoices, ledgers and tax filings. Progress billing software produces the measurement summary, the schedule of work completed, the takeoff check report and the payment application cover. The two share data; neither replaces the other.

Inside a single payment application the desk is handling separate work items: structural takeoff, rebar takeoff, mechanical and electrical takeoff, section takeoff, the check report against each of them, the summary, the completed works schedule and finally the cover. Each is its own calculation and its own control point. Month-end delays rarely come from one item; they come from every link in that chain being carried by hand.

So the question to ask a vendor is not "does it do progress billing" but "which links of this chain does it connect to each other." A system that takes the takeoff and generates the summary automatically is worth several times one that only prints the cover.

Your rate book is not one document

Whatever market you work in, there is usually more than one published pricing reference and they serve different purposes. One set of figures is used for approximate cost and fee calculation at the design stage. A separate set, the detailed schedule of rates or unit price items, is what payment applications are actually measured against. Public sector work typically mandates a specific set; private work follows whatever the contract says.

Getting this wrong is expensive in a mundane way. A payment application built on the wrong reference turns into correspondence with the client, and correspondence turns into delayed cash.

The public versus private distinction matters for a second reason. Public contracts largely fix the format: specification, rate codes, a prescribed measurement book layout. Private work leaves the format to the contract, and firms usually default to their own spreadsheets. That looks more flexible, but it is unaudited, and when a dispute arises over quantities you have no chain of evidence to point at.

Can AI quantity takeoff replace your estimator?

Short answer: no, but it can seriously compress the repetitive part. Every credible automated takeoff approach in use today runs with a human in the loop. The system counts, traces and scales on the drawing; a senior estimator verifies the output and handles the complicated items directly. No arrangement that removes the verification step survives contact with a real project.

What matters more is understanding what performance depends on. On clean, vector-based PDF drawings, automated takeoff does useful work. When the drawing is a scan, contains handwritten markups, or overlays multiple systems on one sheet, accuracy degrades noticeably. Dense mechanical and electrical layouts and reinforcement detailing are far harder than architectural plans.

The practical rule that follows: start your AI takeoff trial with architectural floor plans and clean files. If your first test uses the scanned sheets from your most complex project, the result will justifiably put you off, but you will have formed the wrong conclusion about the technology.

Most takeoff tools market accuracy figures of 95 percent and above. Those numbers come from vendor marketing rather than independent testing. Running one sheet from your own project through a trial tells you more than any datasheet.

Why do generic takeoff tools leave you halfway?

International takeoff products, the ones using computer vision to identify rooms, areas, doors and windows, do technically solid work. The problem is not the detection. It is what the output connects to. These tools do not know your local rate codes, your prescribed measurement book layout or the payment application format your client expects.

The result is that you get a takeoff, but what you hold is a list, and the step that converts that list into a payment application is still manual. Half of the tedious work is automated and the other half sits exactly where it was. When firms say "we tried it and it did not quite fit," this missing link is usually why.

The most effective arrangement we have seen is to use a mature takeoff tool and build a thin layer that maps its output onto the firm's own rate catalogue. There is no need to write a takeoff engine from scratch. What is missing is the translation layer.

Can site messaging traffic become a report?

Yes, and this is usually the fastest payback available. Most site data is already digital: photos, voice notes, messages. What is missing is structure. Transcribing the voice note and attaching it to a date, block, floor and work item; linking the photo to the relevant item; letting the timesheet flow into the daily report.

Most off-the-shelf site management products promise to feed timesheet and production data into a daily report, but converting free-format messaging content into structured records automatically is not a standard feature. This is one of the places where custom development genuinely earns its cost.

Mechanically this belongs to the same problem family as turning a receipt photo into an accounting entry: extracting structured records from images and free text. Our guide on automating expense reports from receipt photo to ledger walks through the same pattern on the finance side.

A month in a subcontractor with three sites

Picture a 25-person subcontractor doing structural work across three concurrent sites, with a single person in the technical office. Month-end payment preparation takes about a week, and most of that week goes into collecting data, verifying it and calling site managers to ask what was actually done where.

The first intervention was not buying software. It was changing the shape of data entry. Site managers began logging daily production through a short form instead of free text: block, floor, work item, quantity, photo. They kept sending voice notes, but those notes were transcribed automatically and dropped into the same form as a draft. The manager only had to confirm.

By the end of the second month, payment preparation had gone from a week to two days. The gain came not from AI producing takeoffs but from the information that used to be reconstructed at month end having accumulated day by day. Automation on the takeoff side only started to make sense after that discipline existed.

How relevant are the industry delay statistics to your business?

One data point shows up constantly in sector writing: according to McKinsey's widely cited 2016 work, large construction projects run around 20 percent longer than scheduled and go up to 80 percent over budget. That phrase, "up to 80 percent," is regularly repeated as "80 percent over budget." The difference looks small and changes the size of the claim entirely.

The more important caveat is scope. That finding concerns large projects, and megaproject statistics, covering work above a billion dollars, describe another world again. For a firm delivering a twelve-unit residential block, those numbers do not transfer directly.

What does transfer is the mechanism. Delay and overrun come from broken record-keeping: late awareness of what was built, late payment applications, disrupted cash flow. That chain operates identically on small jobs. Only the figures shrink.

Why can you never find the prices?

Progress billing and site management software rarely publishes pricing. Across the products we reviewed there was no open price list; every one runs on a fill-in-the-form-and-wait-for-sales model. For a firm trying to compare options, that is real friction.

Our practical advice: when requesting a quote, state user count, number of sites and module scope in writing, and ask for the annual total. A monthly per-user price sounds small until you multiply it by three sites and ten users.

Custom development follows different logic, where cost is driven by scope. There is a wide gap between a layer that simply collects site data and turns it into reports and a full progress billing system. Keeping the first release narrow is almost always the right call.

What should you be recording from site every day?

Delays in payment preparation almost always trace back to information being gathered at month end. The list below is the minimum daily record set you can start today without buying anything. Any software you eventually buy will ask for exactly this.

• Location: site, block, floor, room. A quantity cannot be tied to a payment application without a location; "wall built" on its own is useless.
• Work item and quantity: ideally against a rate code. The site manager does not need to know code numbers, only to pick from a short list.
• Timesheet: who, which crew, how many hours. This is the single shared source for subcontractor payments and cost analysis.
• Photo: attached to the work item and dated. In a dispute this is frequently the strongest document you hold.
• Obstruction and waiting records: material not delivered, weather, no power. Extension of time claims are built from daily records, not from memory.

Once those five are kept consistently, payment preparation stops being a collection exercise and becomes an assembly exercise. That is also exactly where automation contributes: reducing the burden of filling that form, and dropping voice notes and photos into those fields as drafts.

Frequently asked questions

I have no BIM model. Is automated takeoff still possible?

Possible but limited. With a model, quantities come from the model and the problem is already solved. Without one, the work falls back to detection on drawings, which is reasonable on clean vector PDFs and noticeably worse on scans. If you have no model, set your expectation at "the estimator gets faster" rather than "the estimator becomes unnecessary."

Off-the-shelf or custom?

For the standard takeoff and payment application flow, off-the-shelf products are mature and writing that from scratch is wasteful for most firms. Custom development pays off where your firm is genuinely different: how site data gets captured, mapping to your own rate catalogue, talking to your existing accounting system. The right answer is usually a combination.

Can AI fill in the measurement book?

It prepares it rather than fills it. If the underlying takeoff and production records are collected properly, generating the summary is a mechanical step. The difficulty was never writing the book; it was hunting for the data that feeds it at month end.

Will site managers actually adopt this?

In proportion to how short you keep the form. The threshold we see in the field is roughly two minutes: beyond that, daily entry gets abandoned and messaging apps win. Which is why the right strategy is not banning the messaging app but converting what arrives through it into records.

So what should you actually do?

• Fix daily data capture first. While information from site arrives as free text, no software will rescue your month end.
• Run your takeoff trial on clean drawings. Start with vector PDFs and architectural plans rather than judging the technology on scanned sheets.
• Digitise your rate catalogue. This is the link that connects generic tool output to a payment application, and it is usually where the time disappears.
• Ask for quotes as an annual total. Per-user monthly pricing makes comparison unnecessarily hard.
• Never remove the verification step. An automated takeoff is a draft, and you are still the one signing it.

Technology conversations in construction tend to open with grand claims, while most firms' actual gain comes from somewhere very ordinary: information that used to be reconstructed at month end being written down as it happens. AI will not fill in your measurement book, but it can put organised data in front of the person who does. If you want to work out where that gap sits in your own operation, bring one sample payment application file and we can look at it together.