Why does a quote that looks correct cost the most?

Because nobody re-reads a document that looks finished.

Every quality system in this category is built to catch the visible failure: the line that did not match, the request it could not parse, the customer it could not identify. Those are cheap. They announce themselves, someone looks, and the cost is a few seconds.

The expensive failures are the ones that produce a complete, plausible, priced document. The item is right. The description is right. The customer is right. One number in the middle is wrong, and there is nothing on the page that suggests anyone should look.

For anyone who has to trust the output of a quoting system. 8 minute read.

Two error classes, and only one of them is visible

How it looks — The item is wrong: A product the customer did not ask for · The quantity is wrong: Entirely normal
Who catches it — The item is wrong: The reviewer, often the customer · The quantity is wrong: Frequently nobody
When it surfaces — The item is wrong: At review, or on delivery · The quantity is wrong: On the invoice, or on the total
What it costs — The item is wrong: A correction · The quantity is wrong: The margin, or the order

The received wisdom is that item matching is the hard problem, and in one sense it is — chapters 5 and 6 are about it. But item errors are self-announcing. A reviewer scanning a sheet notices a fire extinguisher on an order for copper fittings.

Nobody notices 80 where the customer wrote 8.

The quantity nobody checks

Two failures from our own build, both real, both cheap to cause and expensive to find.

A formatting rule ate a digit. "2 boxes pipe insulation" lost its leading quantity in normalisation and arrived as a line for one box. Correct item, correct description, correct price per unit. The total was wrong and nothing about the row said so.

A specification was read as a quantity. "90 degrees" — part of the item's description, describing the angle of an elbow — was parsed as a quantity of ninety. That one is almost comic until you price it: ninety fittings instead of the eight the customer wanted, on a quote that reads perfectly.

The right item at the wrong quantity is worse than no match at all, and the reason is entirely about attention. An unmatched line demands a decision. A matched line with a bad number asks for nothing.

The unit is part of the quantity, incidentally, and dropping it is the same error wearing different clothes. 40 m is not 40. A row that carries a number without its unit has already lost half the fact.

Microsoft documents this exact failure in its own agent

We are not describing a defect peculiar to our build. Business Central's Sales Order Agent [GA] has a published section on reliability, and unit-of-measure conversion is the first entry:

"You might need to correct the quantities in the created document when nonbase units of measurement differ from the standard ones. For example, if the system treats 1 kilogram as 900 grams and a customer requests 2 kilograms, the system might generate a document showing 2,000 grams instead of 1,800 grams or 2 kilograms."

Sit with that for a second. The customer asked for two kilograms. The document says two thousand grams. Those are not the same quantity in a system where a kilogram has been configured as nine hundred grams — and the document that says so looks completely ordinary.

There is a related bound on the availability check, and it points the same way. Microsoft's agent sets its quantity filter "to the requested quantity, currently only in the base unit of measure" — so the availability answer is computed in base units regardless of what the customer wrote.

None of this is a criticism of Microsoft's engineering. It is an honest disclosure of a hard problem, published by the vendor, and it is far more useful than silence.

A missing value hides better than a wrong one

This is the sharpest version of the whole argument, and it comes from a failure that cost us real money on a real document.

Nine lines were written in the form code x 80. The parsing lost the quantity entirely — not to a wrong number, to nothing. The lines came back matched at high confidence, passed review under green ticks, and dropped out of the total.

Here is the mechanism, and it is worth understanding because it generalises far beyond quoting:

*The confidence score was about the item. It was displayed as though it covered the row.*

The system was entirely correct that code resolved to a specific catalogue item. It was highly confident about that, and it said so. The reviewer read that confidence as a statement about the whole line — item, quantity, unit, price — because that is where the tick was sitting.

A blank is never a zero, and it is never hidden under a tick that means something else. Those are two separate rules and both were broken by one display decision.

A price of zero, which means "not calculated"

The same shape appears in Business Central, and Microsoft documents the mechanism precisely:

"The Sales Order Agent calculates prices by creating a temporary sales document and applying the standard Business Central pricing engine. Extensions that subscribe to events on sales documents might not work correctly with temporary documents. If an extension modifies pricing logic or validates fields on sales lines, the price calculation can fail and return a price of 0."

Zero is a number. It renders like a number, it totals like a number, and on a quote line it reads as this item is free rather than we could not work out what this costs. Microsoft's own troubleshooting advice acknowledges how quiet it is: it tells you to enable a notification, because "the price is 0 and no notification appears" is a state the system can reach.

This matters especially in Business Central, where — in Microsoft's own words — pricing logic is "often extended by ISV solutions", which is exactly the cause Microsoft names. The more customised the pricing, the more likely the silent zero.

The rule underneath all of it

Every failure above is one rule broken in a different place:

A number displayed with confidence is a claim, and every claim on a screen has to be about the thing it sits next to.

Not the row. Not the line. Not generally. The thing it sits next to.

A tick beside an item name is a claim about the item name. If it is placed at the end of a row, it becomes a claim about the row, and the row includes a quantity nobody scored. That is not a display detail — it is the difference between a review that works and a review that produces false assurance, which is worse than no review at all.

The corollaries are short:

Score what you scored, and place the score where its subject is.
Show a blank as a blank. Never as a zero, never under a tick.
State the unit with the quantity, always, because a bare number is an incomplete fact.

And the instructions have to reach the document, not just the screen

One last failure in the same family, because it produces the same looks-fine outcome.

A deadline, a job reference and a correction never become priced lines — so a system that treats the quote as "the lines" will send a perfectly formatted document with none of them on it. The customer asked for delivery by Thursday and the quote is silent about Thursday.

The sent document carries them, in their own block, corrections first. And it reads them from the same place the review screen reads them: re-deriving them for the export creates a second version of the truth, and the two start disagreeing immediately.

About Cognilium Cognilium builds AI systems that work in tandem with Microsoft Dynamics 365 — the decisions the ERP records but does not make. Business Central and Finance & Operations, on your own governed stack. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to stress-test a quoting flow against the errors nobody catches? Book a 15-minute call — bring a request with awkward units and we will run it. No deck.

Why does a quote that looks correct cost the most?