TL;DR
A quantity error produces a document that looks completely normal. Microsoft documents its agent returning 2,000 grams for 2 kilograms, and a price of zero.
Because a wrong quantity produces a document that looks completely normal, and nobody re-reads a document that looks finished.
The item is right. The description is right. The customer is right. One number in the middle is wrong, and nothing on the page suggests anyone should look.
For anyone who has to trust the output of a quoting system before pressing send. 8 minute read.
Why is a quantity error different from an item error?
| The item is wrong | The quantity is wrong | |
|---|---|---|
| How it looks on the page | A product nobody asked for | Entirely normal |
| Who catches it | The reviewer, or the customer | Frequently nobody |
| When it surfaces | At review, or on delivery | On the invoice |
| What it costs | A correction | The margin, or the order |
The received wisdom is that item matching is the hard problem, and in one sense it is — chapter 1 is about it. But item errors announce themselves. A reviewer scanning a sheet notices a fire extinguisher on an order for copper fittings.
Nobody notices `80` where the customer wrote `8`.
What does Microsoft document about this?
Not a hypothetical. Business Central's Sales Order Agent [GA] publishes a section headed "Scenarios impacting reliability in handling customer requests", and unit-of-measure conversion is its 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. The customer asked for two kilograms. The document says two thousand grams. In a system where a kilogram has been configured as nine hundred grams, those are different quantities — and the document that says so looks completely ordinary.
There is a related bound on the availability check that points the same way. The 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 genuinely hard problem, published by the vendor, and it is far more useful than silence.
Why does a missing quantity hide better than a wrong one?
This is the sharpest version of the whole argument, and it comes from a failure in our own build that cost 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 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 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.
Two separate rules were broken by one display decision: a blank is never a zero, and a blank is never hidden under a tick that means something else.
The unit is part of the quantity, incidentally. 40 m is not 40, and a row carrying a number without its unit has already lost half the fact.
What is a price of zero?
The same shape, and Microsoft documents the mechanism precisely on the item-availability page [PRP]:
"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 one, it totals like one, 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 acknowledges how quiet it is: the advice is to enable a notification, because "the price is 0 and no notification appears" is a state the system can reach.
This matters most where pricing is customised — and Microsoft names extensions as the cause. In its own words, Business Central's pricing logic is "often extended by ISV solutions." The more extended your pricing, the more likely the silent zero.
What is 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. Placed at the end of a row, it becomes a claim about the row — and the row contains a quantity nobody scored. That is not a display detail. It is the difference between a review that works and one that produces false assurance, which is worse than no review at all.
Three corollaries, and they are short:
- Score what you scored, and put 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.
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.
Sources
- Process sales quotes and orders with Sales Order Agent
- Item availability in Sales Order Agent (preview)
- Sales Order Agent overview — Business Central
This article is part of our work on the RFQ quoting engine.
Share this article
How an agent reads an RFQ, matches each line to your catalogue and prices it, and what has to happen to the lines it cannot resolve.
