TL;DR
Yes, if the identity it runs under is allowed to. The posting goes through the same business logic, validations and workflows as a person in the client.
Yes — if the identity it runs under is allowed to. Microsoft's ERP MCP server exposes three families of tools, and the posting travels the same path as one made by a person in the client: the same business logic, the same validations, the same workflows. What it does not get is extra permission.
Can it, really?
Yes, and the limit is the identity rather than the technology.
"The authenticated user can never do more through the MCP server than they're able to do through the finance and operations application."
So the question is never whether an agent can post a receipt. It is whether this identity is allowed to post one — and that is answered in your security configuration, not in the agent.
Microsoft is explicit that the connector adds nothing: "The MCP server doesn't elevate privilege." An identity with the right duties can post; one without cannot; and the agent changes neither case.
Through what, exactly?
Three tool families, and Microsoft names what each does:
"The Dynamics 365 ERP MCP server provides three categories of tools for working with the data and business logic of finance and operations apps."
| Family | Microsoft's description |
|---|---|
| Data tools | "enable the agent to perform standard data operations to create, read, update, and delete data in your finance and operations apps environment" |
| Form tools | "enable the agent to perform operations that are available on pages in the application" |
| Action tools | "Enable the agent to find and directly invoke classes in finance and operations apps code" |
Data tools work through entities: "Data tools in the MCP server enable the agent to work with application data through data entities."
For a product receipt, the realistic routes are data tools or form tools, and which one suits depends on whether the operation you need is exposed as an entity or lives behind a page. Form tools exist precisely because not everything is an entity.
Does posting this way skip anything?
No, and this is the sentence that matters to an auditor.
"Business logic, validations, and workflows aren't bypassed."
And the security model is the same model, not a parallel one: "MCP requests are governed by the same authentication, authorization, business logic, and data controls that apply to other finance and operations app experiences", and "It doesn't create a separate security boundary."
So a receipt posted by an agent behaves like a receipt posted by a clerk. If a validation would have stopped the clerk, it stops the agent. If a workflow would have routed it, it routes.
Attribution works the same way too: "An action that an agent takes through the MCP server is therefore attributable to the user who initiated the request, similar to an action that the same user takes in the finance and operations client."
### What this does and does not promise It promises the posting is ordinary. It does not promise the agent chose correctly. Validation catches an impossible posting; it does not catch a plausible posting of the wrong quantity. That gap is why an approval gate exists, and why the record has to be read back afterwards.
When do you need a developer?
When the logic you need is not reachable as data or as a page.
Microsoft describes the case precisely: where "the action or business logic isn't available through the entities or application client, or the agent needs direct access to the logic through code", then "a developer can write a class in finance and operations apps code to make the business logic available through the MCP server."
The developer uses a named framework: "The developer creates the class by using the AI tool framework."
For straightforward receipt posting you should not need this. Action tools earn their place when you have customised logic — a one-off validation, a company-specific posting rule — that no entity exposes. That is a build, with a developer's timeline, and it is worth knowing which side of that line your process falls on before scoping.
What should gate an agent posting?
A person, before the write — and a read-back after it.
Before: the agent shows the exact record it intends to create and waits. Not a summary, not a confidence score — the posting itself, in a form the approver can recognise. Microsoft's validations will stop the impossible; only a human stops the wrong-but-valid.
After: the agent reads the record back from the ERP and reports what it found, including anything it could not confirm. A write that is not read back is a write you are trusting on the agent's word, and that is the part worth designing carefully.
Where we are with this, honestly: we have built two agents on this pattern and they run on test data. The Teams confirmation card and the Outlook notice are designed and in build, not shipped. No published results exist for this pattern, ours or anyone's.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
If you are deciding whether your receipt posting needs a developer or just a configured identity, that is a short conversation with a definite answer. Bring the process to a 15-minute call.
Sources
- Use MCP for finance and operations apps · fetched and read in full 2026-10-21
- Security for Dynamics 365 ERP MCP · fetched and read in full 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "The authenticated user can never do more through the MCP server than they're able to do through the finance and operations application" | T1 — verbatim | mcp-security | PASS |
| 2 | 1 | "The MCP server doesn't elevate privilege" | T1 — verbatim | Same page | PASS |
| 3 | 1 | The question is about the identity, not the agent | T2 — ours, the reading of claims 1 and 2 | — | PASS |
| 4 | 2 | "The Dynamics 365 ERP MCP server provides three categories of tools for working with the data and business logic of finance and operations apps" | T1 — verbatim | copilot-mcp | PASS |
| 5 | 2 | All three families quoted — data, form, action | T1 — verbatim ×3 | Same page | PASS |
| 6 | 2 | "Data tools in the MCP server enable the agent to work with application data through data entities" | T1 — verbatim | Same page | PASS |
| 7 | 2 | Form tools exist because not everything is an entity | T2 — ours, read off the two definitions | — | PASS |
| 8 | 3 | "Business logic, validations, and workflows aren't bypassed" | T1 — verbatim | mcp-security | PASS — the article's spine |
| 9 | 3 | "MCP requests are governed by the same authentication, authorization, business logic, and data controls that apply to other finance and operations app experiences"; "It doesn't create a separate security boundary" | T1 — verbatim ×2 | Same page | PASS |
| 10 | 3 | "attributable to the user who initiated the request, similar to an action that the same user takes in the finance and operations client" | T1 — verbatim | Same page | PASS |
| 11 | 3 | Validation catches the impossible, not the wrong-but-valid | T2 — ours, and it is the most important sentence we wrote here. It is a logical consequence of validation being a rule check, not a claim about Microsoft's validation quality | — | PASS |
| 12 | 4 | "a function or business logic isn't available through the entities or application client, or the agent needs direct access to the logic through code"; "a developer can write a class in finance and operations apps code to make the business logic available through the MCP server" | T1 — verbatim ×2 | copilot-mcp | PASS |
| 13 | 4 | "The developer creates the class by using the AI tool framework" | T1 — verbatim, framework name character-exact | Same page | PASS |
| 14 | 4 | Standard receipt posting should not need action tools | T2 — ours, a scoping judgement. Hedged as "should not" rather than asserted, because it depends on the customer's customisation | — | PASS |
| 15 | 5 | The approval-before and read-back-after pattern | T2 — ours, method | — | PASS |
| 16 | 5 | Our agents run on test data; Teams and Outlook are designed and in build, not shipped | T2 — REQUIRED disclosure per the source document's guardrail table | — | PASS |
Tier summary: 11 × T1 (all verbatim), 5 × T2 — 0 × T4.
### ⚠️ Claim 11 is the one that keeps this article honest "Validation catches the impossible, not the wrong" is ours, and everything in §5 rests on it. It is not a criticism of Microsoft's validation — a validation is a rule, and a rule cannot know that a plausible quantity is the wrong quantity. Stating it is what justifies the approval gate, and without it the article would read as though "validations aren't bypassed" were a sufficient safety guarantee. It is not, and saying so is the difference between selling a gate and justifying one.
### 🔴 Guardrails applied | Rule | Compliance | |---|---| | Never "least-privilege" | Not used. The article quotes Microsoft's "doesn't elevate privilege" and talks about what an identity is permitted to do | | Never "zero middleware" | Not used | | Never "MCP builds new ERP logic" | §4 says the opposite explicitly — a developer writes the class first, and the agent then invokes it | | Never "Teams and Outlook are live" | §5 states designed and in build, not shipped | | Never a customer name, saving or percentage | None appears |
🔴 No pricing. No rate, credit figure, cost or currency anywhere.
No unbounded absence claimed. Every negative is Microsoft's own — doesn't elevate privilege, aren't bypassed, doesn't create a separate security boundary.
No figures of ours. No volume, no accuracy, no customer, no result.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
