How to connect AI chat tools to your ERP and other back-office systems (without losing control)

How do you connect AI tools to your ERP and other critical finance systems? Chat-based AI tools, including ChatGPT, Claude and Copilot, connect to systems of record through MCP (Model Context Protocol), which tells an LLM what system operations are available and how to use them. MCP servers can be built by the system vendor, your IT team or a third-party provider. For finance, the decision comes down to functional capabilities and the governance model.

Why should finance organizations adopt AI?

Ask a CFO what they hope AI will do for their finance organization, and they’ll likely give you the same answer they gave for every past technological advancement that’s happened during their career. They want to close the books faster. Get better insights, sooner. Lower transaction costs. Reduce errors. More effectively enable the business to grow.

The only difference is their expectation. Leaders truly believe AI is going to transform their organization, despite many not knowing how exactly or how soon.

Most finance teams already have ChatGPT, Claude or Copilot, and despite few seeing substantial ROI yet, most see the potential. A critical missing link for most, though, is that those tools can’t reach the systems where the work happens.

When it comes to securely connecting your AI chat tools to the systems your back office runs on, you have options. The option you choose could be the difference between an org that transforms finance operations entirely, and one that sees modest productivity gains.

What does it mean to connect AI to a system of record?

For enterprises with real-world operations, the back office has to do work that spans multiple systems. Finance teams work across the ERP (sometimes multiple), bank accounts, the procurement system, the CRM, custom business applications and a handful of ERP modules/point solutions. The analysis and judgment happen between them, in Excel workbooks, email chains and chat threads.

Before any of that, someone downloads, compiles and uploads. ChatGPT, Claude and Copilot can do that work, but only with a way to read from and write to the systems themselves.

That access has to be governed. Reading carries data risk: payroll, vendor bank details, customer records. Pulling a trial balance or summarizing open invoices is useful, as long as each person’s permissions are set correctly and your agreement with the model provider protects your data.

Writing carries financial risk. A model that can post a journal entry or release a payment is acting on the business, and every control that currently applies to a person doing that work has to also apply to the model.

Can I build my own AI finance integration?

AI has made building prototypes incredibly accessible. An analyst who has never shipped software can use Codex or Claude Code to mock up an app that displays the supplier’s rate card next to an open invoice and highlights discrepancies. If the demo works, the instinct that follows is understandable: if I can build this myself, why would I buy anything?

Building a working prototype is useful, but there’s a critical gap between a clever demo and a system finance can run on. Anything that touches a system of record has to clear a bar that IT and audit set for good reason: authenticated access, scoped permissions, a record of who did what and a way to catch a write before it does damage. Meeting that bar is most of the work, and it’s the part a prototype skips.

So the useful question is not whether you can connect AI to your systems. You can. The question is how to do it in a way that satisfies IT, compliance and the controller.

How do AI tools get access to enterprise finance systems?

ChatGPT, Claude and Copilot reach other systems through MCP (Model Context Protocol), an open standard. An MCP server lists a system’s functions in a form the model can read. The model picks the ones a request needs, and the server runs them against the system’s API.

In Claude and ChatGPT, an admin adds the MCP server as a connector. In Copilot, IT publishes it inside an agent built in Copilot Studio or the Microsoft 365 Agents Toolkit, and operators reach it in Teams or Copilot.

Any developer can build an MCP server, including the system/application vendor, your own IT team or a third-party provider. The decision to use what your vendors offer, build your own or buy a third-party MCP server comes down to what functionality you need, when you need it and who’s on the hook to maintain it.

Vendor-built: the system vendor ships the server. The company that makes your system publishes the MCP server and decides which functions it exposes. As of October 2026, systems like NetSuite, Sage Intacct, Microsoft Business Central and Coupa have all shipped MCP servers, but the scope varies widely. NetSuite’s can create and update records. Sage Intacct’s is read-only, and Business Central’s is read-only by default. Acumatica has said an official one won’t arrive before 2027.

For a team standardized on one of these systems, the vendor’s server is usually the default option, as it comes from a vendor they already trust and asks little of IT.

IT-built: your team builds the server. Your team builds a server to expose capabilities, one system operation at a time.

Take something as routine as entering a supplier’s bill for goods received in Acumatica. Exposing that single process to an AI chatbot means setting up a dedicated integration user with only the permissions it needs, targeting the right version of Acumatica’s API, creating the bill with each line tied back to the purchase receipt and then releasing it. Release runs in the background, so the integration has to keep checking until the bill actually posts or fails. It also has to make sure a retry can’t create the same bill twice. Only then is that operation wrapped as a single tool the model is allowed to call.

