Can AI turn an emailed quote request into a Business…

Can AI turn an emailed quote request into a Business Central quote?

Yes. Microsoft ships it, it is generally available, and if you run Business Central you already have it.

So the useful question is which requests it handles, which it hands back, and how a person is meant to know the difference — because a system right about thirty-seven lines and quietly wrong about three has not saved anyone an afternoon.

This is the eight steps a request passes through, and the one thing deciding whether the output can be sent without re-reading every line.

For the owner or sales lead at a distributor that quotes from a catalogue, and the Business Central partner they will ask. 8 minute read.

Yes, and Microsoft already ships it

Sales Order Agent [GA] runs inside Business Central. Microsoft's description:

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

There is no implementation project: "the agent is readily available in the product." You point it at a mailbox and designate who reviews its work. It bills through Copilot Credits, and when those run out "it stops processing new emails."

Its matching runs in three layers, and the first does most of the work:

"Exact identifier match by item number, vendor item number, GTIN, or cross-references. Exact identifier matches have the highest confidence."

Attributes come second, fuzzy search third, across eight tables including Item Reference — where the codes your customers use for your products live.

A person still presses send: "The agent always involves designated Business Central users to review and approve all outgoing messages before it sends them to customers." That is the right design, and it is the one Microsoft chose.

The eight steps a request actually passes through

Whatever reads the request, the same work happens in the same order. Naming the steps is what lets you say where a request stopped.

Intake — The request is in one place, whatever channel it arrived on
One shape — It is in a common form, and the original is still attached to every line
Identify — You know which customer is asking
Extract — Requested lines are separated from everything else that was said
Resolve — Each line points at a specific item you actually sell
Price — The line carries this customer's price, and a decision about where to buy it
Review — A person checks the lines that need checking, and only those
Send — The answer goes back on the channel it arrived on, and the quote lands in the ERP

Steps 1 to 3 look like plumbing. A request failing at step 3 cannot be priced at all.

Two places a request dies before it is ever a line

One queue, or no clock. A distributor fielding email, an attachment, an EDI message and a photograph has as many queues as channels and no single answer to "what have we not replied to yet?" Requests are rarely lost because somebody misread them, but because nobody saw them ageing. Chapter 1.

Price hangs off identity. A contract price, a customer price group or a quantity break cannot be applied until you know who is asking — until then a line is quoted at list, which is the wrong number. Microsoft is precise about how it resolves identity, and about the limit:

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

The restriction is deliberate — it "prevents unauthorized parties from impersonating a customer by using a similar name" — and it is a sound trade. It also means an unrecorded address, a forwarded message or a purchasing assistant writing on a customer's behalf stops the run. Chapter 2 is about that moment.

The two hard parts: what they meant, and which item it is

Somewhere in a real request is a sentence like "same as the last order for the Kelso site, plus twenty more of the elbows", and another saying the insulation is no longer wanted.

Both name a product. Both name a quantity. Neither is an order line. One points at history; the other deletes something. Send either to a catalogue and you get a row nobody asked for — or a change they did ask for that never arrives. Chapters 3 and 4 take that apart.

Then the matching, hard for reasons that stack: customers use their own names and superseded codes, the same item often exists several times in one catalogue under different suppliers, and "like last time" is answerable only from that customer's order history.

A match a reviewer cannot check is a match a reviewer cannot trust. The row carries how it was found, how far ahead of second place it finished, and the customer's own words underneath — because two lines can both look certain while one was a coin toss between entries differing only in supplier. Chapter 6 is that panel; chapter 5 is the row where nothing matched.

Every documented failure produces a quote that looks correct

This is Microsoft's documentation, not our opinion. The process page carries a section headed "Scenarios impacting reliability in handling customer requests". Four entries:

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 example asks for washing powder and gets a washing machine.

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 [PP]: "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 — all four produce a quote a reviewer scrolls past.

Which is why the question that matters is not what a system extracted. It is what it is unsure about, line by line.

Microsoft shows 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.

What those four pages do not describe is a ranking — a per-line score telling a reviewer which line is least safe, so attention goes there first. Work is surfaced as task-level Needs Attention steps, and at the availability step, "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.

That gap is the subject of chapters 7 and 8, and it is the difference between checking three lines and re-reading forty.

The questions this cluster answers

1 — Why should every quote request land in one queue, whatever channel it arrived on?
2 — Why can't you price a line until you know who is asking?
3 — Is a sentence in a quote email a product line or an instruction?
4 — Why does a correction in a follow-up email get lost?
5 — What should happen when a customer's words match nothing in your catalogue?
6 — How do you show a reviewer why a line matched?
7 — Why does a quote that looks correct cost the most?
8 — How should an AI quoting system decide which lines a human must check?
9 — Does choosing the supplier belong to procurement, or to quoting?
10 — What should an AI system write back into Business Central, and what should it never touch?
11 — What does Business Central's Sales Order Agent not do?
12 — Sales Order Agent or a companion quoting workspace — which request goes where?
13 — When is an AI quoting system the wrong thing to build?

Where this stops, and what we are not claiming

Microsoft's agent is good at the case it was built for: an Exchange email from a registered contact, a modest number of lines, no variant, no question about where to buy. Its 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 11 lists them all; chapter 12 sorts between them.

Nothing here touches stock or the ledger. Microsoft draws the same line: 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." Chapter 10 is about volunteering that early.

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.

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/

Wondering which of your quote requests would come back needing a person? Book a 15-minute call and we will walk the eight steps against your own inbound, on your data if you bring it. No deck.

Can AI turn an emailed quote request into a Business Central quote?