How to Connect Claude to Business Central: Three Patterns, and What Each One Really Costs

We published a piece on the ERP Software Blog arguing that the Copilot-versus-Claude question is the wrong one, and that organizations should think about where each AI layer fits.

The question that follows is more practical: fine, but how does that actually work, and what does it cost me?

Fair. Architecture opinions are cheap. Here’s the practical version.

There are three patterns for connecting Claude to Microsoft Dynamics 365 Business Central. I’ve listed them roughly in order of implementation effort, and I’ve included where each one breaks down, because the failure modes are usually more useful than the feature lists.

Pattern 1: Power Automate as the middle layer

What it is. A flow triggers on something — a document lands in SharePoint, an email arrives, a record changes in Business Central. The flow sends the content to Claude’s API, receives structured output back, and writes approved information into Business Central through the standard connector.

Microsoft provides a Business Central connector for Power Automate with triggers and actions to build the BC side of this. The Claude side is an HTTP call or a custom connector you define once and reuse.

When it fits. Document-shaped work where Claude isn’t independently posting financial transactions. Reading supplier certificates. Extracting terms from a contract before someone keys them in. Summarizing an inbox into a queue a human works through.

One thing to get right immediately. Your Anthropic API key is a credential, not a configuration value. It belongs in Azure Key Vault, referenced by the flow — not pasted into an HTTP action where it sits in the flow definition for anyone with maker access to read. This is a five-minute decision at the start and an incident report if you skip it.

What it actually costs. Depending on connectors and architecture, you may need standalone or premium Power Automate licensing, plus API consumption with Anthropic. At modest volume both are manageable.

The less obvious cost is ownership. Someone has to maintain the flow, understand why it failed, and know what depends on it. Flows accumulate. I’ve walked into organizations with dozens of them and little documentation.

Where it breaks. As volume, concurrency, and orchestration complexity increase, Power Automate becomes the wrong abstraction. Platform and connector throttling limits need to be designed for rather than assumed.

Owner’s take: start here when the workflow fits. It’s the cheapest way to find out whether Claude’s output is good enough to build on. If the answer is no, you’ve spent days instead of committing to a development project.

Pattern 2: A proper service layer

What it is. An Azure Function or similar service sits between Business Central and Claude. BC calls the service, another system invokes it, or it processes work asynchronously. Your prompts, validation, retries, and error handling live in code you control.

When it fits. Anything at meaningful scale, anything complex enough that maintaining it in a flow becomes painful, and anything where you need disciplined testing and version control.

This is where working with Claude gets specific. Three things belong in this layer and nowhere else:

Prompts are versioned artifacts. The prompt is business logic. When someone changes the instruction that determines how a contract clause gets classified, that change needs the same review as a code change, because it has the same consequences.

Structured output needs validation, not trust. You’ll ask Claude to return JSON. Validate it against a schema before anything touches Business Central. Decide in advance what happens when validation fails — route to a human queue, don’t retry silently and don’t write a partial record.

Confidence has to be part of the contract. Have Claude return not just the extracted value but how certain it is and what it couldn’t determine. Then set a threshold: below it, a person looks. Without this you get a system that’s right most of the time and silently wrong the rest, which is worse than one that’s obviously unreliable.

What it actually costs. This is a development project. Budget for the build, then budget for owning software — monitoring, patching, investigating failures, and understanding it when the original developer is gone. That lifecycle cost is easy to underestimate during a successful proof of concept.

Where it breaks. Credentials and secrets treated as implementation details. Use managed identities where appropriate and Key Vault for the API key.

Owner’s take: go here after a simpler prototype has shown the reasoning creates value. Building the production integration before proving the output is one of the easiest ways to spend money on the wrong problem.

Pattern 3: Business Central MCP — Claude connected directly

What it is. Business Central now ships its own Model Context Protocol server. Rather than building an integration outward, BC exposes its API pages as tools that Claude can discover and call directly.

Microsoft explicitly names Claude as a supported MCP client. Their own documentation for connecting non-Microsoft hosts walks through the app registration and uses “BC MCP – Claude” as the example name. This isn’t a workaround — it’s a documented path.

What that means in practice. Your controller opens Claude, asks which customers are over their credit limit, and gets an answer from live Business Central data. No report built, no integration written.

