How accurate is an AI estimate, line by line?

What does accurate mean for an estimate?

A pre-calculation works out what a part will cost before anyone has made it. Every estimate of that kind has spread and uncertainty: the setup turns out differently from the plan, or the operator runs the first piece more carefully. A single accuracy figure on the total price says nothing until you know which parts it was measured on, and against which actual hours.

Accurate means something more practical here: the lines stay close to what the shop floor really does. Setup, programming, machining and material, each with a time or a price you recognise. Even cycle time comes in more than one version, as four cycle times for the same part shows. The wider picture is in what AI means for the precision machine shop.

Where does a figure in the estimate come from?

A figure you cannot trace is a figure you cannot defend, to the customer or to the manufacturing engineer who prepares the job. So every estimate line should show what it is built from: the time, the rate and the quantity. Those are its line inputs, and with them you can check the sum yourself.

For the time, you want to know what it rests on: the geometry of the model, a requirement on the drawing, or a value somebody typed in. The rate should be your own hourly rate for that machine, not an average from a database. For material, it is your purchase price, with its date.

That provenance has to be there, but it need not sit beside every figure: you call it up when you need it. Only what is missing should stand out.

Why do AI prices differ so much?

Run the same part through a few tools and the prices can land far apart. The gap comes from what each tool starts from.

One tool uses a standard rate, another the rate you set per machine. Where one counts two setups, another counts one. An instant price from a sourcing portal may start from what similar work fetches on the market, while a cost price from your shop starts from what the work costs you. Sometimes finishing drops out, or setup time disappears into an average per piece.

An instant price from a portal is built for the buyer who compares, not for the shop that makes the part. Match your quote to it and you pay the difference yourself: a small batch with two setups and anodising, priced as one setup without finishing, takes the second setup's time and the anodiser's invoice straight out of your margin. So compare line by line, not on the total. Then the difference gets a name: a different rate, or an anodising line that is missing.

How do you test software on your own drawings?

A demo on a sample part shows how the software works. Whether its results suit your work only becomes clear on drawings you have quoted yourself. You also find out how easily you can correct a line.

How to set estimate and actual side by side per operation is covered in estimate versus actuals per operation. The test itself takes five steps.

1. Pick three drawings you have quoted before: a simple turned part, a mid-range milled part and a complex part with several setups.
2. Share them only once confidentiality has been agreed, and remove the customer name and drawing number where you can.
3. Let the software price them and compare operation by operation with your own pre-calculation, not just on the total.
4. If you have a post-calculation for those jobs, add it as a third column.
5. For every correction, note where the difference was and why, such as a different rate or a finishing step that was left out.

What if a price is still missing?

Sometimes a price is missing. The anodiser has not replied yet, or a bought-in part has no price in your list. If the software fills in a zero, the total looks complete and is too low. If it fills in an average, you get an amount no supplier ever quoted.

A missing purchase or subcontract price should stay an open value: visibly open until someone fills it in. Better open than invented. That applies to purchase and subcontract lines, where a supplier sets the price; a machining time stays an estimate with inputs you can adjust. There is a worked case in finishing without a price.

Do you need years of history first?

Software that prices from history first needs an archive: earlier jobs with their actual hours. Not every twelve-person subcontract shop keeps one in good order. The OECD (2025) lists among the obstacles for small firms, especially in manufacturing, the difficulty of finding AI vendors suited to their needs and a lack of quality data. In a 2021 white paper on AI in one-off and small-batch production, Fraunhofer IPT wrote that manufacturers mostly lack the relevant data in sufficient quantity and quality.

In a report on robotisation (2026), TNO points out that an AI model built on data cannot always be prepared for every situation when the work carries a lot of variation and uncertainty. The report is about robots, but precision work in small batches has the same variation.

A pre-calculation need not wait for that. It can start from what a request already brings: the model, the requirements on the drawing, your own machines with their rates and your purchase prices. Tidy post-calculation records help later, when you calibrate, but they are not a condition.

What happens to your corrections?

A cost engineer who changes a line has a reason for it. The setup time is too tight for this material, or the job moves to the other machine. If nobody records that reason, it is gone the moment the quote leaves: the ERP keeps the price, not why it is that price.

So every change should be a correction with reason: who, when and why. That correction history should travel with the revision and the quote version, as software-driven machining sets out. When the part comes back, you can read what changed, and why.

Put post-calculations beside those corrections and you have the material for calibration: estimates checked against actual hours. In Blake, calibration on actual hours comes next. Every correction to the calculation stays on record, with its reason.