A customer replies "yes" to a quote by email. In Business Central, that's now enough to create a sales order. The Sales Order Agent reads the reply, matches it to the open quote, and converts it. No one on the ops team opens a screen. No one clicks approve. The order exists because an inbox got one word back.
Call this headless ERP: a Business Central workflow where an agent completes the transaction end to end, and no human has to open a screen to make it happen. Microsoft's own agents in Business Central — the Sales Order Agent, the Payables Agent — already ship headless paths today, not on a future roadmap (Microsoft Learn, 2026). A screen used to be where accountability lived by default: a login, a click, a timestamp, a name. Take the screen away and none of that appears unless something was built to replace it.
Most of the conversation about agentic Business Central features is about what the agent can now do without a person in the middle. Almost nobody is asking who owns what just happened once the person is gone. Headless without an answer to that question isn't a faster process. It's a faster way to lose the trail.
What Business Central's Sales Order Agent actually removes
Microsoft frames its Business Central agents plainly: they are "autonomous AI workers that can independently handle tasks with minimal human input," built so "their work is transparent, reviewable, and keeps people in the loop as work progresses" (Microsoft Learn, 2026-07-01). That intent shows up in how the Sales Order Agent is built. The agent "identifies the contact in Business Central, finds the request, and generates a quote for you to review and send." A person sees that quote before it leaves the building.
The review stops there. "When the contact confirms the quote, the agent converts the quote into an order," automatically, with no internal approval screen standing between the customer's reply and the posted order. The Payables Agent runs the same pattern from the other direction: it "monitors the company mailbox for vendor invoices," matches details to purchase orders and receipts, and "proposes posting accounts for unmatched lines and routing exceptions." Read that last part carefully. Matched lines post. Only the lines the agent can't match get routed to a person.
The review Microsoft built protects the quote going out. Nothing protects the order coming back in.
Where the five stages went
A governed decision moves through five stages: Signal, Route, Approve, Execute, Audit. Run the Sales Order Agent's inbound path through that model and three of the five disappear. The customer's reply is the Signal. The agent routes the confirmation to itself and executes the order conversion in the same motion — no separate party makes a decision about it. And nothing produces an Audit record built for anyone but the engineer who has to debug the tool call later.
None of that makes the Sales Order Agent broken. It makes it a feature that quietly collapsed three governance stages into one automatic step, and shipped that as a productivity win. The gap only surfaces the day someone has to answer for a specific order: a dispute, a pricing error, a compliance sample. The honest answer, at that point, is that no person decided it. A workflow decided it, and the workflow doesn't have a name.
The governance knob Microsoft did build
Give Microsoft credit here, because the correction isn't "Microsoft ignored governance." Agents built in Copilot Studio reach Business Central one of two ways (Microsoft Learn, 2026-05-03): the Business Central Connector, a low-code path that acts as the signed-in user and inherits their existing BC permissions, or the Business Central MCP Server, where the agent issues direct HTTP GET, POST, PATCH, and DELETE calls against BC API endpoints.
The MCP path carries a real write-scope control: the MCP Server Configuration, which names exactly which API pages, and which CRUD operations, an agent is allowed to use. Leave it unconfigured and the default is read-only access across every exposed API page. That's a legitimate governance primitive, more precise than most enterprise software ships for AI write access.
It answers one question only: can this agent touch this table. It says nothing about who's responsible for the specific write it made at 2:14pm on a Tuesday, for what reason, on whose authority. Scope and accountability are two different problems, and Microsoft solved the first one.
Why an execution log isn't an audit trail
Microsoft's own troubleshooting guidance for these agents is direct about what the log is for: "Use the agent's execution logs to troubleshoot tool calls and to see request/response payloads." That sentence is honest, and it's the whole problem in one line. A payload trace built to help a developer debug a broken integration is a different artifact from a record built to tell an auditor who approved a write, and why.
| Attribute | Execution log (Microsoft's framing) | Audit trail (what accountability needs) |
|---|---|---|
| Built for | A developer troubleshooting a failed tool call | An auditor or compliance reviewer with no API background |
| What it captures | Request and response payloads, tool call sequence | Who accepted the action, at what value, on what document, and why |
| Where it lives | Inside the agent's execution history, engineering-facing | Alongside the business record, readable without a developer's help |
| Default coverage | Every tool call, matched or unmatched | Only what's been explicitly designed to name an approver |
| What MCP Server Configuration controls | Nothing — it governs write scope, not logging | Nothing either — scope and accountability are separate design problems |
The difference isn't cosmetic. An auditor sampling AI-originated postings under a SOX approval review, or a customer's lawyer disputing an order nobody remembers approving, doesn't want a JSON payload. They want a name, a value, and a reason, in a form they can read without asking engineering to translate it first.
What this costs a CIO who can't answer the question
The cost doesn't show up on a line item labeled "headless ERP risk." It shows up the first time a customer disputes a sales order nobody keyed in, or an internal audit samples a batch of agent-originated postings and asks for the approval record behind each one. "The agent did it" satisfies nobody in that conversation — not compliance, not the customer, not the board member asking why write access to the ERP has no name attached to it.
One test actually surfaces the gap. For every API page your MCP Server Configuration lets an agent write to, name the accountable person behind its last write, without opening a developer log to find out. If that name doesn't exist anywhere a non-engineer can read it, the audit trail isn't missing paperwork. It never got built.
Building the record the screen used to create for free
Fixing this doesn't mean turning every headless write back into a manual approval — that undoes the point of running the agent at all. It means treating write scope and ownership as two separate design decisions instead of one. The MCP Server Configuration answers what an agent may touch. A second, deliberate step has to answer who's accountable for what it did with that access, named before the agent goes live, not reconstructed after an incident.
That second step is what decision infrastructure means in practice for a headless agent: a record that captures the Signal that triggered the write, who or what Approved it, and an Audit entry a compliance reviewer can read without a developer's help, sitting alongside the Business Central transaction rather than buried in a tool-call log. Business Central's own approvals architecture and Microsoft's Copilot documentation both stop at the write. What happens to the record after it posts is still an open design question every Business Central shop running these agents has to answer for itself.
Most teams don't know how many of these gaps they're carrying until they list every table an agent can write to and ask who owns each one.
Take the Decision Latency Diagnostic →
Frequently asked questions
What is headless ERP in Business Central?
Headless ERP describes a Business Central workflow where an AI agent completes a transaction end to end with no screen a human has to open to make it happen. Microsoft's Sales Order Agent and Payables Agent already ship headless paths today: a customer's email reply can become a posted sales order, and a matched vendor invoice can post, without anyone logging into Business Central to click approve. The screen used to be where accountability lived by default, through a login, a click, a timestamp, and a name. Remove the screen and none of that appears unless something is built to replace it.
Does Business Central's Sales Order Agent require approval before converting a quote into an order?
Only partially. Microsoft's own documentation says the Sales Order Agent identifies the contact in Business Central, finds the request, and generates a quote for a human to review and send — a person reviews the quote before it goes out. But when the contact confirms the quote, the agent converts it into an order automatically, with no internal approval screen between the customer's reply and the posted order. The review protects the outbound quote. Nothing protects the inbound conversion.
What does the MCP Server Configuration control in Business Central Copilot Studio agents?
The MCP Server Configuration names exactly which Business Central API pages, and which CRUD operations — create, read, update, delete — an agent connecting through the Business Central MCP Server is allowed to use. Leave it unconfigured and the default is read-only access across every exposed API page. It's a real write-scope control, and Microsoft built it deliberately. It answers whether an agent can touch a given table. It says nothing about who is accountable for the specific write that agent makes, or why.
Is an AI agent's execution log the same thing as an audit trail?
No. Microsoft's own guidance describes the purpose plainly: use the agent's execution logs to troubleshoot tool calls and to see request and response payloads. That's a debugging artifact, built for a developer diagnosing a broken integration. An audit trail is a different object: a record, readable without engineering help, naming who accepted a specific action, at what value, on what document, and why. A payload trace answers what the agent called. It doesn't answer who's accountable for the result.
Microsoft built the write-scope control. The ownership record is still your team's to build, before the first disputed order forces the question. For the same accountability gap on the human-approval side of Business Central, see why Business Central's approval engine can't approve anything alone.