Connect ChatGPT or Claude to Business Central: four things to solve

You can connect ChatGPT or Claude to Business Central today. Microsoft lists both as clients that comply with the Model Context Protocol specification, and the Business Central MCP server accepts them. The connection is the easy part.

Four problems remain after the connection works. This page names each one, shows how it appears, and gives the control that solves it.

Can ChatGPT read Business Central data?

Yes. Microsoft's MCP server exposes your Business Central API pages to MCP-compliant clients. Microsoft names Copilot Studio, GitHub Copilot, Claude, ChatGPT and MCP Inspector.

Microsoft hosts such as Visual Studio Code and Copilot Studio use a preregistered application. For a non-Microsoft client you must register your own application in Microsoft Entra ID.

After that, an assistant can list your customers, read your items and, if an administrator allows it, create and post documents.

Problem 1: the permission you granted is not the permission you think

Microsoft states that all MCP operations are performed with your user identity and permissions. That statement holds at the Business Central end.

The application registration is the part you own. Security guidance on the Model Context Protocol names the confused deputy as a central risk of the pattern: a server acts with its own privileges instead of the privileges of the person who asked. In practice, the application registration is where the privilege gets too wide.

What to do. Register one application for each use. Scope it to the person, not to the department. Use audience-bound tokens so a token for one server cannot be replayed against another. Test with a user who holds narrow permissions. An administrator sees everything, so an administrator is the worst test account you can pick.

Problem 2: the audit record names an identity, not an intention

Business Central records who performed each action. That is correct and it is useful. It is also less than a finance team needs.

An audit record says that a user updated a customer. It does not say which question produced that update, which rows the assistant read first, or which sentence the person acted on. When something goes wrong three weeks later, the audit record tells you what changed and not why.

What to do. Keep the conversation with the action. Whatever platform you put in front of the connector must store the question, the tool calls, the parameters and the result, and it must keep them for a period you set. If the assistant runs in a client you do not control, that record does not exist.

Problem 3: a truncated read looks exactly like a complete one

A query that returns 500 rows of a 3,901-row result looks finished. The client receives a page. The model receives a list. Neither one is told that rows remain, unless something tells it.

The model then writes a total. The total is arithmetic over a sample, and it is wrong by an amount nobody can see.

What to do. Require two things from any read: the number of records returned and a flag that states whether more remain. Then require the answer to repeat that limit in the sentence. A system that aggregates a truncated read without saying so will be wrong on your largest tables, which are the tables your largest questions use.

Problem 4: the model writes the number

This is the problem that does not appear in a demonstration and does appear in a board pack.

A language model produces the sentence you read. If the model holds the values, the model can change them. Research on financial hallucination describes the failure as subtle rather than obvious: a figure attributed to the wrong period, a threshold recalled instead of retrieved, a total that is plausible and wrong.

Permission control does not help here. A model with perfect permissions can still write a number that no row contains.

What to do. Separate the query from the value. Let the model write the query. Let the platform run it, render the rows, and tell the model only that a result appeared. Then check each figure in the written answer against the rows that the query returned during the same turn, and replace anything that fails.

A comparison of the two paths

Neither column is wrong. A developer who explores a sandbox should use the first one. A finance team that acts on the answers needs the second.

What we would tell you to do first

Connect a sandbox and try it. The experience is instructive, and it will show you how much of the work is the connection and how much is everything else.

Then ask the assistant a question whose answer you already know, over a table with more rows than one page. Ask it how many records it read. The answer to that second question tells you whether you can trust the first.