TL;DR
The record itself, from the ERP, after the write. A success message describes an intention, and an intention is not evidence of a posted record.
The record itself, from the ERP, after the write. Not a summary, not a confirmation message, not the agent's account of what it did. An agent that says "posted successfully" has told you about its own intention, and intention is not evidence.
Why is reading back necessary at all?
Because a report of success and a successful posting are different objects.
An agent composes its reply from its own execution context. If a write partially succeeded, was rejected downstream, or landed on a different record than intended, the agent's summary can still be cheerfully positive — it is describing what it tried to do.
The only thing that settles the question is the record. Read it from the ERP after the write, and compare it to what was supposed to happen.
This is not an AI-specific principle. It is why integrations have always confirmed a write by querying it back, and why a goods-in clerk looks at the screen after pressing post. What is new is that the intermediary is fluent and persuasive, which makes its self-report easier to accept and no more reliable.
What does the platform already give you?
Attribution and ordinary processing. Both matter, and neither is a read-back.
"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."
And nothing is skipped: "Business logic, validations, and workflows aren't bypassed."
So the posting is real and it is traceable. The ERP knows who did it and applied every rule it would have applied to a person.
### What that does not tell you Attribution answers "who". Validation answers "was this legal". Neither answers "is this the record we meant to create" — a posting can be attributable, valid, and wrong. The read-back is the only step that closes that gap, and the platform does not do it for you.
What should the read-back actually contain?
Four things, and the fourth is the one usually missing.
One — the identifiers. The document number, the line, the date. Enough that a person can find the record independently, without trusting the agent's framing.
Two — the values that mattered. The quantity posted against the quantity expected, the item, the order it attached to. The comparison, not just the result.
Three — the state afterwards. What the line looks like now: fully received, partially received, still open. A read-back that reports the write but not the resulting state leaves the reader to guess the consequence.
Four — what it could not verify. If the agent checked three things and could only confirm two, the third belongs in the report. A read-back that only lists successes is a success report wearing a read-back's name.
The test for a good read-back is simple: could a reviewer who does not trust the agent use it to find and check the record themselves? If not, it is a reassurance rather than evidence.
Why report the gap at all?
Because the alternative is silent confidence, and silent confidence is what gets discovered at month-end.
An agent working through old accrual lines will hit cases it cannot settle: evidence that is not in the system, a vendor who has not replied, a receipt whose history is ambiguous. Those are correct outcomes of a careful process, not failures to hide.
And the operational value is real. A list of "could not determine" lines is exactly the list a controller needs, because it is the short list where human time is genuinely required. An agent that reports only what it resolved has deleted the most useful half of its output.
This is also the practical answer to a reasonable objection. Asked how you know an agent is not quietly guessing, the strongest reply is not an accuracy claim — it is that the agent tells you what it could not establish, every time, and you can check that list.
Where does the data actually go?
Out of the ERP and into whatever client you chose, and that is your decision to audit.
"Any data movement or retention outside the customer's finance and operations environment would be dependent on the data storage and retention policies of the agent client (for example, Microsoft Copilot Studio, Claude, Microsoft Foundry), and/or the client's access to other external systems."
Microsoft's instruction is direct: "Ensure you audit the agent client's permissions to move data to other systems and the data retention policies."
The server itself holds nothing: "The MCP server doesn't store customer data."
So the read-back lives wherever your client lives, and the retention question belongs to the platform you picked, not to Dynamics 365. If the read-back is part of your control evidence, decide deliberately where it is kept and for how long — because the ERP records the posting and has no opinion about your transcript.
Organisations do get a say in the model too. Microsoft notes that "Organizations also control which AI service and agent client they use with the MCP server."
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.
Ask any agent you are evaluating to show you the record it posted and the list of what it could not verify. If it cannot produce the second list, that is the conversation. Fifteen minutes is enough.
Sources
- Security for Dynamics 365 ERP MCP · fetched and read in full 2026-10-21
- Use MCP for finance and operations apps · fetched and read in full 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | A report of success and a successful posting are different objects | T2 — ours, the article's thesis, argued rather than asserted | — | PASS |
| 2 | 1 | This is not an AI-specific principle — integrations have always confirmed writes by querying back | T2 — ours, an engineering observation | — | PASS |
| 3 | 2 | "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" | T1 — verbatim | mcp-security | PASS |
| 4 | 2 | "Business logic, validations, and workflows aren't bypassed" | T1 — verbatim | Same page | PASS |
| 5 | 2 | A posting can be attributable, valid and wrong | T2 — ours, and the hinge of the article. Not a criticism of validation; a statement of what a rule check can and cannot know | — | PASS |
| 6 | 3 | The four contents of a read-back | T2 — ours, method. Microsoft publishes no read-back specification and the article does not imply one | — | PASS |
| 7 | 3 | The test: could a reviewer who does not trust the agent find and check the record? | T2 — ours | — | PASS |
| 8 | 4 | The unverified list is the most useful part of the output | T2 — ours, an argument. No figure attached and none implied | — | PASS |
| 9 | 5 | "would be dependent on the data storage and retention policies of the agent client (for example, Microsoft Copilot Studio, Claude, Microsoft Foundry), and/or the client's access to other external systems" | T1 — verbatim, including Microsoft's own list of example clients | mcp-security | PASS |
| 10 | 5 | "Ensure you audit the agent client's permissions to move data to other systems and the data retention policies" | T1 — verbatim | Same page | PASS |
| 11 | 5 | "The MCP server doesn't store customer data" | T1 — verbatim | Same page | PASS |
| 12 | 5 | "Organizations also control which AI service and agent client they use with the MCP server" | T1 — verbatim | Same page | PASS |
| 13 | 5 | The ERP records the posting and has no opinion about your transcript | T2 — ours, and BOUNDED. It is a statement about where the read-back is retained, resting on claim 11. Not a claim that F&O has no audit capability — it has workflow history and database logging, which are different mechanisms | — | PASS |
Tier summary: 6 × T1 (all verbatim), 7 × T2 — 0 × T4.
### ⚠️ This article is T2-heavy by necessity, and the reason is worth stating Microsoft publishes no read-back specification, because a read-back is a design pattern rather than a product feature. So §3 and §4 are ours and are labelled as ours — there is no page to cite for "what a good read-back contains", and inventing one would be the §0 defect in its purest form. What is quoted is everything the platform does supply: attribution, unbypassed validation, no data storage at the server, and the instruction to audit your client's retention. The argument built on top of those is ours, and the article never dresses it as Microsoft's.
### 🔴 One sentence this article deliberately does NOT contain The internal source document for this cluster notes that agent output "can vary from run to run, so outputs should be verified" and gives read-back as our answer. That observation is ours, from our own build notes — it is not sourced to a Microsoft page, and the description field of this article was written to say Microsoft states it. Corrected before publication. The description now attributes variability to no one and the body makes the argument on its own terms. An unsourced claim wearing a vendor's name is the exact defect §0 exists to prevent, and it nearly shipped in a metadata field nobody re-reads.🔴 No pricing. No rate, cost or currency anywhere.
No figures of ours. No accuracy claim, no error rate, no volume, no customer. §4 argues the unverified list is valuable without quantifying how often it appears — we have measured no such rate.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
