What can the Procurement Agent not do yet?

Microsoft publishes part of the answer in a list, and almost nobody quotes it. That is unusual and it is generous — a vendor naming its own gaps is doing your scoping for you. For a manufacturer, the four unsupported scenarios on that list are not edge cases. They are Tuesday. And the list is not the whole boundary: the harder limits are documented on other pages, in ones and twos.

What it does, stated fairly first

The Procurement Agent is [PRP] — production-ready preview, so usable in production but still on prerelease terms, which is a real distinction to carry into a steering meeting. It has two capability sets, and you can enable either or both.

Supplier communications handles purchase-order email traffic in both directions. Outbound, it generates follow-ups — confirm this order, why is this late — and can be configured to send immediately or to save as drafts for human review. Inbound, it reads vendor email, works out whether a message is a confirmation or a change request, identifies the affected purchase orders, extracts field-level changes, and surfaces them so the purchaser reviews only the delta.

The scenarios it handles are more sophisticated than the summary suggests:

Increase or decrease order quantity — Reads the email body and PDF attachments; identifies the impacted purchase order and line
Cancel quantity or line — Matches the message to the correct purchase order and lines, for one line or several
Price increase or decrease — Summarises old versus new unit price where available, plus any rationale given
Cancel balance — Detects that a supplier will not fulfil the remaining open balance
Updating confirmed delivery date — Extracts the date change from the email or attachment and links it to the correct order
Updating confirmed shipping date (ETA based on ETD) — Detects which date the supplier gave; Microsoft says the agent can learn to infer or derive the receiving ETA (estimated time of arrival) from the ETD (estimated time of departure) using agreed transit-time assumptions
Match unit of measure — Recognises a packs-versus-each mismatch and still extracts the intent of the change
Follow up for not confirmed purchase order — Identifies orders unconfirmed past a defined threshold, such as seven days, and prompts follow-up
Follow up on delayed purchase order — Identifies orders delayed beyond a defined threshold and prompts follow-up

Reading PDF attachments, working forward from a departure date, and coping with a unit-of-measure mismatch are genuinely useful. This is not a thin product.

The four it cannot do yet

Microsoft's framing sentence matters as much as the list. The documentation says "The agent doesn't currently support the following scenarios", and closes each item with "This scenario isn't yet supported." Those are hedges, and they are Microsoft's. Here are the four, under Microsoft's own headings (supplier communications features of the Procurement Agent):

Splitting a line into multiple deliveries — Microsoft's example is a supplier proposing to ship 30 now and 70 later.
Changing site for delivery receipt for specific line — a different site or warehouse for one line.
Changing vendor for a specific line — the same supplier asking to ship from a different operating entity or account.
Changing vendor for the purchase order — the same request, for the whole order.

Now sit those beside a real manufacturing week. A split delivery is the single most common thing a supplier proposes when they cannot meet a date in full — it is the compromise that keeps a line running. A site change is what happens when the receiving plant changes because production moved. Both are routine, and both fall outside the agent's supported scenarios today.

The consequence is not that the agent is useless. It is that your automation rate assumption is wrong if you did not read this list. An honest scoping conversation puts these four on the first slide, because they determine what proportion of your inbound vendor mail still lands on a human.

The limits that are not on the list

The four-item list covers inbound email change scenarios. Three further constraints sit on other pages and bind just as hard.

The agent reads incoming PDF attachments and not Word or Excel documents — if a vendor confirms on a spreadsheet, that attachment is not parsed. Change detection is scoped to six fields: quantity, unit of measure, price, confirmation, delivery date and cancellation (review and apply purchase order changes received in vendor emails). And impact simulation accepts only a changed confirmed receipt date or quantity, so it will not simulate a site change or a vendor change either.

Read the list, then read the pages around it. The list alone under-states the boundary.

The naming is inconsistent, and it is Microsoft's inconsistency

Microsoft's conceptual documentation is clear: the Procurement Agent has two capabilities, supplier communications and impact analysis, and you can enable either or both. Supplier communications is a capability, not a separate product.

The product surface has not caught up. The agent library entry is still named Speed up updates in purchase orders with Supplier communications agent, and the navigation is Procurement and sourcing > (Preview) Supplier Communications Agent > (Preview) Emails from vendors (review and apply purchase order changes received in vendor emails). So a procurement team saying "Supplier Communications Agent" is reading its own screen, not a bad partner summary. Use the capability name in your own documents, expect the older label in the UI, and do not turn it into a correction.

