TL;DR
An agent reads the request, identifies the customer, matches each line and prices it. What it does with the lines it cannot resolve is the real engineering.
It reads the request, works out who is asking, matches every line to something you actually sell, prices it at that customer's price, and hands a person the lines it could not settle.
Microsoft ships one for Business Central, and it is generally available. So the interesting question is not whether software can do this. It is what happens to the lines it cannot resolve — because a quoting system that is right about thirty-seven lines and quietly wrong about three has not saved anyone an afternoon.
For the owner or sales lead at a distributor that quotes from a catalogue, and the engineer scoping the build. 8 minute read.
What does an RFQ agent actually do?
Microsoft's Sales Order Agent [GA] describes its own loop:
"The agent uses AI to analyze customer requests received via email and locates the customer in Business Central. If important details are missing or more choices are available, the agent engages in multiturn email conversations to clarify the request. It checks inventory and informs the customer about the availability of the items they're looking for. The agent then follows up with a sales quote or order, based on configuration."
Five steps, in order: read · identify · match · check · quote. Every RFQ system does the same five, whoever builds it, because each one depends on the last. You cannot price a line before you know the customer, and you cannot check availability before you know the item.
There is no implementation project — "the agent is readily available in the product" — and a person still presses send. Microsoft is explicit: "The agent always involves designated Business Central users to review and approve all outgoing messages before it sends them to customers."
How does it match a line to your catalogue?
This is the step everything else rests on, and Microsoft documents a three-layer strategy:
- "Exact identifier match by item number, vendor item number, GTIN, or cross-references. Exact identifier matches have the highest confidence."
- "Semantic attribute matching uses item attributes from the customer's message (such as color, material, or size) and AI to rank candidates by relevance."
- "Broader fuzzy search falls back to a global search across all items when the direct and attribute-based searches don't produce results."
It searches eight tables to do it, including Item Reference — where the codes your customers use for your products live — and Item Attributes.
Notice what the third layer is being asked to do. It runs precisely when the first two found nothing: the hardest lines, the weakest signal, and a job description that says produce a candidate anyway. A global search across every item will almost always return something. Chapter 1 takes the layering apart; chapter 3 is about what that fallback should be allowed to do with a weak result.
Why can't it price a line before it knows the customer?
Because in Business Central a price is not a property of the item. It is a property of the relationship — customer price groups, discount groups, line discounts — and all of them resolve through the customer record.
Microsoft's agent does not read a number off the item card. It builds a document:
"the agent creates a temporary sales document behind the scenes and applies Business Central's standard pricing engine, including customer price groups, customer discount groups, and line discount rules. The result reflects the actual price the customer would see on a quote, not the list price from the item card."
The actual price, not the list price. The difference between them is the customer, and there is no shortcut — Microsoft's own agent manufactures a throwaway document rather than compute it another way.
So identity comes before pricing, and Microsoft is precise about how it establishes identity:
"For security, the agent identifies contacts exclusively by matching the sender's email address to the E-Mail field on contact cards. It doesn't search by contact name, company name, or other fields when establishing the security context. This restriction prevents unauthorized parties from impersonating a customer by using a similar name."
That is a sound trade, not a gap — fuzzy matching on a company name is how one customer's contract pricing gets attached to a stranger's request. It also means an unrecorded address stops the run. Chapter 4 is about what to do at that moment.
Where does an RFQ agent go wrong?
Here is the part worth reading twice, and it is Microsoft's documentation rather than our opinion. The process page carries a section headed "Scenarios impacting reliability in handling customer requests".
A unit-of-measure error. "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."
A wrong item, returned confidently. "Searches for related consumables often return the main product instead of the requested accessory or consumable." Microsoft's own example asks for washing powder and gets a washing machine — and states that the requested item is not in the catalogue at all.
Attributes used to search, then unavailable to judge. "The agent searches for items using item attributes, but the attributes aren't shown to the agent on the item availability page. This condition decreases reliability for customer requests that depend specifically on the attributes."
A price that fails silently. On the item-availability page [PRP]: "If an extension modifies pricing logic or validates fields on sales lines, the price calculation can fail and return a price of 0."
Read them together. Not one looks like an error on the finished document. The right item at the wrong quantity, a plausible neighbouring product, a missing attribute, a zero that means not calculated rather than no charge — every one produces a quote a reviewer scrolls past. Chapter 2 is about the quantity class specifically, because it is the one nobody checks.
What decides whether the quote can be sent?
Not the extraction. The extraction is the part that works.
What decides it is whether the reviewer knows which lines to distrust. Check three lines and send, and the afternoon is saved. Re-check all forty to find out which three, and nothing was saved at all.
Microsoft does show its working. The reviewer gets a timeline of the steps taken, and Business Central "can also display the reasoning used by the agent and citations that led to a suggested value." That is real explanation, and more than many systems offer.
What those four pages do not describe is a ranking — a per-line signal saying this one is least safe, start here. Work is surfaced as task-level Needs Attention steps, and at the availability step Microsoft states plainly: "You can't change the items and quantities at this point."
Explanation answers why did it say that. A ranking answers which one should I check first. Chapters 2 and 3 are about earning that second signal.
What does this cluster answer?
| ch | The question |
|---|---|
| 1 | How does RFQ line-item matching actually work? |
| 2 | Why does quote automation get quantities wrong? |
| 3 | What should happen when a line matches nothing? |
| 4 | Can an AI agent price a line without knowing the customer? |
| 5 | What can a quoting agent read and write in Business Central? |
| 6 | Can an agent chase a supplier for a delivery date? |
| 7 | Sales Order Agent or your own quoting agent — which request goes where? |
| 8 | When is AI quote automation the wrong build? |
What are we not claiming?
Microsoft's agent is good at the case it was built for: an email from a registered contact, a modest number of lines, no variant, no question about where to buy. Its documented limits read as deliberate engineering rather than gaps — "up to 15 item lines per sales document", and "the use of the item's Variant Code isn't currently supported." Chapter 7 sorts requests between the two approaches.
Nothing here touches stock or the ledger. Microsoft draws the same line and explains it: a quote comes first because sales quotes "have no impact on planning, reservations, availability calculations, or cash flow forecasts." And "the agent doesn't post documents."
Status, stated plainly. This is a system we build. It runs, it is demonstrable on a call, and there are zero delivered engagements — no distributor is running it today, and no number here describes anyone's business. We build these on request, against your catalogue and your Business Central.
Want to know which of your quote requests would come back needing a person? Book a 15-minute call and we will walk the five steps against your own inbound, on your data if you bring it. No deck.
Sources
- Sales Order Agent overview — Business Central
- FAQ for Sales Order Agent — Business Central
- Process sales quotes and orders with Sales Order Agent
- Item availability in Sales Order Agent (preview)
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.