This is the modern version of a pattern most IT teams already know. It’s the same logic as the workflow automations and point-to-point integrations that have connected finance systems for years. Only in this case, your AI tool invokes the function instead of the workflow triggering it or the user clicking a button in the UI.

Third-party: an integration or platform provider builds the MCP server. Some third-party vendors, such as integration providers and iPaaS solutions, may offer MCP servers with catalogs of connectors across dozens or hundreds of apps. In some cases, enabling a connection is as simple as scoping access and turning it on, but legacy tools may require more involved configuration.

Each approach has trade-offs that limit what finance gets from AI and how fast it gets there.

What’s the problem with vendor-built AI connectors for finance?

Vendor-built connectors are the path of least resistance, and for single-system work they can be enough. But back-office operations rarely run within one system, so the potential value of your ERP vendor’s MCP server is limited.

The coverage limit: one connector per system, at the vendor’s scope

A vendor connector covers one system, at the depth that vendor chooses to expose. One might allow read-only access. Another might expose thirty different write operations, but not the one you need.

Finance work spans systems, so a close that touches the ERP, the bank, a billing platform and a procurement tool needs four connectors of four different shapes, and the reconciliation logic that stitches them together lives in none of them.

Coverage also runs out at the edges of your stack. End-of-life on-premises products, such as Dynamics GP and SL or older Sage versions, have no vendor connector. In some cases the AI capability becomes the reason to migrate, turning the promise of AI into a lever for a costly upgrade the team wasn’t planning. Microsoft ends GP support at the end of 2029 and points customers to Business Central, which has an MCP server. GP doesn’t.

What are the limits of IT-built AI integrations in finance systems?

The IT-built path gives you more control and, potentially, more coverage as compared to using vendor-built MCP servers. When your team builds the integration, your team decides exactly which operation is exposed, what or who is allowed to invoke it and under what controls, and a risk-averse controller can sign off on it with confidence. This is why the pattern has held up in finance for years.

The range limit: one build at a time

Each integration covers a single operation, and the next one is a fresh request in a queue that already has a backlog. The older form factors, like a slash command wired to one Salesforce update in one channel, never scaled to the range of things a finance team actually does.

The upkeep limit: every build is a standing commitment

An integration isn’t done when it ships. It has to be maintained as APIs change and processes shift, and that work lands on a team already measured on other priorities. And as your org’s AI adoption increases and matures, operators will ask for more coverage across more systems.

The governance limit: more capabilities mean more sprawl

The more systems and functionality you expose to AI, the harder it gets to manage the sprawl from a governance perspective. Being careful means moving slowly while pressure to show ROI grows. A laissez-faire approach creates risk, much of it unknown given how new AI is.

What limits apply to every MCP connection?

Whoever builds it, a standard MCP server hands the model a list of tools and leaves the planning to the model. Two limits follow, for vendor-built, IT-built and third-party servers alike.

The replanning limit: every run starts from scratch

The model works out which systems and tools to use, and in what order, each time a request comes in, even with saved instructions. For an occasional question, this doesn’t matter. For work a team does hundreds of times a day, it adds up to inference cost and waiting time.

The reliability limit: the steps change from run to run

AI is probabilistic, so two runs of the same task can take different steps. Cross-system work adds steps and multiplies the variation. A control that runs differently each time is hard to test and hard to rely on.

How can finance teams connect AI to their systems safely?

The vendor path is fast to turn on but stops at one system. The IT-built path gives control, but requires significant resources to build and maintain each connection. Third-party catalogs give breadth with generic operations.

Actions by CoPlane gives finance a single MCP server that connects the team’s AI tools to the systems they work across.

An Action is a named operation with its own permissions and record. Through the MCP server, a user with sufficient permissions can invoke an Action to:

• run an operation in an external system, such as creating a vendor in the ERP
• query an external system, such as pulling a report
• start a CoPlane workflow or agent, such as to process an invoice
• check a business rule, such as a vendor’s price variance tolerance
• complete a human-in-the-loop task assigned to them
• analyze operational performance for processes running through CoPlane

Teams already running workflows on CoPlane use all six from day one. From Claude, ChatGPT or Copilot, they ask which invoices are waiting on a PO match, check a vendor’s variance tolerance and clear the task assigned to them. Teams new to CoPlane start with operations in their systems, and each process they move onto CoPlane adds to what the AI can reach.

Each Action is a named Python function, written with AI by your team, ours or both. Identity, permissions, credentials, approval enforcement and the record are built once in the platform, and each Action handles its own system’s specifics, such as retries and duplicate checks. Where a system has no API, an Action works through its portal, a file drop or a scheduled extract and runs the same steps every time.

