TL;DR
The shipped agents cover defined ground and no more. Where the documented boundary falls, and what has to be built on the other side of it.
At the same place, every time: they propose and a person commits. Read the three first-party agents' published limits side by side and the differences turn out not to be about capability at all — they are about where the document came from.
What boundary do all three share?
None of them commits a transaction on its own.
The Payables Agent ends at a draft that a supervisor finalises, and Microsoft's summary of the flow is that drafts are reviewed "so invoices are ready for approval and posting." Ready for. Not posted.
The Expense Agent extracts and then hands back: "AI detects the merchant, amount, date, and category for you. You review the details and make changes if needed."
And custom agents built in the design experience inherit the same shape. Microsoft's runtime description: "It helps ensure that sensitive operations always require explicit user review and consent", with "a timeline view of all agent activities, allowing users to review what happened and why—enabling a true human-in-the-loop experience."
That is one design decision applied three times, not three separate caution settings. An agent in Business Central is built to produce something a person signs off. If you are evaluating one on whether it can run unattended end to end, you are evaluating it against a shape Microsoft did not build.
Where do they differ, and what explains it?
Approval is the sharpest split, and it is not about which agent is more mature.
| Approval routing | |
|---|---|
| Expense Agent | ✅ "Approvers can review, approve, or send back expense reports with comments" |
| Payables Agent | ❌ Approval flows named under Microsoft's own Feature limitations |
The same page that refuses approval for Payables also refuses anomaly detection — both sit under that heading, which makes them a published limitation rather than something we failed to find.
Our reading of why, and Microsoft does not state a rationale: an expense report is an internal document. The submitter and the approver both work for you, and the agent is routing between colleagues. A vendor invoice arrives from outside. Microsoft keeps that agent on the extraction side of the boundary and leaves the commitment to your own controls.
The vendor-creation behaviour says the same thing more bluntly. When the Payables Agent creates a vendor, "the Blocked field on the vendor card is set to All", because "vendors and their bank accounts are approved by having communication with the vendor and doing human callbacks… In many places, this action is a requirement for a successful audit."
Counterparty-supplied data is not trusted by default. That is the principle underneath every difference in the table.
What does none of them do?
Nothing triggers an agent you built yourself.
"there aren't yet any built-in integrations to automatically trigger these custom agents based on incoming emails, events, or scheduled recurrences (this can be done by professional developers using the APIs available in the AI Development Toolkit)."
The built-in agents have triggers — a custom one does not. The Payables and Sales Order agents watch a mailbox through an internal dispatcher. An agent you design in the wizard waits to be handed a task, unless a developer wires it to the Tasks API.
That gap is the difference between a capability and a system, and it is the single most important thing to know before promising a custom agent to anyone. Microsoft documents it plainly; it is not a discovery.
What do the limits actually have in common?
They constrain the input, not the intelligence.
Read the Payables list again and notice what kind of limit each one is: PDF only · ten attachments per email · no PDF over ten pages · none over five megabytes · daily caps. Not one of those is about whether the model understands an invoice. They are all about what shape of document is allowed to reach it.
That is a useful thing to know when something fails. If an invoice did not get processed, the first question is not did the AI misread it — it is did the document get through the door at all. Those are different failures with different fixes, and the published constraints answer the second one.
The one genuine capability limit is anomaly detection — the agent matches and extracts; it does not judge whether an invoice is suspicious. Everything else on the list is a gate, not a ceiling.
What should you design around this?
Four things, and all of them are design decisions rather than patches:
- Put the commitment step where it belongs. These agents draft. Your approval control, whether a Business Central workflow or a person, is a separate design and it is not optional for payables.
- Check document fit before configuration. If your suppliers send links or spreadsheets, no setting rescues it.
- Plan the trigger for anything custom. A wizard-built agent waits; wiring it to fire on an event is developer work against the Tasks API.
- Separate a door failure from a judgement failure when something goes wrong. The published limits tell you which one you are looking at.
And read the limits as a family rather than one agent at a time. The pattern — propose, never commit; trust internal documents further than external ones; constrain the input rather than the model — holds across all three and will almost certainly hold across the next one Microsoft ships.
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 scoping an agent that has to run on a trigger, or commit rather than propose, that is the part that needs building. Bring the workflow to a 15-minute call.
Sources
- Payables Agent Overview — Business Central ·
ms.date2026-05-03 - Expense Agent Overview for Business Central ·
ms.date2026-04-23 - Envision and design AI agents in Business Central — release plan ·
ms.date2026-06-09
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | Payables drafts are reviewed "so invoices are ready for approval and posting" | T1 — verbatim | payables-agent | PASS |
| 2 | 1 | Expense: "You review the details and make changes if needed" | T1 — verbatim | expense-agent-overview | PASS |
| 3 | 1 | Runtime: "sensitive operations always require explicit user review and consent"; timeline view; "true human-in-the-loop experience" | T1 — verbatim ×2 | Release plan | PASS |
| 4 | 1 | "one design decision applied three times" | T2 — ours, a characterisation of claims 1–3 | — | PASS |
| 5 | 2 | Expense lists approval workflows; Payables names Approval flows unsupported | T1 — verbatim ×2, two different pages, both read | Both agent pages | PASS — load-bearing contrast |
| 6 | 2 | Anomaly detection also under Feature limitations | T1 — verbatim | payables-agent | PASS |
| 7 | 2 | The internal-vs-external explanation | T2 — ours. Body says "Microsoft does not state a rationale" | — | PASS — not put in Microsoft's mouth |
| 8 | 2 | Vendor set to Blocked = All; human callbacks; audit requirement | T1 — verbatim ×2 | payables-agent | PASS |
| 9 | 3 | "there aren't yet any built-in integrations to automatically trigger these custom agents…" | T1 — verbatim | Release plan | PASS |
| 10 | 3 | Built-in agents have triggers; custom ones wait | T1 — the dispatcher is documented on payables-agent; the absence is quoted from the release plan | Both pages | PASS — presence and absence each sourced separately |
| 11 | 4 | Every Payables limit constrains input shape | T2 — ours, a reading of the published list, labelled | — | PASS |
| 12 | 4 | Anomaly detection is the one genuine capability gap on that list | T2 — ours, and bounded to the Payables limitations list, not to all agents | — | PASS — bounded inline |
| 13 | 5 | The four design points | T2 — ours, method | — | PASS |
Tier summary: 8 × T1 (all verbatim), 5 × T2 — 0 × T4.
🔴 No pricing, per the founder ruling of 2026-09-15. No credit rate, no currency, no total. The metering is a separate article and it carries none either.
### On the shape of the absence claims here This article makes three, and they are three different kinds: 1. Approval flows and anomaly detection — quoted from Microsoft's own Feature limitations heading. A published limitation list, not a search. 2. No trigger for custom agents — quoted verbatim from the release plan. Microsoft's own sentence, including the "yet". 3. *"Almost every published limit constrains the input" — ours, and bounded to the Payables list we read in full. It is not a claim about every limit Microsoft has ever published. None of the three is an unbounded negative*, which is the failure mode this article's shape is most exposed to.
Status labels. The Expense Agent is a production-ready preview; Agent Designer is public preview with general availability planned for October 2026. Neither is described as shipped. The Payables Agent overview carries no preview banner and is not called preview here.
No figures of ours. No count, no rate, no measured result.
Share this article
What Microsoft ships, what it does not, and the layer we build where a general assistant runs out.
