The verify tax
Review time decides whether AI estimating and quoting pays. How to design so every line links to its source and only exceptions get reviewed, and the three numbers to measure.
- SMSimran MalhotraCo-founder
5 min read
Every AI estimating demo reports processing time. The BOQ went in, and four minutes later a priced sheet came out. That number means very little to the person who has to sign the sheet. Their clock starts when the sheet lands on their desk and stops when they're willing to put their name on it.
We call the time between those two points the verify tax. It's what a person spends checking the machine's work before they can use it, and it decides whether the tool pays for itself.
An estimator on r/estimators put a number on it. After being trained on an AI takeoff tool, they found that cleaning up its output took 70 to 80% of the time a normal takeoff would, even on clean plans (thread). That's a saving of 20 to 30% at best, before the cost of the tool and the risk of whatever got missed. In another thread, an estimator described a company winning a $2.5M job and then finding no budget for dumpsters or job prep, because the takeoff had been done with AI and never checked (thread). Both stories have the same root. When checking a line means redoing it, the tax is close to 100%, and people either pay it in full or skip it.
Why review takes as long as the work
Review is slow when the reviewer has to go and find things. The sheet says 146 Nos of a 600×600 panel. To check it, the estimator opens the BOQ and finds the line, opens the spec and finds the clause, opens the luminaire schedule and finds the type code, then compares. The tool did the same reading, but it threw away where it read each fact from. So the person reads it all again.
Review is also slow when nothing tells the reviewer which lines to look at. If the output is 400 lines with the same visual weight, the only safe approach is to check all 400. A tool that's right 95% of the time doesn't help much if you can't tell which 5% are wrong.
False alarms cost as much as misses. A commenter on r/ConstructionManagers described a PM who runs every submittal through AI and then asks for the flags to be reviewed, and said about 60% of what it flags is nonsense (thread). Every one of those flags still had to be read and dismissed by someone who knew better.
Design for the reviewer
Three rules follow, and they do more for the verify tax than a better model does.
Every line links to its source. A matched line carries the BOQ row number, the spec clause, the schedule type and the catalogue SKU, and clicking any of them opens the document at that spot. Checking a line becomes a look at two things side by side. "Matched on 600×600, 40 W, 4000 K, UGR 19; lumen output 3,900 against 4,000 required" is a reason a person can verify in seconds. A confidence score of 0.94 on its own gives them nothing to check.
Lines that need judgement are kept apart from lines that don't. Confident, fully matched lines go in one place and stay there. Deviations, low-confidence matches and "no match" lines go into a queue. The estimator works the queue and spot-checks the rest. That split is where the time saving comes from, and it only holds if the confident bucket really is trustworthy. Set the threshold high at the start and loosen it as the evidence builds.
The tool is allowed to abstain. A line marked "no match, price by hand" costs the estimator what it always cost. A wrong match marked as confident costs far more, because once people find one, they stop trusting the whole bucket and start checking every line again.
How to measure it
If you're piloting an AI estimating or quoting tool, measure the review, and measure it on your own past jobs. Pick ten to twenty tenders your team has already priced and run them through. Then have the estimator who would normally do the job review the output with a timer running. Record three numbers per job.
| Measure | What it tells you |
|---|---|
| Review minutes per job | The verify tax itself, set against the hours the job took by hand |
| Exception rate | The share of lines sent to the review queue |
| Rework after review | Lines that passed review and were changed later, at pricing, submittal or after award |
Review minutes per job is the headline. Compare it with how long the same job took by hand, and count the setup too: normalising the sheet, uploading files, fixing the export so it fits your template. A tool that saves four hours of matching and adds two hours of fixing the output has saved two hours.
Exception rate tells you whether the design is working. If 70% of lines land in review, the reviewer is doing the job again with extra clicks. Track it by job type, because a tender from a consultant who writes clean specs behaves very differently from a contractor's sheet with merged cells and "as per drawing" in every description.
Rework after review is the number that catches false confidence. If it rises over the pilot, people have started rubber-stamping the confident bucket, and that's more dangerous than a slow review.
For a sense of what others are reporting, a UK contractor's pilot covered by Construction Management in February 2026 cut BoQ packaging from about 13 hours to about 4.5 hours per BoQ across 14 BoQs, with people reviewing the output. The article says accuracy was measured and doesn't publish the figures. That's the gap to close in your own pilot. A time saving means little until you know the rework that came with it.
Run the timed review before you sign anything, on jobs where you already know the answer, and ask the vendor to sit beside your estimator while they do it. Each time the reviewer leaves the screen to hunt for a page, you're watching the verify tax being paid. When we scope a BOQ estimation pilot, review minutes per job is the first baseline we ask for.