How the connection works. All MCP hosts connect to the same endpoint. Microsoft clients like Visual Studio Code and Copilot Studio use a preregistered application. Claude requires you to register your own multi-tenant app in Microsoft Entra ID and supply the client ID. Authentication uses OAuth 2.0 authorization code flow with PKCE.

The detail that matters most for governance: operations execute under the authenticated user’s identity, not a generic service account. Your audit trail records who did it. If Claude posts something on the controller’s behalf, the ledger reflects the controller.

The permission model. By default the MCP Server gives read-only access to exposed API pages. Write operations are off until an administrator turns them on. Configuration happens on the MCP Server Configurations page in BC, where you add API page objects and set permissions per object: read, create, modify, delete, and bound actions. You can review the complete permission model in Microsoft’s Business Central MCP Server configuration documentation.

That last permission deserves attention. Bound actions are OData actions attached to a record — including posting documents and changing statuses. So the permission model isn’t theoretical. Somebody decides, object by object, whether Claude can post.

Microsoft’s own examples show items fully read-write-delete while customers are read-and-modify only. That granularity is the value of the architecture, and also the governance responsibility that comes with it.

Where it breaks. Someone selects “Add All Standard APIs as Tools,” enables write operations, and treats the agent like a reporting tool.

There’s also a practical one: some MCP clients limit tools per agent. Copilot Studio currently caps at 70, with Dynamic Tool Mode available for larger configurations. Without understanding that, a missing tool looks like an AI reasoning problem when it’s a configuration problem.

Worth knowing before you promise a timeline: the non-Microsoft client path is newer than the Microsoft one. Microsoft publishes a BC MCP Proxy sample explicitly marked for experimentation rather than production, and connecting Claude directly against Entra-protected endpoints has had rough edges around OAuth client registration. Pilot it before you commit to it.

What it actually costs. Less custom integration development than a service layer. But not zero — you still have model costs, configuration, testing, security, monitoring, and governance. The cost moves rather than disappears. You write less plumbing and administer more permissions that can reach your ledger.

Owner’s take: this is where the architecture is heading, and where I’d want many Business Central customers to end up. It isn’t necessarily where I’d want them to start.

What I actually tell clients

1. Prove the reasoning before you build the plumbing.

Take fifty representative documents, define what a correct answer looks like, run them through Claude, and grade the output. If accuracy isn’t there, no integration pattern saves you. This is inexpensive and prevents most expensive failures.

2. Decide what Claude is allowed to do before you configure anything.

Not “AI will help with payables.” Write: Claude analyzes the document and prepares a draft; a human approves and posts. Then configure permissions to enforce it. That’s where AI governance stops being a slide and becomes architecture.

3. Keep Business Central as the system of record.

Claude reasons over your information and proposes or initiates controlled actions. It shouldn’t hold a competing copy of your customers, vendors, inventory, or transaction logic. Every architecture that violates this eventually has to answer: which system is telling the truth?

So what does each pattern really cost?

Pattern 1 — Power Automate: lower initial effort, licensing where required, Anthropic API consumption, ongoing flow ownership.

Pattern 2 — Service layer: higher development investment, cloud and model consumption, meaningful software maintenance.

Pattern 3 — MCP: potentially lower integration effort, but greater emphasis on permissions, client configuration, governance, and control.

Which is why I wouldn’t pick the architecture based on which one has the smallest Azure bill.

The part nobody puts in the proposal

All three patterns work. The technical integration usually isn’t the hardest part, and a competent Business Central team can implement any of them.

The harder problem is that you’re introducing a system that produces probabilistic, plausible output into a system of record where incorrect transactions have consequences.

The controls, approval steps, permissions, and audit trail aren’t overhead on the AI project. They are the project.

The integration may be straightforward. Designing the governance around it is where the real work begins.

Choosing the right pattern for your environment

If you’re weighing Claude, ChatGPT, Copilot, or MCP for your own Dynamics 365 Business Central environment, talk with DStrategyTech before choosing the integration pattern.

We’ll help you determine what Business Central and Copilot already solve, where a general-purpose model adds value, and how much architecture you actually need before you start building.

---

Sai Turlapati is CEO of DStrategyTech, a Michigan-based Microsoft Partner specializing in Dynamics 365 Business Central migrations, Power Platform, and AI integration.