CoPlane runs in your cloud or ours. Credentials stay in CoPlane and never reach the AI tool or the person asking. The model only sees the Actions the person asking is allowed to use, so it chooses from a short list instead of a full catalog.

With CoPlane, you decide exactly what the AI can do and who can do it, down to the individual user and operation. Approval can be required on any Action: a staff accountant’s entries can route to the controller before they post, while the controller posts directly.

Every Action call is recorded in one place: who called it, with what inputs and what came back. When something needs explaining later, the record is one query rather than a forensic project across every system involved.

Most software is something you buy instead of building. CoPlane is the platform you buy so that you can build. You implement it once, with the controls IT has signed off on, and from there your team has room to work inside a boundary everyone has already agreed to. The security review happens once. After that, a new Action is a build on approved ground, not a new security review.

For work that has to run the same way every time, the same Actions become Processes: named sequences that run on a schedule or on request, with a full trace of every run. Processes launch October 27.

Comparing ways to connect AI to your systems of record

What are finance controls for AI agents?

Finance controls for AI agents do three jobs: limit what the agent can do on its own, require a person’s approval before consequential writes post and keep one record of every action. Regardless of which method you choose, connecting AI to your systems is only the first step. The next is trusting what it does. That requires a few guardrails.

Constraint keeps the AI from improvising

Permission alone doesn’t guarantee correctness. A perfectly permissioned agent can still post to the wrong account or match a payment to the wrong invoice. The fix is to limit how much the agent has to figure out on its own. A registered operation that runs the same way every time leaves little room for error. The model supplies the inputs, so validations and reviews are still required for sensitive operations. An agent reasoning freely through a task from scratch has more room to get it wrong.

The safer pattern uses AI reasoning only where judgment is genuinely needed, and locks everything else into a fixed, repeatable operation.

Human review catches consequential writes before they land

Before a payment releases or an entry above a set threshold posts, a person approves it. That approval should be logged, along with what the person saw when they made the call.

This is human-in-the-loop review, and it’s the standard control for any write with real consequences. And rather than using AI to make that call in the moment, your team should decide upfront which writes need this step.

A complete audit trail answers for what happened

Something will eventually go wrong. When it does, identifying the root cause as quickly as possible is critical to ensure the issue doesn’t happen again.

Fast root cause analysis requires keeping unified records of what operation(s) ran, how they were triggered and who’s the accountable party. Without a complete, unified audit log, root causing an issue means pulling logs from the ERP, the AI tool and any other system involved, and piecing the story together manually.

The better approach records everything to the same log automatically. The operator, the inputs, approvals, the operations executed within implicated systems, and the result. With that information in one place, root cause analysis becomes a single query instead of a cross-system investigation.

Most importantly, a person needs to stay accountable for everything that happens.

FAQ: AI in finance

Can AI agents post journal entries or move money on their own? Technically yes, but a person should approve payments and entries above a set threshold before they post. The real control is how narrowly access is scoped, not the model itself.

Is human-in-the-loop approval required for AI finance operations? Not by default, but it’s the standard control for consequential writes. Which operations require a human approver before they post is set by policy, per operation, rather than left to the model.

Is my ERP’s built-in AI enough? For work inside that ERP, it can be. Finance work crosses the ERP, the bank and the portals, so it needs a connection that reaches all of them.

Is it safe to connect AI to your ERP? Safety is a function of how access is designed, not of the AI tool. What the AI can reach, what it can act on unsupervised and whether there’s a record all come down to the connection layer.

What’s the difference between AI grounding and AI taking action? Grounding is read-only retrieval, chatting with your data. Taking action is a write with consequences, such as posting an entry or releasing a payment. Write access is the harder problem and where controls matter most.

What finance tasks can AI actually do today? Look things up, pull and report, match and reconcile, draft entries and act with approval. See what CoPlane Actions can do.

Do you need SOX controls for AI in finance? If you’re subject to SOX, yes. Existing control frameworks still apply when the actor is an agent. Segregation of duties is tested most directly: the rules that separate who creates from who approves have to hold whether a person or an agent is doing the work.

Who is responsible when an AI agent makes a financial error? A person, always. Accountability doesn’t move to the AI, which is why traceability back to who invoked the operation and who approved it matters.

Do you need an AI-native ERP to use AI in finance? No. Most AI-native ERPs today are built for software and AI companies, where the work is subscriptions, billing and revenue recognition. Few yet handle inventory, receiving or logistics. For a company with real-world operations, replacing the ERP is also expensive, slow and risky. Connecting AI to the systems you already run gets the work done now and keeps the option to move later.

See how CoPlane connects AI to the systems your finance team already runs. Read the Actions launch announcement →