Where ERP Agents Stop

The group controller had Microsoft's release notes open in one window and the month-end checklist in the other. Two of the group's countries run Business Central, a Microsoft ERP: the business system that holds a company's orders, invoices and accounts. The third still keeps its books in the local system it had before the acquisition, and payments arrive from four banks as statement files, the banks' lists of money in and out. Her question was short: now that Microsoft ships AI agents for invoices and reconciliation, which of the work we planned do we still need?

Some of the planned work had just become unnecessary. Most of the hard part had not moved.

What shipped, in the vendor's own terms

Business Central now has a Payables Agent, listed as generally available. Microsoft describes it as an agent that "monitors mailboxes for incoming vendor invoices, uses AI to analyze invoice content, and shows invoice drafts to agent supervisors for review." It reads PDF invoices from a Microsoft 365 mailbox, identifies the supplier, proposes the invoice lines and matches them to what was ordered, and turns an approved draft into a supplier invoice in the system.

Beside it sit a Sales Order Agent and an Expense Agent; the table below sets the four side by side.

Dynamics 365 Finance, Microsoft's other finance ERP, has an Account Reconciliation Agent, also in preview. Reconciliation means checking that the detailed lists, such as what each supplier and customer is owed, add up to the totals in the main books. The agent "evaluates exceptions and provides a recommended action for each one". The first releases cover supplier and customer balances, tax and bank.

None of this is a demonstration. It runs inside the products, under their security rules, with each agent working as its own user, so its work shows up in the same Created By and Modified By fields as a person's.

What they leave to people, on purpose

The most useful lines in the documentation say what the agents do not do.

The Payables Agent "doesn't post purchase invoices": it never enters an invoice into the books, which is the step that makes it final and payable. It has no approval flow of its own. A supplier it creates stays blocked until someone releases it, and the documentation is plain that supplier bank details are confirmed the way they always have been, with a call to the supplier. The Sales Order Agent drafts a quote first, even when the customer asks for an order. The reconciliation agent recommends a fix for each difference; a person accepts it, reverses it, links the transactions or accepts the difference.

This reads less like a gap than a design choice: the agent prepares, a person commits, and the record shows which was which. It is where a careful finance team would draw the line, and worth keeping even when a later release lets you move it.

Where they stop

For the controller, the boundary that mattered was the edge of each system.

These agents work in Business Central online or Dynamics 365 Finance, on the data those systems hold. Invoices arrive as PDFs through a monitored Microsoft 365 mailbox. There is one Payables Agent per company. The documentation says nothing about other vendors' systems, about local books kept after an acquisition, or about bank statement files, and that silence is the boundary. The agents don't claim to work there, so they should not be planned as if they do.

In her group, that left the agents useful for most supplier invoices and for reconciliation within the two Business Central countries. It left untouched the work that actually decided when the month-end close, finalising and checking the month's accounts, was done: the amounts the three companies owe each other, matching statement lines from four banks against unpaid invoices in three sets of books, and explaining why the group's numbers agreed on the last day.

The bill arrives per action

The agents are billed in Copilot Credits, Microsoft's usage units, per action. Microsoft's own example for the Payables Agent counts 50 credits to process an invoice and 5 for each line, so 100 invoices of three lines a month come to 6,500 credits. When the credits run out, the agent stops taking new invoices and picks up the backlog when capacity returns.

Two design consequences follow, and neither is about the price, which we leave to the licensing conversation. First, routine checks that are pure arithmetic, a quantity against a delivery or a total against an expected figure, belong in ordinary code, where they cost nothing per run. Second, the month-end calendar needs the credit balance on it. An agent that pauses on the twenty-ninth because the month's capacity ran out is a risk to the close, and should be planned like one.

Design around them, not against them

The plan we gave the controller had three parts.

Use the built-in agent inside each system. Where Business Central's agent covers the work, turn it on and let it carry the routine invoices and quotes. The vendor maintains it, it follows the product's permissions, and nobody in the group has to own its code.

Build only the layer they cannot see. One layer across systems reads the three sets of books and the four banks' statement files, holds the rules the group's finance team already applies to money between its own companies, and prepares the matches and the exceptions for a person. It does not repeat what the built-in agents do. It starts where their documentation goes quiet.

Keep one evidence trail. Each built-in agent already records its actions under its own user name. The cross-system layer records its proposals and the reviewer's decisions the same way, against the same documents. At month-end the controller can follow a number from the bank line to the entry in the books, through whichever agent or person touched it, in one trail rather than three. The approval itself stays in the business system, with the people who already own it.

The first month

We suggested starting small, on her own numbers. The Payables Agent has a trial mode that processes up to 50 invoices without using billable credits, so the first step cost nothing: run it on one company's invoices from a month that is already closed and compare its drafts with what the team actually entered. Where the drafts match, that company's routine invoices can move to the agent. Where they don't, the reasons show which suppliers or invoice layouts still need a person.

The second step was the cross-system layer, scoped to one job: the amounts the three companies owe each other. That item most often decided the last day of the close, so it was where engineering time bought the most. The bank statements came next, once the layer had held through one close.