Connecting Your ERP to iSAP Exchange via MCP
Most finance teams do not have a payments problem. They have a reconciliation problem. The payment happens in one system, the invoice lives in another, and someone spends their week matching the two by hand.
The Model Context Protocol changes what is possible there. It lets an AI assistant work directly against both systems — your ERP and your payment platform — through a defined set of tools, instead of a person copying figures between screens.
What MCP actually is
MCP is an open standard for connecting AI assistants to systems. Rather than writing bespoke integration code for every combination of assistant and application, a system exposes a set of tools — list_invoices, get_payment_status, and so on — with defined inputs and outputs. The assistant sees what is available, chooses what to call, and receives structured data back.
The practical consequence: someone in your finance team can ask "which supplier invoices over 30 days old are still unpaid, and has anything been sent for them?" and get an answer drawn from both your ERP and iSAP Exchange, without a report being built first.
Which systems this covers
The connection method differs by system. What your assistant sees does not — the same tool names and structures apply across all of them, so a query written against one system works against another.
| System | Typical connection route |
|---|---|
| SAP (S/4HANA, Business One) | OData services, or the Service Layer for Business One |
| Oracle | Fusion Cloud ERP REST APIs; E-Business Suite requires a different route |
| Microsoft Dynamics 365 | Dataverse and the Business Central APIs |
| Odoo | JSON-RPC |
| iSAP.One | Native REST API |
Each connection is configured against your environment. Versions, customisations and access policies vary enough between installations that this is a conversation rather than a download.
What it is used for
- Reconciliation. Match payments made through iSAP Exchange against invoices and ledger entries in your ERP.
- Payment status in context. Ask about an invoice and see whether payment has been sent, is in progress, or has settled — without leaving your system of record.
- Cross-border payroll preparation. Pull payroll data for a run, in the format the disbursement requires.
- Treasury visibility. Balances across currencies and entities, in one answer.
- eInvoicing. Connect payment initiation to the invoice record, so the document and the transaction stay in step.
Read-only first, deliberately
Every integration begins read-only. Reading data and moving money are different categories of risk, and we do not treat them as a spectrum.
Where write operations are introduced later, they are prepared as drafts for human approval. An assistant can propose a payment run; it does not execute one. That boundary is designed in from the start rather than added once something is already working.
How a project runs
- Tell us your system and your use case. Which ERP, which version, and what you want an assistant to be able to answer.
- Agree scope and access. We define the tools together, starting read-only, and agree how access is provisioned — service user, credentials, sandbox.
- Connect and test. Configured against your environment and tested with real queries before anyone relies on it.
- Use it. Your team asks in plain language; the assistant answers from live data.
A first project is usually small on purpose: one system, three or four read-only tools, enough to prove the value. Most of the effort is not writing code — it is agreeing access, credentials and scope.
What we will ask you
- Which ERP you run, and which version
- Whether a sandbox or test environment exists
- Who can provide a service user with read-only rights
- What you actually want the assistant to do
The last one matters most. It decides which tools are worth building, and it is the question most integration projects answer too late.
Get in touch
Integrations are scoped individually. For parameters, credentials and a technical conversation, write to office@isapexchange.com with your ERP and your use case, and we will take it from there.
More detailed technical documentation will follow on this page. In the meantime, see how iSAP fits together in the other guides, or read about our payment solutions and payroll solutions.
Frequently asked questions
What is MCP?
MCP stands for Model Context Protocol. It is an open standard that lets an AI assistant call a defined set of tools against a system, rather than a developer writing custom integration code for each one. The assistant sees a list of available tools, decides which to use, and receives structured data back.
Which ERP systems are covered?
The integration approach is designed for SAP, Oracle, Microsoft Dynamics 365, Odoo and iSAP.One. The connection method differs by system — SAP typically through OData or the Service Layer, Oracle through Fusion REST APIs, Dynamics 365 through Dataverse, Odoo through JSON-RPC, and iSAP.One through its own REST API — but the tools your assistant sees are the same in each case.
Does this move money automatically?
No. Integrations begin read-only. Reading invoices, balances and payment status is very different from initiating a payment, and we treat it that way. Where write operations are introduced later, they are prepared as drafts requiring human approval, never executed by an assistant on its own.
Do I need to replace my ERP?
No. The integration sits alongside your existing system. Nothing is migrated and no data leaves your ERP except what a specific tool call requests.
What about our data and GDPR?
Data returned through a tool call can end up in an AI assistant's context, so we scope tools deliberately: status codes, identifiers and amounts rather than personal data by default. Data residency, processing agreements and the exact scope are agreed per customer before anything is connected.
Is this available now?
Integrations are set up individually with each customer rather than self-service. If you want to connect your ERP, contact us at office@isapexchange.com and we will walk through your system, your use case and what is needed on both sides.
What does a first project look like?
Usually a small read-only scope on one system: list invoices, retrieve an invoice, check payment status. That proves the connection and the value before anything larger is built. Most of the effort is not the code, it is agreeing access, credentials and scope.
What do you need from us to start?
Which ERP you run and its version, whether you have a sandbox or test environment, who can provide a service user with read-only rights, and what you actually want the assistant to do. That last one matters most — it decides which tools are worth building.
Find this useful? Make iSAP Exchange a preferred source on Google, and our guides will surface more easily when you search.