Impact analysis, and the feature nobody talks about

The second capability set answers a different question: does this change actually matter?

The mechanism is worth knowing because it is the ERP doing something an email parser could not. Impact analysis traces the changed supply through markings and peggings — the links that tie a specific supply to a specific demand — then checks that trace against confirmed incoming supply and projected on-hand inventory. It looks at sales orders, production orders, transfer orders and inventory levels, and classifies each change as Has impact or No impact, with the detail behind it.

It runs automatically on two configured sources only: change requests arriving as emails through supplier communications, and change requests submitted through the vendor collaboration interface. A change that reaches you any other way needs a person to start the analysis.

The underrated part is impact simulation: test a change that never arrived by email or through the vendor collaboration interface, and change nothing in the system while you do it. Microsoft lists four of what it calls "some key use cases" — trialling the feature before using it on live supplier change requests, proactively testing at-risk or high-priority orders, evaluating whether a supplier's proposed expedite actually resolves the impact, and evaluating changes received through channels that do not automatically trigger an analysis (simulate whether purchase order changes have impact).

That last one is the quiet win. A supplier phones your buyer, and the buyer runs the simulation instead of tracing pegging by hand. It is still the agent and it still consumes credits — Microsoft lists impact simulation as a Procurement Agent capability and meters impact analysis the same way whether an email triggers it or a person does. What it does not need is a vendor message.

The human stays in the loop by design

Walk the combined workflow and notice where it ends: send the order, follow up, receive the confirmation, receive a change request with the changed fields surfaced, see the downstream impact — and then a person decides. Accept and update, follow up with the supplier, cancel, or inform stakeholders.

Nothing here posts a purchase-order change unattended. Sell it internally as decision triage, because that is what it is, and because promising unattended handling of supplier changes is a promise the product does not make and your buyers would not want.

The cost trap Microsoft names

One configuration decision drives spend, and it is documented rather than discovered. Microsoft's own example: configure supplier communications to run on incoming emails from all vendors in a shared mailbox, configure impact analysis to run on vendor emails, and impact analysis consumes credits when any vendor sends an email about purchase order changes (impact analysis overview).

The meter has two parts. Impact analysis carries a fixed cost each time the agent runs plus a variable cost that depends on the number of line changes communicated — so a noisy supplier base costs you on both halves. The lever is the vendor scope on the agent configuration page: Specific vendors rather than Any vendor, unless you have modelled the volume.

The counter-argument

"These gaps will close. Every one of them is an obvious candidate for the next wave. Pilot now and grow into it."

Probably right, and piloting now is a reasonable decision — this is [PRP], which exists precisely so you can use it in production while it matures. The direction of travel is not in doubt.

Two cautions on the reasoning, though. Nobody outside Microsoft knows the sequence: the current published plan is 2026 release wave 1, which runs to September 2026, and it lists nothing for any of these four — its only procurement-related entries are Procurement Agent impact analysis, in public preview since 24 April 2026, and Supplier Engagement (Supply Chain Management, 2026 release wave 1 planned features). Any roadmap for the four is inference rather than information. And the business case has to survive the current state, because a case built on the assumption that split deliveries get handled next quarter is a case built on a rumour. Pilot on what ships, plan on what ships, and let the gaps closing be upside rather than a dependency.

What to do this week

Pull a week of inbound vendor email and tally how many messages are split deliveries, site changes or vendor changes. That count is the share the agent will not touch, measured on your own traffic rather than assumed.
Check how supplier communications is scoped in your configuration — by vendor, or across a whole shared mailbox. If it is the mailbox, that is a cost finding as well as a noise one.
Run one impact simulation on an at-risk purchase order. Microsoft's simulation accepts a changed confirmed receipt date or quantity, and it changes nothing in the system. It needs no vendor contact, it does consume credits, and it is the fastest way to show a procurement team what the product actually does.

Where we would draw the line

We would not build a business case on an automation rate without first counting the four unsupported scenarios in a real week of mail — that count is the difference between a credible case and an embarrassing one. We would not enable impact analysis across a whole shared mailbox before modelling volume. And we would not describe this agent as handling supplier changes end to end, because the product does not claim that and the person we said it to will find out.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Counting a week of vendor mail against the four gaps is the honest way to size this. If you want a second pair of eyes on the tally, we will do it with you on a call. https://cognilium.ai

Sources

More on this: AI inside Dynamics 365, and where Copilot stops.

What can the Procurement Agent not do yet?