---
title: "How does an AI agent turn an RFQ into a quote?"
canonical_url: "https://cognilium.ai/blogs/how-an-ai-agent-turns-an-rfq-into-a-quote"
slug: "how-an-ai-agent-turns-an-rfq-into-a-quote"
section: "blogs"
date_published: "2026-09-09"
date_modified: "2026-09-09"
word_count: 1705
reading_time_minutes: 8
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
entities: []
related:
  - "https://cognilium.ai/blogs/how-rfq-line-item-matching-works"
  - "https://cognilium.ai/blogs/why-quote-automation-gets-quantities-wrong"
  - "https://cognilium.ai/blogs/when-a-quote-line-matches-nothing"
---
# How does an AI agent turn an RFQ into a quote?

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.

## Key takeaways

- An RFQ agent runs five dependent steps — read, identify, match, check, quote — and each one needs the last, so a failure early is invisible late.
- Matching is layered, and the fuzzy fallback runs on the hardest lines with the weakest signal while still being asked to produce a candidate.
- Microsoft documents four ways its own agent goes wrong, and every one produces a document that looks correct — a right item at a wrong quantity, a plausible neighbour, a missing attribute, a price of zero meaning not calculated.
- The extraction is the part that works. What decides whether a quote can be sent is knowing which lines to distrust.
- Explanation and ranking are different things. Showing why a line matched does not tell a reviewer which line to open first.

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](/blogs/sales-order-agent-or-your-own-quoting-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:

1. *"Exact identifier match by item number, vendor item number, GTIN, or cross-references. Exact identifier matches have the highest confidence."*
1. *"Semantic attribute matching uses item attributes from the customer's message (such as color, material, or size) and AI to rank candidates by relevance."*
1. *"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](/blogs/how-rfq-line-item-matching-works) 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](/blogs/can-an-agent-price-without-knowing-the-customer) 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](/blogs/can-an-agent-price-without-knowing-the-customer) 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](/blogs/how-rfq-line-item-matching-works) 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](/blogs/why-quote-automation-gets-quantities-wrong) scrolls past. [Chapter 2](/blogs/why-quote-automation-gets-quantities-wrong) 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?

## 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](/blogs/sales-order-agent-or-your-own-quoting-agent) 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](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-order-agent)
- [FAQ for Sales Order Agent — Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/faqs-sales-order-taker-agent)
- [Process sales quotes and orders with Sales Order Agent](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-order-agent-process)
- [Item availability in Sales Order Agent (preview)](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-order-agent-item-availability)

This article is part of our work on [the RFQ quoting engine](/solutions/rfq-quoting-engine).

## Frequently asked questions

### What does an RFQ agent actually do?

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.

### How does it match a line to your catalogue?

This is the step everything else rests on, and Microsoft documents a three-layer strategy:

### 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.

### 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".

### What decides whether the quote can be sent?

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.

### 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.

---

Canonical HTML: https://cognilium.ai/blogs/how-an-ai-agent-turns-an-rfq-into-a-quote