Where ERP Agents Stop

The group controller had the release notes open in one window and the month-end checklist in the other. Two of the group's markets run Business Central. The third still runs the local ledger it had before the acquisition, and cash arrives as statement files from four banks. Her question was short: now that Microsoft ships 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 vendor, proposes lines and matches them to purchase order lines, and turns an approved draft into a purchase invoice.

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

Dynamics 365 Finance has an Account Reconciliation Agent, also in preview. It "evaluates exceptions and provides a recommended action for each one", for differences between subledgers and the general ledger. The first releases cover accounts payable, accounts receivable, tax and bank.

None of this is a demonstration. It runs in the products, under the products' security model, with each agent acting 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 are the ones that say what the agents do not do.

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

These read less like gaps than like 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 ERP.

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

In her group, that left the agents useful for most of the supplier invoices and for the reconciliation of the subledgers in the two Business Central markets. It left untouched the work that actually decided when the close finished: the intercompany balances between the three companies, the statement lines from four banks against open items in three ledgers, and the explanation of why the group's numbers agreed on the last day.

The bill arrives per action

The agents are billed in Copilot Credits, 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 processing 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, the routine checks that are pure arithmetic, a quantity against a receipt or a total against a control figure, belong in ordinary code, where they cost nothing per run. Second, the close calendar needs the credit balance on it. An agent that pauses on the twenty-ninth because the month's capacity ran out is a close risk, and it should be planned like one.

Design around them, not against them

The plan we gave the controller had three parts.

Use the native agent inside each ERP. Where Business Central's agent covers the work, turn it on and let it carry the routine invoices and quotes. It is maintained by the vendor, it follows the product's permissions, and nobody in the group has to own its code.

Build only the layer they cannot see. One cross-system layer reads the three ledgers and the four banks' statement files, holds the intercompany rules the group's finance team already applies, and prepares the matches and the exceptions for a person. It does not repeat what the native agents do. It starts where their documentation goes quiet.

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

The first month

We suggested starting small and 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 posted. Where the drafts match, that company's routine invoices can move to the agent. Where they do not, the reasons show which suppliers or layouts still need a person.

The second step was the cross-system layer, scoped to one job: the intercompany balances between the three companies. It was the item that most often decided the last day of the close, so it was where engineering time bought the most. The bank statements came after it, once the layer had held through a close.