Dynamics 365 Procurement Agent: What It Costs Per Run

TL;DR

The Procurement Agent in Dynamics 365 Supply Chain Management "incur[s] charges based on the number of Microsoft Copilot Studio credits you use when running it", with a fixed cost per run and a variable cost on top (Microsoft Learn).

The 2 features meter differently. Follow-up emails vary by "the number of emails the agent writes". Review-and-apply changes varies by "the number of emails the agent reads and the number of attachments those emails have".

That second one is the important sentence: your bill scales with your suppliers' behaviour, not your own. You do not control how many emails arrive or how many PDFs are attached to them.

It is a production-ready preview, which Microsoft defines as GA quality that you can go live on, kept in preview so improvements can keep shipping.

Microsoft states it "might disable Copilot-driven features for selected customers if it detects abuse of the functionality".

What is actually being charged?

Two meters running at once, and only one of them is under your control.

Microsoft's documentation is unusually direct about it. The agent "has a fixed cost per run and a variable cost that depends on the resources it consumes", billed in Copilot Studio credits. The fixed part behaves like a flag-fall: it applies each time the agent runs, regardless of how much work it finds. The variable part is where the two supplier-communication features diverge, and the difference matters more than the rates.

Feature. Fixed cost. Variable cost depends on

Follow up on purchase orders. Each time the agent runs. "the number of emails the agent writes"

Review and apply purchase order changes. Each time the agent runs. "the number of emails the agent reads and the number of attachments those emails have"

Read the second row again. The follow-up feature charges for output, which you configure. The review feature charges for input, which your suppliers generate. That is a genuinely different risk profile inside one product, and the documentation does not flag it as such.

Why does the input meter deserve more attention than the output meter?

Because you can forecast one and not the other.

Follow-up emails come from a query you write. You decide which purchase orders qualify, how often the agent runs, and what it sends. If the number surprises you, you changed something.

Review-and-apply reads whatever arrives. A supplier who sends 1 consolidated email a week costs a fraction of one who sends 5 separate messages with a PDF attached to each. Neither is doing anything wrong, and neither asked you. Some arithmetic on a mid-market distributor to show the shape:

500 purchase orders a month, with 1.5 supplier emails per order, is 750 emails read per month.

If 40% carry an attachment, that is 300 attachments processed on top of the reads.

A single supplier changing habits, splitting one confirmation email into 3, adds 250 emails a month from a decision made entirely outside your business.

None of those numbers are Microsoft's, and the credit rate per email is not published on this page. The point is the shape, not the total: this line item moves for reasons that never appear in your own planning cycle. Anyone budgeting it as a flat per-seat cost is budgeting the wrong variable.

What does "production-ready preview" actually mean?

Microsoft has been clearer about this than most vendors are about preview labels, and the definition is worth quoting because it is unusual: a production-ready preview "has the quality of a generally available (GA) feature and you can go live with it". The reason it is not GA is that "the agent is under continuous development", and Microsoft keeps the designation "so we can continue to implement improvements in the short term".

So the label is not a warning about quality. It is a statement about change cadence. You may run it in production, and the thing you run will keep moving under you. For a procurement process that is a real trade to weigh: the improvements are free, and so is the retraining every time the behaviour shifts.

Two other terms sit alongside it. The documentation is marked "prerelease documentation and is subject to change", and production-ready previews are "subject to supplemental terms of use" separate from your main agreement. Both are worth reading before a procurement team depends on the feature.

What stays under human control?

More than the framing suggests, and this is the reassuring part.

On follow-ups, the agent "can automatically send the emails right away, or it can save them as drafts that require human review before they can be sent". That is a configuration choice, not a fixed behaviour, and starting in draft mode costs nothing except the reviewing.

On inbound changes, the agent detects a requested quantity or price change, "summarizes the old versus new price (where available)" and "flags it as a commercial change requiring buyer decision or approval". It reads and proposes. A person still decides. For a price increase arriving by email with a PDF justification attached, that is the correct division of labour: the tedious part is finding and parsing it, and the consequential part is agreeing to it.

Microsoft also reserves the right to intervene: it "might disable Copilot-driven features for selected customers if it detects abuse of the functionality". Worth knowing that the switch exists on their side too.

How does this fit the wider agent-cost picture?

It fills a gap we flagged this week. Comparing how 4 ERP vendors govern agents, the most striking column was cost: only 1 of the 4 named agent spend as something you govern. Microsoft's governance tooling, the CLI and toolkit that decide what an agent may do against a 650,000-action surface, says nothing about what an agent may spend.

This page is the other half of that answer, and it is filed under the product rather than under governance. The permission to run an agent and the budget to run it at business volume live in different documents, maintained by different teams, and only one of them is in the room when someone approves the pilot.

The same split appears elsewhere in the stack. Business Central's built-in finance agents are licensed differently again, and NetSuite's rollout decides eligibility per account before cost is even a question.

What should a procurement team do before switching it on?

Count your inbound supplier email first. The review feature's bill is a function of that number and you already have it, in the mailbox the agent will read. Count a normal month before you turn anything on, so you have a denominator.

Run follow-ups in draft mode for the first cycle. It costs the same fixed run, produces the same emails, and lets a buyer see what the agent would have sent under their name.

Separate the two features in your business case. They meter differently and they fail differently. Approving them as one thing hides which is generating the cost.

Ask who owns the credit budget. Copilot Studio credits are a platform resource, and the team that approves a procurement pilot is often not the team that watches that meter.

FAQ

Is the Procurement Agent generally available?

It is a production-ready preview: Microsoft states it has GA quality and you can go live with it, and it stays in preview so improvements can keep shipping.

What exactly consumes credits?

Each run has a fixed cost. On top, follow-ups vary with emails written, and review-and-apply varies with emails read and attachments processed.

Does it send emails to suppliers without a human seeing them?

Only if configured that way. It can save them as drafts requiring review instead.

Can it change a purchase order on its own?

It detects and summarises requested changes and flags commercial ones for buyer decision or approval.

Was this called something else?

Microsoft's documentation has carried it as the Supplier Communications Agent and as supplier-communications features of the Procurement Agent. Same capability, and worth knowing when searching.

The last mile

Microsoft automates the correspondence, and that is a real saving on a genuinely tedious job. Finding the late orders and drafting the chase emails is work nobody wanted.

What the meter cannot tell you is whether accepting a supplier's proposed price increase is the optimal call for this order, at this margin, with this alternate supplier available at this lead time. The agent surfaces the change and flags it. The decision it flags is where the money is, and it is still the buyer's. Turning the recorded state into the right decision, inside the system the team already runs on, is the layer Cognilium works in.