Business Central Payables Agent: setup step by step, what it actually does, and its limitations before you switch it on

The Payables Agent reads incoming vendor invoices, matches them to purchase orders and receipts, and drafts the purchase invoice for a person to approve. How to set it up, what it needs (E-Documents, POs, permissions), how it's billed, what it will not do, and the review workflow that keeps auditors comfortable.

Short answer: the Payables Agent is an autonomous agent in Business Central that takes an incoming vendor invoice — from the E-Documents inbox or a monitored mailbox — identifies the vendor, matches it to the purchase order and receipt, drafts the purchase invoice with accounts and dimensions, and puts it in a review queue for a person to approve. It is not a chatbot and it is not extensible: you configure it, you don't program it. It needs three things to be useful: purchase orders in the system, the E-Documents framework configured, and a person assigned to review. It's billed by consumption (Copilot credits per processed document), not per user, and it's cloud-only. Version 29 improved matching on line amounts and expected receipt dates and lets it finalise drafts according to your receive-on-invoice setup. Here's the setup, the limits, and what to decide before enabling it.

What it does, precisely

Ingests a vendor invoice: PDF from a mailbox, or a structured e-document (Peppol, EDI).
Identifies the vendor by tax ID, name and address against your vendor list.
Extracts header and lines: numbers, dates, amounts, item or description.
Matches lines to open purchase order lines and receipts — by item, quantity, price and expected receipt date (29 uses line amounts too).
Drafts the purchase invoice: vendor, lines linked to PO, GL accounts and dimensions from the PO or vendor defaults, due date from terms.
Flags what didn't match, with the specific reason.
Queues it for review. A person approves, corrects or rejects. Nothing posts without that step unless you configure it to.

Prerequisites

Purchase orders. If invoices arrive with no PO to match, the agent can extract and draft but not verify. It becomes a faster way to approve unverified invoices. Why purchasing discipline comes first.
E-Documents framework configured — a service for incoming documents (mailbox connector for PDFs, or a Peppol access point). Setup guide.
Vendor master data with tax IDs; the agent matches on them.
Copilot enabled in the environment and Copilot credits (consumption billing) available.
Cloud. On-premises gets none of this.
Availability in your environment's country and language — check the current list; it has been expanding by wave.

Setup

Agents page → Payables Agent → Set up.
Access: which user account the agent acts as, and its permission sets. Give it what a clerk would have — vendor, purchase document, e-document permissions — no more.
Source: the E-Document service (mailbox or network) it watches.
Matching policy: tolerance on price and quantity; whether to match receipts or orders only; how to handle invoices with no PO (draft and flag vs. reject).
Reviewers: who sees the queue. The review bar on lists and documents (new in 29) shows where an agent needs a person.
Finalisation: whether the agent can move a fully matched draft to "ready to post" or must always stop at review. Start with "always review".
Test with ten real invoices in a sandbox. Look at what it got wrong; it's usually vendor data or PO quality, not the agent.

Limitations, stated plainly

Not extensible. You cannot add tools, custom logic or new steps to it. If you need that, the path is the MCP server and Agent Designer, not this agent.
PO-centric. Recurring invoices without POs (rent, utilities, subscriptions) are handled by templates, not by the agent's matching.
Reads what's there. Dirty vendor records and POs with vague lines produce weak matches. The agent surfaces data quality; it doesn't fix it.
Consumption billing. Credits per document. Cheap per invoice, but budget it, and watch the first month.
Language and country availability varies; confirm before promising anyone.
Not a workflow engine. Approvals beyond the review step use standard approval workflows.

The review workflow auditors accept

Agent drafts → reviewer approves (or corrects) → optional approval workflow by amount → post → payment run. Every step is logged with who and when. The agent's proposal and the human's change are both in the audit trail. That is the design that answers "who approved this?" — and it's configuration.

Consumption and ROI, briefly

At roughly 8-15 minutes of manual handling per invoice, the labour alone is $6-11 per invoice at loaded rates; the agent's consumption is a fraction of a dollar. The full case, with duplicates and discounts, is here. Payback is measured in weeks when POs exist — and we'll say so if they don't.

FAQ

Can it post automatically? Yes if configured for fully matched documents. Recommended starting point: no. Expand after a month of clean results.

Does it learn from corrections? It improves matching with your data over time; it isn't a model you train. Corrections mostly improve your master data, which improves it.

What about the Expense Agent and Sales Order Agent? Same pattern — configure, review, approve — for expense claims (mileage, receipts, policy checks) and for orders arriving by email. Same billing model.

Is this the same as Copilot? No. Copilot is assistance inside the UI; agents run autonomously on a queue and wait for approval. Both are included in the cloud licence; agents are billed by use.

Want the Payables Agent running on your invoices in a month? Free assessment, no commitment — starting with whether your POs are ready for it.

Bramvia · bramvia.net