“Will this work with our ERP — the system that manages our business operations?” is usually the first question we hear. The answer is: often yes, but it has to be checked before you sign anything. If an ERP, a CRM — a system for managing customer relationships — or accounting software has an API, the interface other software uses to work with a system and its data, or even just file import, it can usually be connected to an AI model (the engine behind tools such as ChatGPT). First, we check which data and operations the system actually supports, whether your licence covers that access, and whether the expected benefit for the chosen process justifies the cost of the connection. This guide compares four approaches and lists the questions to ask your supplier.
We write for companies running the systems that actually sit in Polish offices — Comarch, enova365, Symfonia and Subiekt, the ERP and accounting packages most Polish firms use, and on the CRM side Livespace, a Polish CRM, alongside Pipedrive and HubSpot — not for developers: four ways to connect, what leaves the company in each of them, and the questions to ask a partner before signing. Technical passages worth passing to whoever runs your systems are marked “For your IT team”. We list these systems because they are the most common in Polish companies; we are not a partner of any vendor and we do not review their products. The interface details were read from vendor websites on 6 September 2026; vendors change them without notice. Where personal data is involved, we describe the technical and organisational side, not the legal one.
What “AI integration with ERP” actually means
Three different things hide behind the phrase. The first is AI features the vendor has built into its own product — a product feature, not an integration; you check it in the vendor’s current documentation, and we do not review it. The second is your process with an AI model inside it, reading from the ERP or CRM and possibly writing back to it: an order from an email becomes a document in the system, and the AI suggests how to record a purchase invoice in the accounts. That is what this article is about. The third, “chat with your ERP data”, is a variant of the second in which the AI only reads.
Four verbs describe the scope of an integration: read, suggest, write and trigger the next action, sending a confirmation for instance. Each one costs more and carries more risk than the last. So the first version always reads and suggests, writing starts in human-approval mode, and loosening supervision is a decision taken on pilot data, not an assumption in the quote. AI integration with a CRM follows the same rule: an entry prepared for approval — yes; an email sent to a customer unread — no.
Before you choose an approach: three questions about your system
Does the system have a documented interface — and is it in your licence? A REST API, the vendor’s own WebAPI, a programming library such as Sfera in Subiekt, or even XML or CSV file import — the difference between them is a difference in build and maintenance cost. In several popular systems the interface is a separately licensed module, priced by the vendor or its partner.
Who has access? The IT department, the vendor’s partner, and sometimes nobody, because whoever implemented the system has left the company. Getting access is often the longest single item in the schedule, so we start arranging it in the same week we pick the process.
Which fields does the process actually need? This is where data minimisation is settled: matching an order needs item codes and quantities, not necessarily the contact’s phone number. The test is the same as in any implementation: try exporting the last hundred cases of the process as one table. Do not describe how you would do it — actually do it.
Four ways to integrate
| Approach | When it fits | What leaves the company | Typical risk | Maintenance |
|---|---|---|---|---|
| 1. API or webhook (an automatic notice from the system) | REST API in the licence, one or two systems | Only the fields sent | Query limits, interface version changes | Low |
| 2. Intermediary program (n8n, Make, Power Automate) | Several systems and steps, an approval step | Fields sent, plus execution history | Nobody owns the rules once they are set | Medium |
| 3. MCP server (a program on your side that gives the AI selected functions) | An AI assistant or AI agent (software that carries out a task’s steps itself) uses selected system functions | Whatever those functions return | Access too broad, hidden instructions in data | Medium to high |
| 4. Software robot (RPA) that clicks through an application like a person | No interface and no partner | Whatever the robot sends outside the company (to an AI model, for example); nothing if the whole flow stays inside the company | Breaks when a screen changes; hard to tell who did what | High |
Approach 1. The system’s API or webhook
The simplest route when the system has a documented REST API — HubSpot, Pipedrive, BaseLinker (a Polish multichannel e-commerce hub), wFirma (Polish online accounting) or Symfonia WebAPI. With a webhook the system itself sends an automatic notice when something changes; with polling the integration checks every few minutes whether anything has changed — simpler, but slower, and it uses up the query allowance. The limits have to be designed in; they are not trivia: BaseLinker allows 100 requests a minute, HubSpot 100 or 190 per 10 seconds for private apps, depending on the plan. Three rules we do not negotiate: each integration has a separate technical user, the right to read is kept apart from the right to write, and every write goes into the activity log together with what it was based on.
Intermediate options: file import and a read-only view
When there is no API, two sensible routes remain. The model prepares a file in the system’s import format — Comarch ERP Optima officially imports and exports documents through XML files — and a person imports it and confirms: slower, but cheap and with a natural approval step. Or there is no write path at all: the model gets a report export or a read-only view, and a person types the result in. In systems built on an SQL database, that view is sometimes a direct read from the database. The vendor usually does not support this, so read-only, on a separate account, and with the implementation partner’s knowledge.
Approach 2. An intermediary program: n8n, Make or Power Automate
When a process involves several systems and steps, an automation tool puts them into one sequence: a new email starts the process, the AI model pulls out the fields needed, rules check them, the person responsible gets an approval request (the Send and Wait step in n8n), and once approved the data goes into the system. n8n has ready-made steps for connecting to HubSpot and Pipedrive; not for the Polish ERPs, so the write goes through the WebAPI or as an import file. This program is where you decide and enforce which fields may reach the model, limiting the data to what is needed. It also keeps the activity log. That is why it matters whether the program runs on your own infrastructure in the EU or in the vendor’s cloud: it stores the history of every run together with the data. For your IT team: the Send and Wait step handles approval, and the HTTP Request step handles the write, through an HTTP call to the WebAPI or an import file. Everything about n8n itself — pricing, licence, retention, the comparison with Make — is in the n8n guide.
Approach 3. MCP server: selected system functions for an AI assistant, within set permissions
MCP (Model Context Protocol) is an open standard that lets an AI assistant use your system’s functions, developed under the Linux Foundation — since 9 December 2025 within the Agentic AI Foundation; the current specification is dated 28 July 2026. An MCP server gives an AI assistant selected functions with set permissions — “find a business partner”, say, or “create an order for approval”. The AI app (Claude, ChatGPT, Copilot or your own agent) uses them without a separate integration for each program.
For your IT team: the protocol is based on JSON-RPC.
It pays off for a company when many different AI apps need to use the same MCP server, and the market is already doing it: HubSpot runs an official remote MCP server, n8n can be an MCP server (the MCP Server Trigger node) and a program that uses other MCP servers (the MCP Client Tool node), Make offers scenarios as MCP functions. We build MCP servers too — and this is where an agent begins in practice. What such a project looks like — one API, one AI app, read-only first — is set out on our Connecting an AI assistant to your system (MCP) page.
The risks are just as concrete. The specification says not to trust function descriptions unless they come from a trusted server. Data a function returns may carry hidden instructions that try to steer the assistant. And asking the user’s permission before each use of a function is only something the specification recommends to the AI app — whether the app you are buying actually asks has to be checked with its vendor. The US NSA warned in May 2026 that the pace of MCP adoption had outrun its safeguards. So permissions are designed before the model is chosen — as we set out under AI agent implementation.
What an MCP server changes in the quote, acceptance and an AI agent’s permissions — and what to ask a supplier who says “we have MCP” — is covered in MCP for businesses: what it is and what it changes.
Approach 4. A software robot (RPA) — a last resort
A software robot impersonates a user: it opens a window, clicks, types. It only makes sense for desktop-only applications where nobody will write a connector. It is fragile — a change to a window’s layout can stop it. It is also hard to tell who did what, because the activity log shows a user account rather than the robot’s actions separately. It needs a per-workstation licence and is hard to leave running safely unattended. As a stopgap (a bridge), or for screen reading at low volume — yes; as the plan for writing data at scale — no.
System by system: what the ERP, CRM and accounting packages popular in Poland offer (as at 6 September 2026)
This part is mainly for whoever runs your systems. If that is not you, the “In short” line under each system is enough. Each entry is an interface type, a note on licensing and what it means for the choice of approach — not a product review.
Comarch ERP Optima and Comarch ERP XL
In short: according to partner documentation, Comarch ERP Optima has no public REST API. Its official document-exchange route uses files; a separately licensed WebAPI is also available. In practice: file exchange or working through a partner.
For your IT team: the official route for exchanging documents in
Comarch ERP Optima
is export and import through XML files, and only authorised Comarch partners receive the description
of their structure. According to partner documentation, Comarch Optima has no public REST API: there
is a separately licensed WebAPI based on SOAP and the oldest interface, COM, which requires a local
installation; there are also third-party REST wrappers — a category, not a recommendation.
Conclusion: the file route, or work through a partner. Comarch ERP XL exposes functions through the
CDN_API.DLL library installed with the system — a programming interface, not a network service.
Comarch Betterfly (formerly Comarch ERP XT) has an API for two-way data exchange with e-commerce.
enova365
In short: data exchange goes through the Integrator module, bought as an add-on; it can retrieve, add and update invoices, goods and business partners among other things.
For your IT team: the vendor offers the Integrator module, licensed as an add-on: SOAP (WCF) and REST, XML and JSON, two-way working — retrieving, adding and updating invoices, goods and business partners among other things — plus scheduled import and export. This can support approach 1 or 2 if Integrator is included in your licence; its price comes from the vendor or a partner, not from us.
Symfonia ERP
In short: Symfonia has a data-exchange interface (WebAPI) on an annual subscription, licensed separately for the Trade module and for Finance and Accounting.
For your IT team: Symfonia ERP WebAPI is REST with JSON over HTTPS, available on an annual subscription and licensed separately for the Trade module (business partners, goods, stock levels, orders, documents, payments) and for Finance and Accounting (business partners, settlements, documents, chart of accounts). By default the licence allows ten concurrently open sessions — an integration must not take them away from people. The vendor quotes the price.
Subiekt nexo and Subiekt GT (InsERT)
In short: Subiekt nexo PRO includes Sfera, a developer library. For Subiekt GT, Sfera is an add-on sold per workstation. A developer writes the connector to it.
For your IT team: in both programs the programming interface is Sfera. Sfera for Subiekt GT is a COM (OLE Automation) add-on sold per workstation — it runs locally, alongside the program. In Subiekt nexo Sfera is among the features available in the PRO edition, documented in the nexo SDK; there is also an event-driven Sfera, reacting to operations in the program. In both cases a developer writes the connector.
Microsoft Dynamics 365 Business Central
In short: the online edition has a documented data-exchange interface (REST API) with stated limits. Copilot in Business Central is a vendor feature, not an integration with your process.
For your IT team: the online edition has a REST API and OData V4 with documented limits — 6,000 requests per user in a five-minute window, five concurrent requests, up to 200 webhook subscriptions — and the SOAP endpoints are being retired.
CRM: Livespace, Pipedrive, HubSpot
In short: AI integration with a CRM is technically the easiest, because all three systems have a data-exchange interface (REST API). Livespace provides one free of charge on every account from the Automation plan upwards.
For your IT team: Pipedrive authorises with an API token or OAuth 2.0, has webhooks and a daily budget of points spent on API requests (Pipedrive calls them tokens): 30,000 times the plan multiplier (Lite 1×, Growth 2×, Premium 5×, Ultimate 7×) times the number of seats. HubSpot limits private apps to 100 requests per 10 seconds on the Free and Starter plans and 190 on Professional and Enterprise, and runs an official MCP server with OAuth 2.0. The difficulty is not technical but procedural: what the model may prepare in the CRM and what it must not be allowed to send, we set out on the page on AI in the sales team.
Invoicing and accounting software: wFirma, Fakturownia — and KSeF
In short: AI integration with an accounting system usually starts with the invoicing software; wFirma and Fakturownia both have a data-exchange interface (REST API): wFirma requires an access request in the app, and for Fakturownia check with the vendor whether your plan includes it.
For your IT team: wFirma provides a REST/JSON API once access is requested in the app; up to 1,000 documents generated through the API a month free of charge, above that individual pricing. Fakturownia, another Polish invoicing service, has a REST API in JSON or XML with a token from the account settings — invoices, products, customers, stock documents, payments; whether it is in every plan, check with the vendor. Both suit approaches 1 and 2 in the “AI prepares, a human approves” mode we described under accounting automation.
KSeF — Poland’s mandatory national e-invoicing system — changes the context of every invoicing integration. According to ksef.podatki.gov.pl (as at 29 May 2026), only KSeF 2.0 has been running since 1 February 2026; from that date the obligation to issue e-invoices covered taxpayers with 2024 sales above PLN 200 million, from 1 April 2026 everyone else, and the smallest — with monthly sales up to PLN 10,000 — will be covered from 1 January 2027. The KSeF 2.0 API documentation has been public since 30 June 2025. What is left to automate after KSeF we set out in the article on KSeF and accounting automation.
BaseLinker (for companies selling online)
In short: in a trading company BaseLinker often already links the shops to the ERP; the AI model then connects to it rather than to each channel separately.
For your IT team: BaseLinker’s API is JSON through a single POST endpoint, a token in the header, a limit of 100 requests a minute and over 150 methods — from orders to stock documents. Where we start in retail is on the page on AI in a trading company.
What leaves the company: fields, region, training, permissions
“Does ERP data go to OpenAI or Anthropic?” — with each approach that is a design decision, not a property of the model. With approaches 1 and 2 only the fields the integration sends reach the model provider, and you choose them. With approach 3 the model sees only what those functions return, so they are designed narrowly: “stock level for an item code” rather than “the whole product record with its history”. With approach 4 the robot reads what is on the screen and can carry out its steps on a company computer (as Power Automate desktop flows do, for example — although the service itself needs an account and an internet connection, so check what it stores outside the company). What leaves the company is whatever the robot passes on — and if a screenshot or the full text read from the screen goes to an AI model, everything on that screen leaves, not just the fields you need. In the four-step flow — your system, the intermediary program, the model provider, back to the system — most is settled at the second step: data that was never sent needs no guarantees at all. The whole flow is on the page on data security and GDPR.
In the terms of service you check the processing region and whether content is used for training: the business tiers of the large providers switch it off by default, consumer tiers are sometimes the opposite — check the terms of the specific service rather than assuming. The model provider’s role is established separately for each operation; why, we set out in GDPR and an LLM rollout.
Every place the integration writes to gets written-down permissions in four parts: what it may read, what it may write, which operations need a person’s approval and where its actions are recorded (the activity log) — the same four items every agent project of ours starts from. Most internal integrations are not high-risk systems within the meaning of the AI Act, but the classification is settled case by case by your lawyer — the duties they identify are implemented under the AI Act technical compliance sprint. This describes the technical and organisational side, not legal advice — the legal assessment belongs to your lawyer or data protection officer.
What an AI integration with an ERP costs, and how long it takes
We will not give you a range without knowing your interface. Six things decide the cost:
- Quality of the interface. Cheapest first: REST API in the licence, a WebAPI or Integrator module to buy, a COM library with a local connector, file import, a software robot (RPA).
- The partner’s share. Optima’s XML structure goes to Comarch partners only; Sfera needs a developer. Every extra party means coordination and a separate invoice.
- Number of systems. Count integrations, not features: each system is its own authentication, data mapping, error handling and access to arrange — we set this out in the article on what an AI implementation costs.
- State of the data. Business partners spelled three ways and item records with no codes are work that is not called integration but costs like integration.
- Level of certainty. A proposal that a person approves is cheaper than automatic updates without approval, because those need ongoing monitoring and checks of a sample of completed cases.
- Maintenance. ERP version updates, retired API versions (Business Central is retiring SOAP; Pipedrive introduced new limits over the course of 2025) and retired model versions — the vendor sets the timing, not you.
Time: one system with a REST API and a test database is weeks; several systems with partners along the way, months — and access is often the longest item. Model fees alone, at a few hundred documents a month, run to a few dozen PLN; most of the cost comes from building and maintaining the connection. An indicative range helps compare options when it is clear what it covers, which assumptions it rests on and whether it includes running costs. To price your project, we also need to know how your system can be accessed.
A worked example: emailed orders into the ERP with a salesperson’s approval
The figures are illustrative and are there for working through your own case — they do not come from a client implementation.
A trading company receives 600 orders by email a month; a salesperson retypes each one into the ERP in about 7 minutes, which is 70 hours a month. With approach 2 the model extracts the line items and matches them to item codes from the ERP, a separate step then checks the item codes and quantities, the approval step (Send and Wait) sends the salesperson a summary, and once approved the integration (the HTTP Request step) creates the order through the WebAPI — or, where there is no API, writes an XML file for import. If approval takes about a minute, that is 10 hours a month instead of 70. The review step is there so that errors surface before confirmation rather than after the order goes out. How to match customer codes, units and packs to item numbers, and what to do with the orders the system is unsure about, are covered in the article on orders from e-mail and PDF into the ERP.
Model cost per the Claude API pricing of 6 September 2026 (Claude Sonnet 5: US$2 per million input tokens, US$10 per million output; tokens are the units providers count text and charge in; billed in dollars): 600 times roughly 6,000 input tokens is 3.6 million, so $7.20; 600 times roughly 800 output tokens is 0.48 million, so $4.80 — around $12 a month in total. The intermediary program: 600–1,200 executions fit inside n8n Cloud Starter (€20 a month on annual billing for 2,500 executions, price of 5 September 2026) or an install on your own server. The interface licence — WebAPI, Integrator, Sfera — is priced by the vendor or its partner; we do not quote somebody else’s price.
The fixed part is the build: three or four integrations (reading business partners and item codes, writing the order, mail, the approval channel), testing and handover — that is what the quote covers. Under these assumptions, the process would free up about 60 hours of a salesperson’s time a month, before allowing for exceptions and corrections. If an hour of that time costs you X zł, then 60 hours times X times twelve months estimates the annual value of the time released; it is not automatically a cash saving. Compare that value with the build cost and the annual running and subscription costs, and use a pilot to check how long approval takes and how often exceptions occur.
When not to integrate — or not yet
- The ERP or CRM already does it. Then switching on a feature you already pay for is enough.
- The volume is too small. The cost of an integration is largely fixed; if the process takes two hours a month, it will almost certainly not pay back.
- There is no interface and no partner. RPA is a bridge, not a plan — the decision about the system comes first, the decision about AI second.
- The data is not in the system anyway. Orders in inboxes and on scans, the decision history in someone’s head — the first stage is putting the flow in order, and that is not an obstacle but the actual scope of that stage.
- There is no process owner and no rules. An integration will entrench the argument about the shape of the process instead of settling it.
- There has been no read-only version yet. A CSV export plus a model proves the value without a single write integration. Start there.
- Somebody requires unsupervised writing from day one. Every implementation of ours starts with approval: at the start, no customer message and no change to data in the system goes through without a person’s approval.
- HR and payroll modules. Employee personal data is a separate regime, and our systems do not score candidates in recruitment under any of the four approaches — the principles behind every implementation are on our standards page.
What to ask your ERP partner before you sign anything
- Does our licence cover WebAPI, Integrator or Sfera — and if not, what does it cost and who switches it on?
- Is there a test database, and how do we refresh it?
- Which objects can be read and which written — and does a write through the interface pass the same validation as a manual entry?
- Will we get a separate technical user with the minimum scope of permissions?
- What are the request and session limits?
- Where can the activity log of actions performed by the integration be seen?
- What happens to the integration when the version is updated — who tests, who pays?
- Who maintains the connector after the project ends, and on what terms?
- Can we have read-only access to start with?
- Can the last hundred cases of the process be exported as one table — today?
What next
In a four-stage rollout — audit, pilot, implementation, handover — the interface question is settled during the audit, and the pilot always runs in human-approval mode. You do not need to know which approach is right for you; you need to know which process and which system. How we pick the process, which steps need a person’s approval and what the cost depends on is on the page on AI automation in a company.
Tell us about your process and the system it runs in. We will tell you which of the four ways we would take and where we would start.