Short answer: yes, and the mechanics are not complicated. But "ChatGPT" in this question means at least three different things with different consequences for your data. A consumer app and corporate API access are not the same, and that difference decides whether you should do this at all.
The short answer
Business Central exposes data through a REST API. Any model able to call external tools can retrieve that data — provided there is a layer between them that authenticates against Business Central and executes only permitted operations. There is no technical obstacle.
The question worth answering first is different: who in this arrangement sees your ledger entries, and what are they contractually allowed to do with them.
Three ways
1. Manual copying
Someone exports data from Business Central and pastes it into a chat. This already happens in many companies, often without management's knowledge, and it is the riskiest of the three: no control over what went out, no log, no guarantees about processing. If this is happening at your company, the most useful response is not a ban but a proper tool.
2. Through an MCP server
You stand up a layer that exposes a list of permitted operations and connect a client to it. The model sees not a database but a list along the lines of "list overdue invoices" with validated parameters. Detail: Business Central MCP server guide.
3. Through the model API in your own application
You do not use the ChatGPT interface at all; your own solution calls the model API. You control exactly what goes into each request and you operate under a corporate agreement. For most companies with financial data this is the right answer.
Four decisions before you start
Each of these is more expensive to reverse later than to discuss now.
Which access route. It determines both cost and what data may pass through at all. A conversation for whoever owns data policy, not for a developer.
Which identity the integration runs as. A service account means everyone sees the same slice. Delegated access means each person sees their own. Switching between them later is a rebuild, so decide at the start.
Which data never leaves your environment. Employee personal data, specific customer fields, commercial terms of particular contracts. That list is written by the business, not by a vendor.
What the solution does when there is no data. It must say so rather than produce a plausible figure. Obvious in principle, verified by separate testing, and the point where quick pilots most often fail.
What happens to the data
| Option | Control over what leaves | Processing terms |
|---|---|---|
| Consumer app, manual copying | None | Consumer terms |
| Corporate subscription | Partial | Corporate agreement |
| Model API in your own solution | Full | Provider contract |
| Model in your own cloud | Full | Your tenant |
Enterprise tiers from the major providers contractually exclude customer data from model training. That is a contract clause rather than a property of the technology — so it gets read, not assumed. For companies needing maximum control, deploying a model in your own cloud environment removes the question entirely, at higher cost.
The part people think about less: the volume of what leaves depends on how operations are designed, not on the provider. An operation returning the three rows you need is safer than one handing over a table for the model to filter. That is an architect's decision, and it affects privacy more than the choice between vendors.
Three real risks
- Volume of data going out. A poorly designed integration sends more than the answer requires — whole tables instead of the relevant rows. Fixed by operation design, not by vendor choice.
- Access rights. If the integration runs under a service account with broad rights, every user effectively gets those rights through the chat. Decide the access model before the build, not after.
- Confident fabrication. A model that received no data tends to answer plausibly. In a financial context that is more dangerous than a refusal. The solution must be built to say "no data", and this is verified by separate testing.
When ChatGPT is the wrong tool
If a question repeats unchanged every month, you need a report or a Power BI dashboard: cheaper, faster, identical output every time. If a process is fixed and should run itself, that is a flow, not a model. A chat interface wins when the questions differ each time and cannot be anticipated.
How to do it properly
- Find out whether anyone is already copying data into a chat. Usually somebody is.
- Decide which data may leave your environment at all, and which may not.
- Choose the access route: corporate subscription, API in your own solution, or a model in your own cloud.
- Read the provider's terms on processing and training. Actually read them.
- Build a layer that exposes a list of operations rather than database access.
- Choose the Business Central authentication model — delegated access if different people must see different data.
- Verify the solution refuses to answer when it has no data.
Steps 4 and 7 are the ones most often skipped, and they are the ones that decide whether this becomes a problem.
Frequently asked questions
Will our data go into model training?
That depends on your contract with the provider, not on the technology. Enterprise tiers from the major providers contractually exclude customer data from training; consumer terms do not always. Read the terms before connecting anything.
Can we do this without development?
If you are willing to copy data manually, yes — but that is the worst option for control. Any managed connection needs a layer between the model and Business Central that authenticates and limits the operation list.
Will ChatGPT see our whole database?
No, if built correctly. The model gets access to a list of described operations with validated parameters. Calls run under a Business Central identity with a permission set, so the platform applies the same restrictions it would to a person.
What about personal data requirements?
If answers can contain personal data, the processing location and provider terms must match your obligations. Decide this during architecture and put it in writing, along with which fields must never leave your environment.
Claude, Gemini or ChatGPT — does it matter?
For the Business Central integration itself, not much: all the leading models can call external tools. The difference is in data processing terms, available deployment regions and price. Choose on those criteria, not on the name.