That is exactly what makes it a sensible place to prove an agent works. It is also what makes the proof narrower than it looks, because every one of those constants was doing quiet work in the result.
The governance half of this — that extending an agent’s scope to a second legal entity is a change recorded in the wrong register, logged as an administrative action when its effect is a financial control — we have taken up before. Multi-entity ERP agents raise a prior question: what changes about the work.
Three things do, and none are visible from inside one entity.
Correct Is a Property of the Entity, Not the Process
In a single-entity pilot, “correct” is a fixed target. The agent either coded the invoice the right way or it did not.
Across a group, correct attaches to the entity, and that is how the product is meant to be configured. Microsoft’s globalization guidance tells implementers to “enable this functionality based on the primary address of the active legal entity” — regulatory behavior is configured per entity, not per process. The Electronic Invoicing service then has its own country-by-country availability, and the gaps are instructive: Poland is listed as preview though its mandate went live in early 2026, and the page says not to use the service for Brazil at all.
This is not an agent problem as such — a human accounts payable process ported from Milan to Munich fails the same way. What differs is the failure mode. A person meeting an unfamiliar regime hits a visible wall and asks someone. An agent generalizes from the pattern it was configured against, silently and at volume, producing output that looks exactly like the output that was right last month.
The divergence underneath is not temporary untidiness awaiting harmonization. Take the two poles.
- Italy clears centrally, and has since 2019. Invoices pass through the Revenue Agency’s Sistema di Interscambio, which validates and delivers them — and, per the European Commission, performs only basic checks and does not store them. Turnover exemptions were removed in 2024, so the regime has been in force for seven years and universal for two.
- Germany does not clear at all. Exchange is decentralized against the European standard, with no central platform. Receipt has been required since 2025; issuance arrives in 2027 for larger businesses and 2028 for the rest.
France added a third pattern on 1 September 2026, routing through approved platforms rather than a state clearinghouse, and splitting the obligation to receive from the obligation to issue. Which produces the kind of detail a rollout plan has to carry: a French SME subsidiary must currently receive and not yet issue, and its German sister is in the same position for different reasons and on a different clock — receipt since 2025, issuance in 2027.
Nor does it resolve on a known date. The VAT in the Digital Age package, adopted in March 2025, applies digital reporting requirements to cross-border business-to-business transactions from 1 July 2030, and by 1 January 2035 requires member states with a domestic real-time transaction reporting obligation to align those systems with the EU standard. That is narrower than convergence: what aligns is domestic reporting, not invoice exchange architecture. Germany has no reporting stream to align at all. The three mechanisms above may outlast 2035.
Authority Stops Being Obvious
The second change is harder, because the product makes it frictionless.
Intercompany accounting in Finance and Operations is configured as a directional pair. The setup documentation is explicit that the relationship names an originating and a destination company, that “the Intercompany accounting setup is shared, so all legal entities can see the setup,” and that the configuration specifies the journal name “to use when the transaction is created in the destination company.” Post as a user active in the originating entity and an entry appears in another legal entity’s ledger. Microsoft documents no acceptance step in the destination company.
Centralized payments goes further: “Any legal entity in the hierarchy can process payments on behalf of any other legal entity in the hierarchy.” That one is opt-in, needing an organization hierarchy with the centralized payments purpose assigned plus intercompany accounting — which is the point. Someone chose it.
Both are useful. Both are also one entity acting for another. When a person does it there is at least a person — a name, a role in the group structure, a reporting line a board could follow. When an agent configured by group finance does it on a schedule, whose authority it acted under has no obvious answer. This is a near-term problem rather than a current one: as set out below, agent coverage of intercompany is not yet shipped.
It is not only a process question. The general principle in company law is that a director owes duties to the company on whose board they sit rather than to the group, and the OECD surveyed 45 jurisdictions on how group boards handle it. The International Corporate Governance Network — an investor governance body, not a legal authority — summarized the majority position as no group-interest exception, and added a line that reads oddly next to a scheduled agent: directors of group companies “may not simply rubber stamp decisions taken by the group’s leadership.”
The practical version is answerable. Business Central ships the checkpoint: intercompany transactions land in the partner’s inbox, where the partner can accept, reject and return, or cancel and delete. It also ships an Auto. Accept Transactions setting per partner, usable where partners share a database, which removes the human step. So a counterparty review step is a real product concept rather than a governance fantasy — and it is configurable, which means it gets decided by whoever set up the partner record.
The Scope Question for Multi-Entity ERP Agents Is Unanswered
The third change ought to be the simplest and is not.
In the functional areas of Finance and Operations that use a company ID, the company is the data security boundary. Microsoft’s organization documentation is careful about the scope: “in these functional areas, companies are used as a boundary for data security. Users can access data only for the company that they’re currently signed in to.” Not everything is company-bounded — the intercompany setup above is explicitly shared — but where the boundary does apply, in a group with real separation between entities, it is a control. On a separate and older guidance page, last updated in early 2024, Microsoft notes that roles are assigned to users “in either all legal entities or within specific legal entities.”
An agent that works across the group has to cross that boundary. That is the access a multi-entity estate is partly structured to withhold, and the convenient configuration is the one that grants it everywhere.
Business Central documents what that means for an agent. Its agent permissions guidance — still marked prerelease — states that agents are modeled as users, that “it’s possible to assign permissions to an agent for specific companies,” that a task considers only permissions defined for that company or all companies, and that “this design ensures agents never exceed the privileges of the user who scheduled the task.” Its generally available Payables Agent setup is concrete about the same thing: “each company can have only one Payables Agent,” and where there are several, each company’s agent can be configured with its own dedicated mailbox or its own monitored subfolder.
Finance and Operations does not. Its agent management page, its responsible AI FAQ, the account reconciliation agent setup — which does specify a dedicated identity user and the roles required — and the MCP security guidance between them cover agent identity, roles and monitoring, and say nothing about legal entity scope. Not that it is restricted. Not that it is unrestricted.
One product in the family has answered the question, which shows it is answerable. For the other it has not been, and a pilot in one entity is never going to ask.
Where This Argument Is Weakest
Three counter-arguments, and the first may simply be right.
Intercompany may be where agents pay off most rather than least. Deloitte’s intercompany accounting survey — fieldwork in 2014, 81 companies, so read it as a shape rather than as today — found just over half of respondents processing intercompany manually with limited counterparty visibility, half with no defined ownership of the process, and a substantial minority carrying out-of-balance positions they closed with plugs. The three challenges cited most were poor use of technology, non-standardized processes and transaction matching. Those are automation problems, not judgment problems. And on more current evidence, the Hackett Group’s 2026 finance study puts accounts payable as the most mature finance process for AI adoption, with a third of organizations already scaling rather than piloting.
The multi-entity plumbing is also more mature than a piece like this implies. Consolidation explicitly supports multiple charts of accounts and different fiscal calendars across legal entities, mass period close runs across selected entities, dozens of localizations ship, and Business Central’s per-company agent permissions are the most complete agent authority model Microsoft documents. Cross-company data sharing is documented as a mechanism for reference and group data, with a published list of shareable tables rather than a general capability — so the data layer is ahead of the authority layer without being finished.
And the cheapest objection is the strongest. Why not prove it in one entity, then deliberately pick a maximally different second? Same finding about what fails to travel, at roughly half the setup cost. On blast radius the gap is smaller than it sounds — one narrowly scoped process running in two entities is not twice the exposure of the same process in one, and reversibility is a design choice either way. On timing it is not: the sequential version arrives later — after a business case has been signed on numbers from one jurisdiction, which is when it is least welcome. That is a claim about organizational momentum rather than a technical one, and a reader who disagrees about their own organization should discount it.
What is not yet shipped is agent coverage of the multi-entity processes themselves. The 2026 wave 1 plan for the account reconciliation agent expands it to inventory and lists fixed assets, project accounting and intercompany as future releases. Which narrows the claim. It is not that multi-entity breaks agents. It is that the plumbing arrived first, the authority model is arriving second, and a rollout today sits in the gap.
What to Add Before the Pilot Becomes a Rollout
- Write down which entity the pilot’s definition of correct came from. One sentence naming the jurisdiction and the regime. It is the thing that silently fails to travel.
- Establish the agent’s legal entity scope explicitly, in writing, whatever the product does or does not document. If it holds access across all legal entities, that is a decision, and it should have a name attached.
- Decide whether a destination entity accepts or is merely posted to. Business Central makes this a per-partner setting. In Finance and Operations, journal names can carry approval workflows, but whether one interposes on a journal generated by intercompany accounting is not documented — so establish it in your own environment rather than assuming either way.
Two more sit outside the pilot and get sequenced last when they should not be: the supervisory ceiling in a three-person finance team is not the group function’s, and an agent spanning entities on unaligned close calendars produces work nobody can reconcile. A third belongs to the audit conversation: a scope extension partway through a year can mean there was not one control operating for twelve months, which is a problem found late if at all.
The Work Underneath the Agent
Most of the above is not agent work. It is multi-entity Dynamics 365 Finance work — close design across legal entities and the configuration decisions stacked around it — with an agent added on top. That estate is what DAX Software Solutions implements and supports, and these questions get answered during implementation rather than during agent selection. We do that part — most usefully while the second entity is still a plan rather than a deployment.
Two caveats. Agent capability in Dynamics 365 moves quickly and several pages cited here are recent or marked prerelease, so verify current behavior against Microsoft Learn rather than against this article. And the tax and company-law points are general description, not advice — requirements differ by jurisdiction, entity and regulator, and the ones that matter to you belong with a professional who knows your structure.
The One Change to Make to the Pilot
Run it in two entities from the start. Pick two that differ — different country, different regime, different close date — and that are an intercompany pair, so the authority question arises inside the pilot rather than after it. Where the most different entities do not trade with each other, take the pair that does and accept less divergence; the authority question is the harder one to retrofit.
Not two processes. One process, narrowly scoped, exactly as a first pilot should be. Two entities.
It costs more setup and takes longer to produce a result. What it buys is the one thing a single-entity pilot cannot: a finding about the entity you have not automated yet.