An ERP agent proposes a purchase order.
The manager has two buttons: Approve and Reject.
That is not a useful approval process. It is a transfer of risk.
Once an AI agent can propose a write to the system of record, the manager needs more than a summary and a green button. The manager needs enough evidence to make a responsible decision without reconstructing the agent’s work from emails, attachments, supplier records and transaction screens.
That makes the review packet—not the transaction form—the manager’s essential work surface.
Microsoft’s recent Dynamics 365 update says its ERP plugin for Copilot Cowork and ERP MCP server can work with ERP data, actions and attachments.[1] In a sourcing example reported by CXM, an agent reads vendor emails and PDF bids, scores the bids against ERP criteria, recommends a supplier and raises the purchase order after a manager approves the proposed action.[2]
This is a vendor example, not independent proof of business results. But it illustrates an important design change.
The human is no longer entering every field. The human is deciding whether the proposed transaction should enter the business record.
That decision deserves a proper packet.
Approval is not the same as informed approval
A human checkpoint can still be badly designed.
If the manager has to open four applications, compare three attachments and search the supplier history before deciding, the agent has not removed the work. It has moved the work into an unstructured investigation.
If the manager approves from a one-line summary, the workflow may be fast but brittle. Important context stays hidden until something goes wrong.
The right objective is not to keep a human somewhere in the flow. It is to give the accountable human the smallest complete set of information needed to decide.
For a write-capable ERP agent, that set can be organised into seven parts.
1. Objective
Start with the business outcome the agent was asked to achieve.
For example:
Select a supplier for 500 units of Item X, required by 15 October, within the approved budget and supplier policy.
The objective tells the manager what “good” means. Without it, a recommendation can look reasonable while optimising the wrong constraint.
Keep this field short. It should state the desired result, deadline and important boundaries—not repeat the entire workflow.
2. Evidence
Show the evidence used to reach the recommendation.
For a sourcing decision, that may include:
- the request for quotation;
- the bids received;
- delivery dates;
- approved-supplier status;
- payment terms;
- relevant supplier-performance records;
- the policy or scoring rule applied.
The manager should be able to open the original evidence from the packet. A generated summary helps with speed, but it should not replace access to the source.
This is especially important when documents disagree or a field was extracted from an attachment.
3. Proposed write
Show exactly what will change in the ERP.
Do not say, “Create the purchase order.”
Show the supplier, items, quantities, unit prices, currency, tax treatment, delivery location, required date, payment terms and any linked project or cost centre.
The difference matters. A manager can approve an intention while missing an incorrect field. The packet should make the proposed record visible before it becomes the official record.
A useful implementation also highlights fields that the agent inferred rather than copied directly from an approved source.
4. Affected records
ERP transactions rarely stand alone.
A purchase order may affect budgets, inventory planning, production schedules, cash forecasts, supplier commitments and downstream approvals. The packet should list the records or processes that will be created, updated or triggered.
This does not require a technical dependency graph on every approval. It requires a practical impact summary.
For example:
- creates one purchase order;
- commits S$18,500 against the operations budget;
- updates expected inventory availability;
- triggers a supplier notification;
- creates a receiving task for the warehouse team.
The manager is approving the downstream effect, not only the first write.
5. Exceptions
A good review packet does not hide uncertainty.
List what did not fit the normal path:
- one bid arrived after the deadline;
- the lowest-cost supplier has weaker delivery performance;
- a required certificate expires before delivery;
- the recommended price exceeds the previous purchase by 8%;
- one attachment could not be read reliably.
Exceptions tell the manager where judgment is needed. If there are no exceptions, state that the workflow found none against the named checks. Do not imply that “no exception detected” means “no risk exists.”
6. Cost or exposure
Show the financial and operational consequence of the decision.
The direct transaction value is only the starting point. Depending on the workflow, the packet may also show budget variance, foreign-exchange exposure, late-delivery impact, cancellation terms, concentration with one supplier or the cost of a manual correction.
The point is not to turn every purchase order into a board paper. The depth of the packet should match the consequence of the write.
A low-value routine order may need a compact packet. A large, unusual or irreversible commitment needs more evidence and a higher approval level.
7. Reversal path
Before approval, show what happens if the write is wrong.
Can the purchase order be cancelled? Has anything already been sent to the supplier? Would reversal create another accounting entry? Who owns the recovery? Is there a deadline after which the decision becomes difficult or expensive to undo?
Reversibility should influence both the approval threshold and the information presented.
A manager can move faster when a safe reversal path is clear. When reversal is difficult, the packet should slow the decision down and escalate it.
The manager’s job changes—but accountability does not disappear
A well-designed ERP agent should reduce repetitive checking and data entry. It should not turn the manager into a ceremonial approver.
The manager’s work becomes more concentrated:
- define what evidence is required;
- decide which exceptions need escalation;
- set approval limits;
- review consequential proposals;
- own the outcome when judgment is exercised.
That is the Agent Boss role in practical terms. The agent prepares the decision. The manager remains accountable for the business commitment.
Microsoft’s roadmap also describes finance capabilities such as suggestion summaries, limits and notifications for agent-supported work.[1] Those features are useful, but each company still has to define what a decision-ready packet means for its own policies, risk and data.
The domain expert should design that packet. Finance should define the evidence for a journal or payment. Procurement should define the evidence for supplier selection. Operations should define the acceptable exceptions for inventory and fulfilment.
Pilot one approval queue
Do not begin by redesigning every ERP approval.
Choose one narrow queue with clear rules and meaningful volume—for example, routine purchase orders below a defined threshold.
For the first pilot:
- define the seven fields in the review packet;
- specify which sources the agent may use;
- separate copied facts from inferred values;
- set exception and escalation rules;
- log the proposal, evidence, decision and final write;
- test the reversal procedure;
- measure review time, exception rate and correction rate.
Only expand the agent’s permissions when managers can make faster decisions without losing visibility or accountability.
The important question is not whether the agent can write to the ERP.
It is whether the manager can see enough to approve that write responsibly.
Sources
[1] https://www.microsoft.com/en-us/dynamics-365/blog/business-leader/2026/09/23/build-the-future-of-agentic-erp-with-new-microsoft-dynamics-365-capabilities [2] https://cxm.world/customer-experience/agentic-erp-microsoft-dynamics-365-agents