TL;DR
It reads PDF attachments in a monitored mailbox, extracts with Azure Document Intelligence, and drafts an invoice. What it skips is the more useful list.
It reads PDF attachments arriving in a monitored mailbox, extracts them with Azure Document Intelligence, and drafts a purchase invoice for a person to finalise. What it skips is the more useful list — and Microsoft publishes all of it.
This matters beyond payables: it is the reference implementation for any document-to-record agent in Business Central.
What actually triggers it?
An email dispatcher, not a schedule and not a button. Microsoft describes the mechanism directly:
"The agent uses an internal email dispatcher running as a background task to continuously monitor a designated mailbox for incoming vendor invoices as PDF documents. The dispatcher triggers the agent to perform tasks and then imports the PDF document into Inbound E-Documents."
Each PDF becomes its own unit of work. "Each PDF document found in an email becomes an entry in Inbound E-Documents… A distinct agent task processes each entry."
And the mailbox advice is more interesting than it looks:
"We recommend you use a shared mailbox that you keep as an internal-only mailbox and don't expose this mailbox to your vendors… by not exposing invoices to vendors, your employees become the first to review and identify potential fraud, while also minimizing unnecessary information for the agent to handle."
Microsoft is telling you to put a human between the sender and the agent. They go further on ownership: "The monitored mailbox should only be attended from within Business Central" and "Users shouldn't access the monitored mailbox from Outlook." There is also a warning against sharing a mailbox with the Sales Order Agent, because "it can cause conflicts with ownership of incoming emails."
How does it read the document?
Optical character recognition, then a model — and Microsoft names the service:
"The PDF is sent for OCR (Optical Character Recognition) data extraction with Azure Document Intelligence, and the result is stored in the same E-Document record."
It is allowed to be unsure, and that is a feature. PDFs it cannot classify are marked "unknown document type", filterable as a view on the Inbound E-Documents page. "The agent helps categorize imported PDF documents when it's uncertain if the PDF is a vendor invoice."
Uncertainty about the vendor stops it outright. If it cannot identify the vendor confidently, the agent halts and asks. A supervisor can then instruct it to create the vendor from the extracted details — and Microsoft is careful about what happens next:
"When the agent creates a new vendor, the Blocked field on the vendor card is set to All… leaving the newly created vendor in a blocked state ensures no invoicing processing can happen until the vendor is unblocked. The agent itself doesn't provide any capabilities for vendor approvals."
How does it actually enter the data?
This is the part worth reading twice, because it is not an API integration.
"Conceptually, the agent interacts with Business Central features like a Business Central user. The agent gets general instructions in natural language that outline how to handle vendor invoices. It uses UI metadata, like captions, tooltips, and other properties, along with data on Business Central pages and its own instructions, to decide each step needed to finish the task. Starting from the designated Role Center, the agent goes through pages, selects UI actions, and enters data as a user does."
The consequence Microsoft draws from that is the important one:
"This approach lets the agent stay flexible and adaptable because its interaction surface and steps aren't hardcoded. Instead, AI decides them based on the context of each step. This flexibility lets the agent find and interact with relevant custom fields and actions."
An agent that drives the UI inherits your customisations for free. If your vendor card carries fields an ISV added, the agent can see and use them — where a hardcoded integration would need extending. It also "can try to automatically fix validation errors by processing displayed error messages and adjusting the input."
The draft explains itself. The purchase document draft is "where the agent explains why it made certain field value suggestions", with a tip on each field that "describes the agent's reasoning behind setting the field's value." Reasoning shown at the field, not buried in a log.
What does it refuse to do?
The limits are published, and this is the list to design against.
| Constraint | Microsoft's words |
|---|---|
| File type | "The agent only processes emails with PDF attachments" |
| Attachments per email | "skips emails with more than 10 attachments" |
| Page count | "doesn't process PDFs with more than 10 pages" |
| File size | "doesn't process PDFs larger than 5 MB" |
| Daily email volume | "doesn't process more than 100 emails per day" |
| Daily invoice volume | "doesn't process more than 500 invoices per day" |
Two whole capabilities are named as unsupported: "Approval flows" and "Anomaly detection." Approvals are a separate Business Central mechanism with its own events, conditions and responses — the agent simply does not drive them.
And it never posts. Microsoft's own summary of the flow is that drafts go to supervisors for review "so invoices are ready for approval and posting" — the agent stops at an invoice, and posting stays a human action.
Who finalises is worth reading carefully, because the page describes both. The process flow lists the agent itself at step eleven — "Payables Agent: Finalizes the purchase document draft into a purchase invoice" — while the draft section describes the supervisor doing it: "when you're done reviewing, you finalize the invoice."
What settles it is the note on the flow diagram. The review steps "are intended to be optional depending on configuration. In the public preview release, these steps aren't optional." Either way, "After you finalize a draft, it's linked to the purchase invoice and is no longer editable."
The agent surface is also moving quickly — Business Central shipped a generally available MCP server, a cross-agent task pane and a third first-party agent in a single wave: what shipped, and where the release plans went.
One more constraint people miss: "This Copilot feature is validated and supported in English only. While it can be used in other languages, it might not function as intended." The agent also consumes Copilot Credits, so a billing model has to exist before it runs.
What does this teach you about contract review?
That the hard infrastructure is built, and the document is the part that is not.
Every ingredient a contract agent needs is already shipped and proven here: a trigger on arriving email, OCR extraction through Azure Document Intelligence, a natural-language instruction set, an agent that drives the UI as a permissioned user, reasoning shown per field, and a draft a human must finalise. That is not a roadmap — it is running in accounts payable today.
Four things transfer directly, and one does not:
- The mailbox pattern transfers. Third-party agreements arrive by email exactly as invoices do.
- The confidence stop transfers. "Halt and ask" is the right behaviour when a clause is ambiguous, and escalation should fire on the trigger, not on a score.
- The blocked-by-default pattern transfers. A new counterparty should be unusable until a person clears it.
- Drafting rather than posting transfers, and it is the whole governance answer for legal work.
- The page cap does not. An invoice fits comfortably. A master services agreement does not, and Microsoft applies the same page ceiling in the agent development toolkit — so it is a platform characteristic rather than one agent's quirk.
Which is why contract work needs its own extraction path rather than the built-in one: what you can and cannot build with Agent Designer sets out where that line falls.
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/
Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.
If your agreements arrive in a mailbox the way your invoices do, the same pattern applies and the extraction is the part that changes. Bring your longest agreement to a 15-minute call.
Sources
- Payables Agent Overview — Business Central ·
ms.date2026-05-03, updated 2026-07-08 - Attachment capabilities and limitations (preview) — Business Central ·
ms.date2026-05-03
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "internal email dispatcher running as a background task to continuously monitor a designated mailbox" | T1 — verbatim | payables-agent, fetched 2026-09-10 | PASS — the trigger claim |
| 2 | 1 | Each PDF becomes an Inbound E-Documents entry; a distinct task per entry | T1 — verbatim ×2 | Same page | PASS — form name copied character-exact |
| 3 | 1 | Shared internal mailbox recommended; fraud rationale; Outlook warning; Sales Order Agent conflict | T1 — verbatim ×4 | Same page, Use a shared mailbox… and Caution | PASS |
| 4 | 2 | "sent for OCR… with Azure Document Intelligence, and the result is stored in the same E-Document record" | T1 — verbatim | Same page | PASS |
| 5 | 2 | "unknown document type" view; agent categorises when uncertain | T1 — verbatim ×2 | Same page | PASS |
| 6 | 2 | New vendor gets Blocked = All; "The agent itself doesn't provide any capabilities for vendor approvals" | T1 — verbatim ×2 | Same page, Note | PASS |
| 7 | 3 | The agent "interacts with Business Central features like a Business Central user", uses UI metadata, walks from the Role Center | T1 — verbatim, long quotation | Same page, General agent operations | PASS — load-bearing |
| 8 | 3 | "interaction surface and steps aren't hardcoded"; reaches "custom fields and actions" | T1 — verbatim ×2 | Same page | PASS |
| 9 | 3 | Inheriting ISV customisations "for free" | T2 — ours, an engineering reading of claim 8, marked as ours | — | PASS |
| 10 | 3 | Per-field reasoning tips in the draft | T1 — verbatim ×2 | Same page, Finalizing the purchase document draft | PASS |
| 11 | 4 | Six document/usage constraints, quoted individually | T1 — verbatim ×6 | Same page, Limitations | PASS |
| 12 | 4 | "Approval flows" and "Anomaly detection" listed as unsupported | T1 — verbatim | Same page, Feature limitations | PASS — a documented absence, not one we inferred |
| 13 | 4 | The agent stops at an invoice "ready for approval and posting"; finalised drafts are non-editable | T1 — verbatim ×2 | Same page | PASS |
| 13b | 4 | Who finalises is described both ways on the same page — agent at step 11, supervisor in the draft section — and the review steps "aren't optional" in public preview | T1 — verbatim ×3, a Microsoft-vs-Microsoft ambiguity reported rather than resolved by us | Same page, process flow + Finalizing the purchase document draft | PASS — a first draft of this article claimed flatly that a person finalises. The page does not say only that |
| 14 | 4 | English-only validation; Copilot Credits | T1 — verbatim ×2 | Same page | PASS |
| 15 | 5 | The page ceiling is a platform characteristic, not one agent's quirk | T1 — the same limit appears on a second, independent page | ai-development-toolkit-attachments, fetched 2026-09-10 | PASS — cross-confirmed on two pages |
| 16 | 5 | What transfers to contract work | T2 — ours, design reading, no product claim | — | PASS |
Tier summary: 15 × T1 (all verbatim), 2 × T2 — 0 × T4.
Both sources fetched on 2026-09-10 before any claim was written. The page-count limit is the one claim carried by two independent Microsoft pages, which is why §5 can call it a platform characteristic rather than a payables quirk — that inference would not be supportable from one page.
The absences here are Microsoft's own, not ours. "Approval flows" and "Anomaly detection" appear under Microsoft's Feature limitations heading. We are quoting a published limitation list rather than reporting a search that found nothing — the strongest form an absence claim can take.
No figures of ours. Every number is Microsoft's published constraint, quoted. No digits appear in either lifted block, so the page ceiling is described there in words.
Feature status. The Payables Agent overview does not carry a preview banner; the development-toolkit page it is compared against does, and §5 does not blur them. No claim is made about the agent being preview or GA beyond what its own page states.
Disclosure: the CTA asks whether agreements arrive by mailbox. No demo link, no self-inspection.
